Merge branch 'master' into transient-approve

ERCS/eip-1.md

@@ -91,7 +91,7 @@ A PR moving an EIP from Last Call to Final SHOULD contain no changes other than
 
 >*EIP Authors are notified of any algorithmic change to the status of their EIP*
 
-**Withdrawn** - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.
+**Withdrawn** - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at a later date it is considered a new proposal.
 
 **Living** - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.
 

ERCS/erc-1046.md

@@ -58,13 +58,13 @@ interface InteroperabilityMetadata {
 
     /**
      * This MUST be true if this is ERC-721 Token Metadata, otherwise, this MUST be omitted.
-     * Setting this to true indicates to wallets that the address should be treated as a ERC-721 token.
+     * Setting this to true indicates to wallets that the address should be treated as an ERC-721 token.
      **/
     erc721?: boolean | undefined;
 
     /**
      * This MUST be true if this is ERC-1155 Token Metadata, otherwise, this MUST be omitted.
-     * Setting this to true indicates to wallets that the address should be treated as a ERC-1155 token.
+     * Setting this to true indicates to wallets that the address should be treated as an ERC-1155 token.
      **/
     erc1155?: boolean | undefined;
 }
@@ -97,7 +97,7 @@ The resolved JSON of the `tokenURI` described in the ERC-20 Interface Extension
  */
 interface ERC20TokenMetadata {
     /**
-     * Interoperabiliy, to differentiate between different types of tokens and their corresponding URIs.
+     * Interoperability, to differentiate between different types of tokens and their corresponding URIs.
      **/
     interop: InteroperabilityMetadata;
 
@@ -157,7 +157,7 @@ Contracts that implement ERC-721 and use its token metadata URI SHOULD to use th
 ```typescript
 interface ERC721TokenMetadataInterop extends ERC721TokenMetadata {
     /**
-     * Interoperabiliy, to avoid confusion between different token URIs
+     * Interoperability, to avoid confusion between different token URIs
      **/
     interop: InteroperabilityMetadata;
 }
@@ -189,7 +189,7 @@ Contracts that implement ERC-1155 and use its token metadata URI are RECOMMENDED
 ```typescript
 interface ERC1155TokenMetadataInterop extends ERC1155TokenMetadata {
     /**
-     * Interoperabiliy, to avoid confusion between different token URIs
+     * Interoperability, to avoid confusion between different token URIs
      **/
     interop: InteroperabilityMetadata;
 }

ERCS/erc-1056.md

@@ -222,7 +222,7 @@ Contract Events are a useful feature for storing data from smart contracts exclu
 
 2. Lookup all events for given identity address using web3, but only for the `previousChange` block
 
-3. Do something with event
+3. Do something with the event
 
 4. Find `previousChange` from the event  and repeat
 

ERCS/erc-1062.md

@@ -18,9 +18,9 @@ The following standard details the implementation of how to combine the IPFS cry
 We think that this implementation is not only aim to let more developers and communities to provide more use cases, but also leverage the human-readable features to gain more user adoption accessing decentralized resources. We considered the IPFS ENS resolver mapping standard a cornerstone for building future Web3.0 service.
 
 ## Motivation
-To build fully decentralized web service, it’s necessary to have a decentralized file storage system. Here comes the IPFS, for three following advantages :
+To build a fully decentralized web service, it’s necessary to have a decentralized file storage system. Here comes the IPFS, for three following advantages :
 - Address large amounts of data, and has unique cryptographic hash for every record.
-- Since IPFS is also based on peer to peer network, it can be really helpful to deliver large amounts of data to users, with safer way and lower the millions of cost for the bandwidth.
+- Since IPFS is also based on peer to peer network, it can be really helpful to deliver large amounts of data to users, in a safer way and lower the millions of cost for the bandwidth.
 - IPFS stores files in high efficient way via tracking version history for every file, and removing the duplications across the network.
 
 Those features makes perfect match for integrating into ENS, and these make users can easily access content through ENS, and show up in the normal browser.

ERCS/erc-1066.md

@@ -480,7 +480,7 @@ AwesomeCoin                 DEX                     TraderBot
 
 Status codes are encoded as a `byte`. Hex values break nicely into high and low nibbles: `category` and `reason`. For instance, `0x01` stands for general success (ie: `true`) and `0x00` for general failure (ie: `false`).
 
-As a general approach, all even numbers are blocking conditions (where the receiver does not have control), and odd numbers are nonblocking (the receiver is free to contrinue as they wish). This aligns both a simple bit check with the common encoding of Booleans.
+As a general approach, all even numbers are blocking conditions (where the receiver does not have control), and odd numbers are nonblocking (the receiver is free to continue as they wish). This aligns both a simple bit check with the common encoding of Booleans.
 
 `bytes1` is very lightweight, portable, easily interoperable with `uint8`, cast from `enum`s, and so on.
 

ERCS/erc-1077.md

@@ -19,7 +19,7 @@ Allows users to offer [EIP-20] token for paying the gas used in a call.
 
 ## Abstract
 
-A main barrier for adoption of DApps is the requirement of multiple tokens for executing in chain actions. Allowing users to sign messages to show intent of execution, but allowing a third party relayer to execute them can circumvent this problem, while ETH will always be required for ethereum transactions, it's possible for smart contract to take [EIP-191] signatures and forward a payment incentive to an untrusted party with ETH for executing the transaction. 
+A main barrier for the adoption of DApps is the requirement of multiple tokens for executing in chain actions. Allowing users to sign messages to show intent of execution, but allowing a third party relayer to execute them can circumvent this problem, while ETH will always be required for ethereum transactions, it's possible for smart contract to take [EIP-191] signatures and forward a payment incentive to an untrusted party with ETH for executing the transaction. 
 
 ## Motivation
 
@@ -83,7 +83,7 @@ In order to be compliant, the transaction **MUST** request to sign a "messageHas
 
 The fields **MUST** be constructed as this method:
 
-The first and second fields are to make it [EIP-191] compliant. Starting a transaction with `byte(0x19)` ensure the signed data from being a [valid ethereum transaction](https://github.com/ethereum/wiki/wiki/RLP). The second argument is a version control byte. The third being the validator address (the account contract address) according to version 0 of [EIP-191]. The remaining arguments being the application specific data for the gas relay: chainID as per [EIP-1344], execution nonce, execution data, agreed gas Price, gas limit of gas relayed call, gas token to pay back and gas relayer authorized to receive reward.
+The first and second fields are to make it [EIP-191] compliant. Starting a transaction with `byte(0x19)` ensure the signed data from being a [valid ethereum transaction](https://github.com/ethereum/wiki/wiki/RLP). The second argument is a version control byte. The third being the validator address (the account contract address) according to version 0 of [EIP-191]. The remaining arguments being the application specific data for the gas relay: chainID as per [EIP-1344], execution nonce, execution data, agreed gas Price, gas limit of gas relayed call, gas token to pay back and gas relayer authorized to receive the reward.
 
 The [EIP-191] message must be constructed as following:
 ```solidity
@@ -174,7 +174,7 @@ Contracts are not obligated to support ether or any other token they don’t wan
 This scheme opens up a great deal of possibilities on interaction as well as different experiments on business models:
 
 * Apps can create individual identities contract for their users which holds the actual funds and then create a different private key for each device they log into. Other apps can use the same identity and just ask to add permissioned public keys to manage the device, so that if one individual key is lost, no ether is lost.
-* An app can create its own token and only charge their users in its internal currency for any ethereum transaction. The currency units can be rounded so it looks more similar to to actual amount of transactions: a standard transaction always costs 1 token, a very complex transaction costs exactly 2, etc. Since the app is the issuer of the transactions, they can do their own Sybil verifications and give a free amount of currency units to new users to get them started.
+* An app can create its own token and only charge their users in its internal currency for any ethereum transaction. The currency units can be rounded so it looks more similar to actual amount of transactions: a standard transaction always costs 1 token, a very complex transaction costs exactly 2, etc. Since the app is the issuer of the transactions, they can do their own Sybil verifications and give a free amount of currency units to new users to get them started.
 * A game company creates games with a traditional monthly subscription, either by credit card or platform-specific microtransactions. Private keys never leave the device and keep no ether and only the public accounts are sent to the company. The game then signs transactions on the device with gas price 0, sends them to the game company which checks who is an active subscriber and batches all transactions and pays the ether themselves. If the company goes bankrupt, the gamers themselves can set up similar subscription systems or just increase the gas price. End result is a **ethereum based game in which gamers can play by spending apple, google or xbox credits**.
 * A standard token is created that doesn’t require its users to have ether, and instead allows tokens to be transferred by paying in tokens. A wallet is created that signs messages and send them via whisper to the network, where other nodes can compete to download the available transactions, check the current gas price, and select those who are paying enough tokens to cover the cost. **The result is a token that the end users never need to keep any ether and can pay fees in the token itself.**
 * A DAO is created with a list of accounts of their employees. Employees never need to own ether, instead they sign messages, send them to whisper to a decentralized list of relayers which then deploy the transactions. The DAO contract then checks if the transaction is valid and sends ether to the deployers. Employees have an incentive not to use too many of the companies resources because they’re identifiable.  The result is that the users of the DAO don't need to keep ether, and **the contract ends up paying for it's own gas usage**.

ERCS/erc-1078.md

@@ -12,12 +12,12 @@ requires: 191, 681, 725, 1077
 
 ## Abstract
 
-This presents a method to replace the usual signup/login design pattern with a minimal ethereum native scheme, that doesn’t require passwords, backing up private keys nor typing seed phrases. From the user point of view it will be very similar to patterns they’re already used to with second factor authentication (without relying in a central server), but for dapp developers it requires a new way to think about ethereum transactions.
+This presents a method to replace the usual signup/login design pattern with a minimal ethereum native scheme, that doesn’t require passwords, backing up private keys nor typing seed phrases. From the user's point of view it will be very similar to patterns they’re already used to with second factor authentication (without relying in a central server), but for dapp developers it requires a new way to think about ethereum transactions.
 
 
 ## Simple Summary
 
-The unique identifier of the user is a contract which implements both Identity and the Executable Signed Messages ERCs. The user should not need provide this address directly, only a ens name pointing to it. These types of contracts are indirectly controlled by private keys that can sign messages indicating intents, which are then deployed to the contract by a third party (or a decentralized network of deployers).  
+The unique identifier of the user is a contract that implements both Identity and the Executable Signed Messages ERCs. The user should not need provide this address directly, only a ens name pointing to it. These types of contracts are indirectly controlled by private keys that can sign messages indicating intents, which are then deployed to the contract by a third party (or a decentralized network of deployers).  
 
 In this context, therefore, a device "logging into" an app using an identity, means that the device will generate a private key locally and then request an authorization to add that key as one of the signers of that identity, with a given set of permissions. Since that private key is only used for signing messages, it is not required to hold ether, tokens or assets, and if lost, it can be simply be replaced by a new one – the user's funds are kept on the identity contract.
 

ERCS/erc-1123.md

@@ -1593,7 +1593,7 @@ A URI in the format `blockchain://<chain_id>/block/<block_hash>`
 -   `block_hash` is the unprefixed hexadecimal representation of the
     hash of a block on the chain.
 
-A chain is considered to match a chain definition if the the genesis
+A chain is considered to match a chain definition if the genesis
 block hash matches the `chain_id` and the block defined by `block_hash`
 can be found on that chain. It is possible for multiple chains to match
 a single URI, in which case all chains are considered valid matches

ERCS/erc-1132.md

@@ -111,7 +111,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
 ```solidity
 /**
   * @dev Returns unlockable tokens for a specified address for a specified reason
-  * @param _of The address to query the the unlockable token count of
+  * @param _of The address to query the unlockable token count of
   * @param _reason The reason to query the unlockable tokens for
   */
   function tokensUnlockable(address _of, bytes32 _reason) public view returns (uint256 amount)
@@ -120,7 +120,7 @@ function totalBalanceOf(address _of)  view returns (uint256 amount)
 ```solidity
 /**
   * @dev Gets the unlockable tokens of a specified address
-  * @param _of The address to query the the unlockable token count of
+  * @param _of The address to query the unlockable token count of
   */
   function getUnlockableTokens(address _of) public view returns (uint256 unlockableTokens)
 ```

ERCS/erc-1444.md

@@ -135,7 +135,7 @@ Text with 2 or more arguments SHOULD use the POSIX parameter field extension.
 
 `bytes32` is very efficient since it is the EVM's base word size. Given the enormous number of elements (card(A) > 1.1579 × 10<sup>77</sup>), it can embed nearly any practical signal, enum, or state. In cases where an application's key is longer than `bytes32`, hashing that long key can map that value into the correct width.
 
-Designs that use datatypes with small widths than `bytes32` (such as `bytes1` in [ERC-1066](./eip-1066.md)) can be directly embedded into the larger width. This is a trivial one-to-one mapping of the smaller set into the the larger one.
+Designs that use datatypes with small widths than `bytes32` (such as `bytes1` in [ERC-1066](./eip-1066.md)) can be directly embedded into the larger width. This is a trivial one-to-one mapping of the smaller set into the larger one.
 
 ### Local vs Globals and Singletons
 

ERCS/erc-2019.md

@@ -218,7 +218,7 @@ Emitted when a given player, operator, company or a given persona, has been appr
 | Parameter | Description |
 | ---------|-------------|
 | walletToFund | The wallet that the player is allowed to start funding requests |
-| orderer | The address that allows the the player to start requests. |
+| orderer | The address that allows the player to start requests. |
 
 #### FundOperatorRevoked
 
@@ -227,7 +227,7 @@ Emitted when a given player has been revoked initiate funding requests.
 | Parameter | Description |
 | ---------|-------------|
 | walletToFund | The wallet that the player is allowed to start funding requests |
-| orderer | The address that allows the the player to start requests. |
+| orderer | The address that allows the player to start requests. |
 
 ## Rationale
 This standards provides a functionality to allow token holders to start funding requests in a decentralized way.

ERCS/erc-2021.md

@@ -249,7 +249,7 @@ Emitted when a given player, operator, company or a given persona, has been appr
 | Parameter | Description |
 | ---------|-------------|
 | walletToBePaidOut | The wallet that the player is allowed to start payout requests |
-| orderer |The address that allows the the player to start requests. |
+| orderer |The address that allows the player to start requests. |
 
 #### PayoutOperatorRevoked
 
@@ -258,7 +258,7 @@ Emitted when a given player has been revoked initiate payout requests.
 | Parameter | Description |
 | ---------|-------------|
 | walletToBePaidOut | The wallet that the player is allowed to start payout requests |
-| orderer |The address that allows the the player to start requests. |
+| orderer |The address that allows the player to start requests. |
 
 ## Rationale
 This standards provides a functionality to allow token holders to start payout requests in a decentralized way.

ERCS/erc-2135.md

@@ -157,7 +157,7 @@ Compliant contracts should pay attention to the balance change when a token is c
 When the contract is being paused, or the user is being restricted from transferring a token,
 the consumeability should be consistent with the transferral restriction.
 
-Compliant contracts should also carefully define access control, particularlly whether any EOA or contract account may or may not initiate a `consume` method in their own use case.
+Compliant contracts should also carefully define access control, particularly whether any EOA or contract account may or may not initiate a `consume` method in their own use case.
 
 Security audits and tests should be used to verify that the access control to the `consume`
 function behaves as expected.

ERCS/erc-2304.md

@@ -12,7 +12,7 @@ requires: 137
 
 ## Abstract
 
-This EIP introduces new overloads for the the `addr` field for ENS resolvers, which permit resolution of addresses for other blockchains via ENS.
+This EIP introduces new overloads for the `addr` field for ENS resolvers, which permit resolution of addresses for other blockchains via ENS.
 
 ## Motivation