Merge branch 'ethereum:master' into master

.github/workflows/jekyll-label-bot.yml

@@ -14,7 +14,7 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-      - uses: Pandapip1/jekyll-label-action@d0fd82c3cd118140a50843906845fca8e59a8b9e
+      - uses: Pandapip1/jekyll-label-action@4b7cce7588a8686f5146a8e12aab7269042057ce
         with:
           token: ${{ secrets.GITHUB_TOKEN }}
           config-path: config/.jekyll-labels.yml

.github/workflows/stale.yml

@@ -20,16 +20,16 @@ jobs:
         repo-token: ${{ secrets.GITHUB_TOKEN }}
         ascending: true # Since we have so many issues, the stale bot finds it hard to keep track. This makes sure that at least the oldest are removed.
         # Issue config
-        stale-issue-message: There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.
+        stale-issue-message: There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity. 
         close-issue-message: This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback.
-        days-before-issue-stale: 7
-        days-before-issue-close: 49 # 49 + 7 weeks = 3 months
+        days-before-issue-stale: 183
+        days-before-issue-close: 190
         exempt-issue-labels: discussions-to
         stale-issue-label: w-stale
         # PR config
-        stale-pr-message: There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
+        stale-pr-message: There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
         close-pr-message: This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.
-        days-before-pr-stale: 14
-        days-before-pr-close: 42 # 42 + 14 weeks = 3 months
+        days-before-pr-stale: 183
+        days-before-pr-close: 190
         exempt-pr-milestones: "Manual Merge Queue"
         stale-pr-label: w-stale

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

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.
 
@@ -43,7 +43,7 @@ If the user doesn’t have an identity, the app should provide the option to cre
 
 All those steps can be designed to be set up in a single ethereum transaction. Since this step is not free, the app reserves the right to charge for registering users, or require the user to be verified in a sybil resistant manner of the app’s choosing (captcha, device ID registration, proof of work, etc)
 
-The user shouldn’t be forced to wait for transaction confirmation times. Instead, have an indicator somewhere on the app the shows the progress and then allow the user to interact with your app normally. It’s unlikely that they’ll need the identity in the first few minutes and if something goes wrong (username gets registered at the same time), you can then ask the user for an action.
+The user shouldn’t be forced to wait for transaction confirmation times. Instead, have an indicator somewhere on the app that shows the progress and then allow the user to interact with your app normally. It’s unlikely that they’ll need the identity in the first few minutes and if something goes wrong (username gets registered at the same time), you can then ask the user for an action.
 
 **Implementation note:** in order to save gas, some of these steps can be done in advance. The app can automatically deploy a small number of contracts when the gas price is low, and set up all their main variables to be 0xFFFFFF...FFFFF. These should be considered ‘vacant’ and when the user registers one, they will get a gas discount for freeing up space on the chain. This has the added benefit of allowing the user a choice in contract address/icon.
 

ERCS/erc-1129.md

@@ -49,9 +49,9 @@ struct Announcement{
 
 
 ### Methods
-#### the number of ammouncements
+#### the number of announcements
 
-Returns the number of announcement currently active.
+Returns the number of announcements currently active.
 
 OPTIONAL - this method can be used to provide quicker information for the UI, but could also be retrieved from `numberOfMessages` variable.
 

ERCS/erc-3770.md

@@ -4,16 +4,16 @@ title: Chain-specific addresses
 description: Prepending chain-specific addresses with a human-readable chain identifier
 author: Lukas Schor (@lukasschor), Richard Meissner (@rmeissner), Pedro Gomes (@pedrouid), ligi <ligi@ligi.de>
 discussions-to: https://ethereum-magicians.org/t/chain-specific-addresses/6449
-status: Stagnant
+status: Draft
 type: Standards Track
 category: ERC
 created: 2021-08-26
 ---
 
 ## Abstract
 
-[ERC-3770](./eip-3770.md) introduces a new address standard to be adapted by wallets and dApps to display chain-specific addresses by using a human-reacable prefix.
-  
+[ERC-3770](./eip-3770.md) introduces a new address standard to be adapted by wallets and dApps to display chain-specific addresses by using a human-readable prefix.
+
 ## Motivation
 
 The need for this proposal emerges from the increasing adoption of non-Ethereum Mainnet chains that use the Ethereum Virtual Machine (EVM). In this context, addresses become ambiguous, as the same address may refer to an EOA on chain X or a smart contract on chain Y. This will eventually lead to Ethereum users losing funds due to human error. For example, users sending funds to a smart contract wallet address which was not deployed on a particular chain.
@@ -36,13 +36,8 @@ Chain-specific address = "`shortName`" "`:`" "`address`"
 
 ### Semantics
 
-```
-
-`shortName` is mandatory and MUST be a valid chain short name from https://github.com/ethereum-lists/chains
-  
-`address` is mandatory and MUST be a [ERC-55](./eip-55.md) compatible hexadecimal address
-
-```
+* `shortName` is mandatory and MUST be a valid chain short name from https://github.com/ethereum-lists/chains
+* `address` is mandatory and MUST be a [ERC-55](./eip-55.md) compatible hexadecimal address
 
 ### Examples
 
@@ -58,7 +53,7 @@ Ethereum addresses without the chain specifier will continue to require addition
 
 ## Security Considerations
 
-The Ethereum List curators must consider how similar looking chain short names can be used to confuse users.
+Similar looking chain short names can be used to confuse users.
 
 ## Copyright