Fix several typos

gas-oracle/README.md

@@ -2,7 +2,7 @@
 
 This service is responsible for sending transactions to the Sequencer to update
 the L2 gas price over time. It consists of a set of functions found in the
-`gasprices` package that define the parameters of how the gas prices are updated
+`gasprices` package that defines the parameters of how the gas prices are updated
 and then the `oracle` package is responsible for observing the Sequencer over
 time and send transactions that actually do update the gas prices.
 

integration-tests/README.md

@@ -1,6 +1,6 @@
 # @eth-optimism/integration-tests
 
-Note that these tests are ran against the legacy system, see `op-e2e` for
+Note that these tests are run against the legacy system, see `op-e2e` for
 the bedrock test suite.
 
 ## Setup

l2geth/accounts/errors.go

@@ -42,7 +42,7 @@ var ErrInvalidPassphrase = errors.New("invalid password")
 var ErrWalletAlreadyOpen = errors.New("wallet already open")
 
 // ErrWalletClosed is returned if a wallet is attempted to be opened the
-// secodn time.
+// second time.
 var ErrWalletClosed = errors.New("wallet closed")
 
 // AuthNeededError is returned by backends for signing requests where the user

l2geth/accounts/hd_test.go

@@ -61,7 +61,7 @@ func TestHDPathParsing(t *testing.T) {
 		// Weird inputs just to ensure they work
 		{"	m  /   44			'\n/\n   60	\n\n\t'   /\n0 ' /\t\t	0", DerivationPath{0x80000000 + 44, 0x80000000 + 60, 0x80000000 + 0, 0}},
 
-		// Invaid derivation paths
+		// Invalid derivation paths
 		{"", nil},              // Empty relative derivation path
 		{"m", nil},             // Empty absolute derivation path
 		{"m/", nil},            // Missing last derivation component

l2geth/accounts/manager.go

@@ -198,7 +198,7 @@ func (am *Manager) Subscribe(sink chan<- WalletEvent) event.Subscription {
 	return am.feed.Subscribe(sink)
 }
 
-// merge is a sorted analogue of append for wallets, where the ordering of the
+// merge is a sorted analog of append for wallets, where the ordering of the
 // origin list is preserved by inserting new wallets at the correct position.
 //
 // The original slice is assumed to be already sorted by URL.
@@ -214,7 +214,7 @@ func merge(slice []Wallet, wallets ...Wallet) []Wallet {
 	return slice
 }
 
-// drop is the couterpart of merge, which looks up wallets from within the sorted
+// drop is the counterpart of merge, which looks up wallets from within the sorted
 // cache and removes the ones specified.
 func drop(slice []Wallet, wallets ...Wallet) []Wallet {
 	for _, wallet := range wallets {

l2geth/accounts/scwallet/README.md

@@ -8,7 +8,7 @@
 
 ## Preparing the smartcard
 
-  **WARNING: FOILLOWING THESE INSTRUCTIONS WILL DESTROY THE MASTER KEY ON YOUR CARD. ONLY PROCEED IF NO FUNDS ARE ASSOCIATED WITH THESE ACCOUNTS**
+  **WARNING: FOLLOWING THESE INSTRUCTIONS WILL DESTROY THE MASTER KEY ON YOUR CARD. ONLY PROCEED IF NO FUNDS ARE ASSOCIATED WITH THESE ACCOUNTS**
 
   You can use status' [keycard-cli](https://github.com/status-im/keycard-cli) and you should get _at least_ version 2.1.1 of their [smartcard application](https://github.com/status-im/status-keycard/releases/download/2.2.1/keycard_v2.2.1.cap)
 

l2geth/accounts/scwallet/wallet.go

@@ -333,7 +333,7 @@ func (w *Wallet) Status() (string, error) {
 // is to strive towards a uniform wallet handling, oblivious to the different
 // backend providers.
 //
-// Please note, if you open a wallet, you must close it to release any allocated
+// Please note, that if you open a wallet, you must close it to release any allocated
 // resources (especially important when working with hardware wallets).
 func (w *Wallet) Open(passphrase string) error {
 	w.lock.Lock()
@@ -362,7 +362,7 @@ func (w *Wallet) Open(passphrase string) error {
 				return err
 			}
 			// Pairing succeeded, fall through to PIN checks. This will of course fail,
-			// but we can't return ErrPINNeeded directly here becase we don't know whether
+			// but we can't return ErrPINNeeded directly here because we don't know whether
 			// a PIN check or a PIN reset is needed.
 			passphrase = ""
 		}
@@ -456,7 +456,7 @@ func (w *Wallet) selfDerive() {
 		case reqc = <-w.deriveReq:
 			// Account discovery requested
 		}
-		// Derivation needs a chain and device access, skip if either unavailable
+		// Derivation needs a chain and device access, skip if either is unavailable
 		w.lock.Lock()
 		if w.session == nil || w.deriveChain == nil {
 			w.lock.Unlock()
@@ -638,7 +638,7 @@ func (w *Wallet) Derive(path accounts.DerivationPath, pin bool) (accounts.Accoun
 // accounts.
 //
 // Note, self derivaton will increment the last component of the specified path
-// opposed to decending into a child path to allow discovering accounts starting
+// opposed to descending into a child path to allow discovering accounts starting
 // from non zero components.
 //
 // Some hardware wallets switched derivation paths through their evolution, so
@@ -666,7 +666,7 @@ func (w *Wallet) SelfDerive(bases []accounts.DerivationPath, chain ethereum.Chai
 // or optionally with the aid of any location metadata from the embedded URL field.
 //
 // If the wallet requires additional authentication to sign the request (e.g.
-// a password to decrypt the account, or a PIN code o verify the transaction),
+// a password to decrypt the account, or a PIN code to verify the transaction),
 // an AuthNeededError instance will be returned, containing infos for the user
 // about which fields or actions are needed. The user may retry by providing
 // the needed details via SignDataWithPassphrase, or by other means (e.g. unlock
@@ -693,7 +693,7 @@ func (w *Wallet) signHash(account accounts.Account, hash []byte) ([]byte, error)
 // or optionally with the aid of any location metadata from the embedded URL field.
 //
 // If the wallet requires additional authentication to sign the request (e.g.
-// a password to decrypt the account, or a PIN code o verify the transaction),
+// a password to decrypt the account, or a PIN code to verify the transaction),
 // an AuthNeededError instance will be returned, containing infos for the user
 // about which fields or actions are needed. The user may retry by providing
 // the needed details via SignTxWithPassphrase, or by other means (e.g. unlock
@@ -733,7 +733,7 @@ func (w *Wallet) signHashWithPassphrase(account accounts.Account, passphrase str
 // or optionally with the aid of any location metadata from the embedded URL field.
 //
 // If the wallet requires additional authentication to sign the request (e.g.
-// a password to decrypt the account, or a PIN code o verify the transaction),
+// a password to decrypt the account, or a PIN code to verify the transaction),
 // an AuthNeededError instance will be returned, containing infos for the user
 // about which fields or actions are needed. The user may retry by providing
 // the needed details via SignHashWithPassphrase, or by other means (e.g. unlock

l2geth/cmd/clef/README.md

@@ -2,7 +2,7 @@
 
 Clef can be used to sign transactions and data and is meant as a(n eventual) replacement for Geth's account management. This allows DApps to not depend on Geth's account management. When a DApp wants to sign data (or a transaction), it can send the content to Clef, which will then provide the user with context and asks for permission to sign the content. If the users grants the signing request, Clef will send the signature back to the DApp.
 
-This setup allows a DApp to connect to a remote Ethereum node and send transactions that are locally signed. This can help in situations when a DApp is connected to an untrusted remote Ethereum node, because a local one is not available, not synchronised with the chain, or is a node that has no built-in (or limited) account management.
+This setup allows a DApp to connect to a remote Ethereum node and send transactions that are locally signed. This can help in situations when a DApp is connected to an untrusted remote Ethereum node, because a local one is not available, not synchronized with the chain, or is a node that has no built-in (or limited) account management.
 
 Clef can run as a daemon on the same machine, off a usb-stick like [USB armory](https://inversepath.com/usbarmory), or even a separate VM in a [QubesOS](https://www.qubes-os.org/) type setup.
 
@@ -75,7 +75,7 @@ In this case, `geth` would be started with `--signer http://localhost:8550` and
 
 Some snags and todos
 
-* [ ] Clef should take a startup param "--no-change", for UIs that do not contain the capability to perform changes to things, only approve/deny. Such a UI should be able to start the signer in a more secure mode by telling it that it only wants approve/deny capabilities.
+* [ ] Clef should take a startup param "--no-change", for UIs that do not contain the capability to perform changes to things, only approve/deny. Such a UI should be able to start the signer in a more secure mode by telling it that it only wants to approve/deny capabilities.
 * [x] It would be nice if Clef could collect new 4byte-id:s/method selectors, and have a secondary database for those (`4byte_custom.json`). Users could then (optionally) submit their collections for inclusion upstream.
 * [ ] It should be possible to configure Clef to check if an account is indeed known to it, before passing on to the UI. The reason it currently does not, is that it would make it possible to enumerate accounts if it immediately returned "unknown account" (side channel attack).
 * [x] It should be possible to configure Clef to auto-allow listing (certain) accounts, instead of asking every time.
@@ -149,7 +149,7 @@ All hex encoded values must be prefixed with `0x`.
 
 ### account_new
 
-#### Create new password protected account
+#### Create a new password protected account
 
 The signer will generate a new private key, encrypts it according to [web3 keystore spec](https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition) and stores it in the keystore directory.
 The client is responsible for creating a backup of the keystore. If the keystore is lost there is no method of retrieving lost accounts.
@@ -229,7 +229,7 @@ Response
 ### account_signTransaction
 
 #### Sign transactions
-   Signs a transactions and responds with the signed transaction in RLP encoded form.
+   Signs a transaction and responds with the signed transaction in RLP encoded form.
 
 #### Arguments
   2. transaction object:
@@ -241,7 +241,7 @@ Response
      - `data` [data:optional]:  input data
      - `nonce` [number]: account nonce
   3. method signature [string:optional]
-     - The method signature, if present, is to aid decoding the calldata. Should consist of `methodname(paramtype,...)`, e.g. `transfer(uint256,address)`. The signer may use this data to parse the supplied calldata, and show the user. The data, however, is considered totally untrusted, and reliability is not expected.
+     - The method signature, if present, is to aid in decoding the calldata. Should consist of `methodname(paramtype,...)`, e.g. `transfer(uint256,address)`. The signer may use this data to parse the supplied calldata, and show the user. The data, however, is considered totally untrusted, and reliability is not expected.
 
 
 #### Result

l2geth/cmd/clef/datatypes.md

@@ -3,7 +3,7 @@
 These data types are defined in the channel between clef and the UI
 ### SignDataRequest
 
-SignDataRequest contains information about a pending request to sign some data. The data to be signed can be of various types, defined by content-type. Clef has done most of the work in canonicalizing and making sense of the data, and it's up to the UI to presentthe user with the contents of the `message`
+SignDataRequest contains information about a pending request to sign some data. The data to be signed can be of various types, defined by content-type. Clef has done most of the work in canonicalizing and making sense of the data, and it's up to the UI to present the user with the contents of the `message`
 
 Example:
 ```json

l2geth/cmd/clef/docs/setup.md

@@ -34,7 +34,7 @@ There are two ways that this can be achieved: integrated via Qubes or integrated
 
 #### 1. Qubes Integrated
 
-Qubes provdes a facility for inter-qubes communication via `qrexec`. A qube can request to make a cross-qube RPC request 
+Qubes provides a facility for inter-qubes communication via `qrexec`. A qube can request to make a cross-qube RPC request 
 to another qube. The OS then asks the user if the call is permitted. 
 
 ![Example](qubes/qrexec-example.png)
@@ -176,7 +176,7 @@ However, it comes with a couple of drawbacks:
 
 #### 2. Network integrated
 
-The second way to set up Clef on a qubes system is to allow networking, and have Clef listen to a port which is accessible
+The second way to set up Clef on a qubes system is to allow networking, and have Clef listen to a port that is accessible
 form other qubes. 
 
 ![Clef via http](qubes/clef_qubes_http.png)

l2geth/cmd/clef/tutorial.md

@@ -227,7 +227,7 @@ In this example:
     - Auto-rejected if the message does not contain `bazonk`,
 - Any other requests will be passed along for manual confirmation.
 
-*Note, to make this example work, please use you own accounts. You can create a new account either via Clef or the traditional account CLI tools. If the latter was chosen, make sure both Clef and Geth use the same keystore by specifying `--keystore path/to/your/keystore` when running Clef.*
+*Note, to make this example work, please use your own accounts. You can create a new account either via Clef or the traditional account CLI tools. If the latter was chosen, make sure both Clef and Geth use the same keystore by specifying `--keystore path/to/your/keystore` when running Clef.*
 
 Attest the new rule file so that Clef will accept loading it: