Fix typos in 37 files.

EIPS/eip-1057.md

@@ -331,7 +331,7 @@ The flow of the inner loop is:
 * The random sequence of math and cache accesses is performed
 * The DAG data read at the start of the loop is merged at the end of the loop
 
-`prog_seed` and `loop` come from the outer loop, corresponding to the current program seed (which is block_number/PROGPOW_PERIOD) and the loop iteration number.  `mix` is the state array, initially filled by `fill_mix`. `dag` is the bytes of the Ethash DAG grouped into 32 bit unsigned ints in litte-endian format.  On little-endian architectures this is just a normal int32 pointer to the existing DAG.
+`prog_seed` and `loop` come from the outer loop, corresponding to the current program seed (which is block_number/PROGPOW_PERIOD) and the loop iteration number.  `mix` is the state array, initially filled by `fill_mix`. `dag` is the bytes of the Ethash DAG grouped into 32 bit unsigned ints in little-endian format.  On little-endian architectures this is just a normal int32 pointer to the existing DAG.
 
 `DAG_BYTES` is set to the number of bytes in the current DAG, which is generated identically to the existing Ethash algorithm.  
 

EIPS/eip-107.md

@@ -93,7 +93,7 @@ the error object cannot be a javascript Error object due to postMessage limitati
 ## Rationale
 
 The design for that proposal was chosen for its simplicity and security. A previous idea was to use an oauth-like protocol in order for the user to accept or deny a transaction request. It would have required deeper code change in the node and some geth contributors argues that such change did not fit into geth code base as it would have required dapp aware code.
-The current design, instead has a very simple implementation (self contained html file that can be shared across node's implementation) and its safeness is guarantess by browsers' cross domain policies.
+The current design, instead has a very simple implementation (self contained html file that can be shared across node's implementation) and its safeness is guaranteed by browsers' cross domain policies.
 
 The use of iframe/ window was required to have both security and user friendliness. The invisible iframe allows the dapp to execute read only calls without the need for user input, and the window ensures user approval before making a call. While we could have made it without the window mode by making the iframe confirmation use the native browser ```window.confirm``` dialog, this would have prevented the use of a more elegant confirmation popup that the current design allows. It also happens to be that the ```window.confirm``` is not safe in some browsers, as it gives focus to the accept option and can be triggered automatically (https://bugs.chromium.org/p/chromium/issues/detail?id=260653).
 

EIPS/eip-1109.md

@@ -47,7 +47,7 @@ The return will be 1 in case of success call and 0 in any of the next cases:
 1.- mu_s[0] is an address of an undefined precompiled smart contract.
 2.- The precompiled smart contract fails (as defined on each smart contract). Invalid input parameters for example.
 
-Precompiled smart contracs, does not execute opcodes, so there is no need to pass a gas parameter as a normal `CALL` (`0xf1`).  If the available gas is less that 2 plus the required gas required for the specific precompiled smart cotract, the context just STOPS executing with an "Out of Gas" error.
+Precompiled smart contracts, does not execute opcodes, so there is no need to pass a gas parameter as a normal `CALL` (`0xf1`).  If the available gas is less that 2 plus the required gas required for the specific precompiled smart contract, the context just STOPS executing with an "Out of Gas" error.
 
 There is no stack check for this call.
 

EIPS/eip-1965.md

@@ -16,7 +16,7 @@ This EIP adds a precompile that returns whether a specific chainID (EIP-155 uniq
 ## Motivation
 [EIP-155](./eip-155.md) proposes to use the chain ID to prevent the replay of transactions between different chains. It would be a great benefit to have the same possibility inside smart contracts when handling off-chain message signatures, especially for Layer 2 signature schemes using [EIP-712](./eip-712.md).
 
-[EIP-1344](./eip-1344.md) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insuficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. Furthermore EIP-1344 can't protect replay properly for minority-led hardfork as the caching system cannot guarantee accuracy of the blockNumber at which the new chainID has been introduced.
+[EIP-1344](./eip-1344.md) is attempting to solve this by giving smart contract access to the tip of the chainID history. This is insufficient as such value is changing. Hence why EIP-1344 describes a contract based solution to work around the problem. It would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in EIP-1344. Furthermore EIP-1344 can't protect replay properly for minority-led hardfork as the caching system cannot guarantee accuracy of the blockNumber at which the new chainID has been introduced.
 
 [EIP-1959](./eip-1959.md) solves the issue of EIP-1344 but do not attempt to protect from minority-led hardfork as mentioned in the rationale. We consider this a mistake, since it remove some freedom to fork. We consider that all fork should be given equal oportunities. And while there will always be issues we can't solve for the majority that ignore a particular fork, **users that decide to use both the minority-fork and the majority-chain should be protected from replay without having to wait for the majority chain to update its chainID.**
 

EIPS/eip-2015.md

@@ -1,7 +1,7 @@
 ---
 eip: 2015
 title: wallet_updateEthereumChain RPC Method
-description: Adds an RPC method to switch betweeen EVM-compatible chains
+description: Adds an RPC method to switch between EVM-compatible chains
 author: Pedro Gomes (@pedrouid), Erik Marks (@rekmarks), Pandapip1 (@Pandapip1)
 discussions-to: https://ethereum-magicians.org/t/eip-2015-wallet-update-chain-json-rpc-method-wallet-updatechain/3274
 status: Stagnant

EIPS/eip-2315.md

@@ -9,7 +9,7 @@ type: Standards Track
 category: Core
 created: 2019-10-17
 requires: 3540, 3670, 4200
-withdrawal-reason: This proposal has been superceded by the EOF proposals.
+withdrawal-reason: This proposal has been superseded by the EOF proposals.
 ---
 
 ## Abstract

EIPS/eip-2515.md

@@ -43,7 +43,7 @@ Add the variable `DIFFICULTY_FREEZE_DIFFERENCE` and use the `LAST_FORK_HEIGHT` t
 For example we can set the `DFD = 1,800,000 blocks` or approximately 9 months. The Difficulty Calculation would then be.
 
 ```
-if (BLOCK_HEIGHT  <= LAST_FORK_HEIGHT + DIFFICUTLY_FREEZE_DIFFERENCE) :
+if (BLOCK_HEIGHT  <= LAST_FORK_HEIGHT + DIFFICULTY_FREEZE_DIFFERENCE) :
    block_diff = parent_diff + parent_diff // 2048 * max(
                 1 - (block_timestamp - parent_timestamp) // 10, -99)
 

EIPS/eip-2711.md

@@ -96,7 +96,7 @@ While we could save one byte in the common case by bundling the y-parity bit of
 ### Optionality of ChainID
 Sometimes it is useful to have a transaction that *can* be replayed on multiple chains.  An example of this is when you construct a vanity signature for a transaction and have the `from` be whatever address that signature recovers to.  With the ability to have someone else be a gas payer (setting both the gas limit and the gas price), one can have transactions that deploy contracts which live at the same address on every chain.  While this can be accomplished with CREATE2 using legacy transactions, we have the opportunity here to simplify the process and enable potentially other future uses of deterministic transactions by making ChainID optional.
 ### Optionality of ValidUntil
-A user can set `ValidUntil` to a very large number which effectively makes it non-expiring.  By making `ValidUntil` optional, we can save some bytes on the wire by allowing such transcations to simply have a `0` (1 byte in RLP) value for this field.
+A user can set `ValidUntil` to a very large number which effectively makes it non-expiring.  By making `ValidUntil` optional, we can save some bytes on the wire by allowing such transactions to simply have a `0` (1 byte in RLP) value for this field.
 ### `SENDER` sets `gasLimit` and `gasPrice`
 This type of transaction is useful when the transaction may execute differently depending on what these values are set to.  By having the `SENDER` set both, we ensure that the `SENDER` has full control over the transaction details.
 ### `SENDER` sets `gasLimit`, `GAS_PAYER` sets `gasPrice`

EIPS/eip-2733.md

@@ -249,7 +249,7 @@ limit.
 These fields are included to better support future changes to the transaction
 type. This would likely be used in conjunction with the `flags` and `type`
 fields. A benefit of explicitly defining them is that specialized serialization
-of RLP can be avoided, simplifing clients and downstream infrastructure. The
+of RLP can be avoided, simplifying clients and downstream infrastructure. The
 author believe the cost of 2 bytes per transaction is acceptable for smoother
 integration of future features.
 

EIPS/eip-2780.md

@@ -42,7 +42,7 @@ not by imposing artificial restrictions to encourage it.
 
 Reducing the intrinsic cost of a transaction from `21,000` to `7,000` gas will make sending transactions cheaper,
 is easily achievable, and does not incur technical debt.
-However, such a change should only be made after it is determined that it does not impose non-negligble externalities, specifically:
+However, such a change should only be made after it is determined that it does not impose non-negligible externalities, specifically:
 
 * Increases uncle-rate.
 

EIPS/eip-2935.md

@@ -114,7 +114,7 @@ stop
 
 Note that the input contract read `32` bytes input as `calldataload`. Users and clients doing EVM call to this contract should left pad the `arg` correctly.
 
-<!-- TODO: bytecode is based off on first version and will be updated once assembley is locked down as it changes contract sender and address -->
+<!-- TODO: bytecode is based off on first version and will be updated once assembly is locked down as it changes contract sender and address -->
 
 Corresponding bytecode:
 `60203611603157600143035f35116029575f356120000143116029576120005f3506545f5260205ff35b5f5f5260205ff35b5f5ffd00`

EIPS/eip-2976.md

@@ -34,7 +34,7 @@ All changes specified below apply to all protocol/versions retroactively.
 * `Transaction` is either `TypedTransaction` or `LegacyTransaction`
 * `TypedTransaction` is a byte array containing `TransactionType || TransactionPayload`
 * `TypedTransactionHash` is `keccak256(TypedTransaction)`
-* `TransactionType` is a positive unsigned 8-bit number between `0` and `0x7f` that represents the type of the transcation
+* `TransactionType` is a positive unsigned 8-bit number between `0` and `0x7f` that represents the type of the transaction
 * `TransactionPayload` is an opaque byte array whose interpretation is dependent on the `TransactionType` and defined in future EIPs
 * `LegacyTransaction` is an array of the form `[nonce, gasPrice, gasLimit, to, value, data, v, r, s]`
 * `LegacyTransactionHash` is `keccak256(rlp(LegacyTransaction))`

EIPS/eip-3540.md

@@ -113,7 +113,7 @@ body := types_section, code_section+, container_section*, data_section
 types_section := (inputs, outputs, max_stack_height)+
 ```
 
-*note: `,` is a concatenation operator, `+` should be interpreted as "one or more" of the preceding item, `*` should be interpreted as "zero or more" of the preceding item, and `[item]` should be interpeted as an optional item.*
+*note: `,` is a concatenation operator, `+` should be interpreted as "one or more" of the preceding item, `*` should be interpreted as "zero or more" of the preceding item, and `[item]` should be interpreted as an optional item.*
 
 #### Header
 

EIPS/eip-3779.md

@@ -42,7 +42,7 @@ The relative jumps of [EIP-4200](./eip-4200) and the simple subroutines of [EIP-
 > `RJUMPI` _offset_
 * Jumps if the top of stack is non-zero.
 > `RJUMPSUB` offset
-* Pushes _IP+1_ on the return stack and jumps to _IP+offest_.
+* Pushes _IP+1_ on the return stack and jumps to _IP+offset_.
 > `RETURNSUB`
 * Jumps to the address popped off the return stack.
 

EIPS/eip-3788.md

@@ -18,7 +18,7 @@ Reject transactions that do not explicitly have the same chainId as the node's c
 ## Motivation
 
 Per [EIP-155](./eip-155.md) a transaction with a `chainId = 0` is considered to be a valid 
-transaction. This was a feature to offer developers the ability to sumbit replayable transactions 
+transaction. This was a feature to offer developers the ability to submit replayable transactions 
 across different chains. With the rise of evm compatible chains, many of which use forks, or packages
 from popular Ethereum clients, we are putting user funds at risk. This is because most wallet
 interfaces do not expose the chainId to the user, meaning they typically do not have insight

EIPS/eip-5027.md

@@ -53,9 +53,9 @@ If `block.number >= FORK_BLKNUM`, the contract creation initialization can retur
 (CODE_SIZE - 1) // CODE_SIZE_UNIT * COLD_ACCOUNT_CODE_ACCESS_COST_PER_UNIT
 ```
 
-if the contract is not in `accessed_code_in_addresses` or `0` if the contract is in `accessed_code_in_addresses`, where `//` is the integer divide operator, and `accessed_code_in_addresses: Set[Address]` is a tranasction-context-wide set similar to `access_addressses` and `accessed_storage_keys`.
+if the contract is not in `accessed_code_in_addresses` or `0` if the contract is in `accessed_code_in_addresses`, where `//` is the integer divide operator, and `accessed_code_in_addresses: Set[Address]` is a transaction-context-wide set similar to `access_addresses` and `accessed_storage_keys`.
 
-When a transactoin execution begins, `accessed_code_in_addresses` will include `tx.sender`, `tx.to`, and all precompiles.
+When a transaction execution begins, `accessed_code_in_addresses` will include `tx.sender`, `tx.to`, and all precompiles.
 
 When `CREATE/CREATE2/EXTCODECOPY/CALL/CALLCODE/DELEGATECALL/STATICCALL` is called, immediately add the address to `accessed_code_in_addresses`.
 

EIPS/eip-5450.md

@@ -144,7 +144,7 @@ Originally another variant of stack validation was proposed, where instead of li
 
 The advantage of this variant would be somewhat simpler algorithm (we would not need to track stack height bounds, but only a single stack height value for each instruction) and no extra requirement for ordering of code basic blocks (see below).
 
-However compiler teams opposed to such restrictive stack height requirements. One prominent pattern used by compilers which wouldn't be possible is jumping to terminating helpers (code blocks ending with `RETURN` or `REVERT`) from different stack heights. This is common for example for a series of `assert` statements, each one compiled to a `RJUMPI` into a shared terminating helper. Enforcing constant stack requirement would mean that before jumping to such helper, extra items on the stack have to be popped, and this noticably increases code size and consumed gas, and would defeat the purpose of extracting these common terminating sequences into a helper.
+However compiler teams opposed to such restrictive stack height requirements. One prominent pattern used by compilers which wouldn't be possible is jumping to terminating helpers (code blocks ending with `RETURN` or `REVERT`) from different stack heights. This is common for example for a series of `assert` statements, each one compiled to a `RJUMPI` into a shared terminating helper. Enforcing constant stack requirement would mean that before jumping to such helper, extra items on the stack have to be popped, and this noticeably increases code size and consumed gas, and would defeat the purpose of extracting these common terminating sequences into a helper.
 
 ### Ordering of basic blocks
 

EIPS/eip-5792.md

@@ -19,7 +19,7 @@ Applications can specify that these onchain calls be executed taking advantage o
 
 The current methods used to send transactions from the user wallet and check their status are `eth_sendTransaction` and `eth_getTransactionReceipt`.
 
-The current methods used to send transactions from the user wallet and check their status do not meet modern developer demands and cannot accomodate new transaction formats. Even the name–- `eth_sendTransaction`-– is an artifact of a time when nodes served as wallets. 
+The current methods used to send transactions from the user wallet and check their status do not meet modern developer demands and cannot accommodate new transaction formats. Even the name–- `eth_sendTransaction`-– is an artifact of a time when nodes served as wallets. 
 
 Today, developers want to send multiple calls batched together in a single RPC call, which many smart accounts can, in turn, execute atomically in a single transaction. Developers also want to make use of features afforded by new transaction formats, like paymasters in [ERC-4337](./eip-4337.md) transactions. `eth_sendTransaction` offers no way to do these things.
 
@@ -34,7 +34,7 @@ We also define one capability expression for use with the fourth method, which f
 
 ### `wallet_sendCalls`
 
-Requests that a wallet submits a batch of calls. `from` and `chainId` are top-level properties rather than per-call properties because all calls should be sent from the same sender and on the same chain, identified by [EIP-155](./eip-155.md) integers expressed in hexidecimal notation. The items in the `calls` field are only those that are shared by all transaction types. Any other fields that a wallet may need to submit a transaction should be handled by the wallet.
+Requests that a wallet submits a batch of calls. `from` and `chainId` are top-level properties rather than per-call properties because all calls should be sent from the same sender and on the same chain, identified by [EIP-155](./eip-155.md) integers expressed in hexadecimal notation. The items in the `calls` field are only those that are shared by all transaction types. Any other fields that a wallet may need to submit a transaction should be handled by the wallet.
 
 The capabilities field is how an app can communicate with a wallet about capabilities a wallet supports. For example, this is where an app can specify a paymaster service URL from which an [ERC-4337](./eip-4337.md) wallet can request a `paymasterAndData` input for a user operation.
 
@@ -205,7 +205,7 @@ If any of these supplemental expressions of capabilities are contradicted by cap
 
 #### `wallet_getCapabilities` RPC Specification
 
-Capabilities are returned in key/value pairs, with the key naming a capability and a value conforming to a shape defined for that name, in an object keyed to the relevant [EIP-155](./eip-155.md) `chainId` expressed in hexidecimal notation.
+Capabilities are returned in key/value pairs, with the key naming a capability and a value conforming to a shape defined for that name, in an object keyed to the relevant [EIP-155](./eip-155.md) `chainId` expressed in hexadecimal notation.
 Capabilities are nested in per-chain objects because wallets may support different capabilities across multiple chains authorized in a given session.
 
 ```typescript