Merge branch 'master' into erc-sig

.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/erc-1066.md

@@ -236,7 +236,7 @@ Currently unspecified. (Full range reserved)
 
 #### `0x7*` TBD
 
-Currently unspecifie. (Full range reserved)
+Currently unspecified. (Full range reserved)
 
 #### `0x8*` TBD
 

ERCS/erc-1077.md

@@ -85,7 +85,7 @@ 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 the reward.
 
-The [EIP-191] message must be constructed as following:
+The [EIP-191] message must be constructed as follows:
 ```solidity
 keccak256(
 	abi.encodePacked(

ERCS/erc-1081.md

@@ -28,7 +28,7 @@ After studying bounties as they've existed for thousands of years (and after imp
 To implement these steps, a number of functions are needed:
 - `initializeBounty(address _issuer, address _arbiter, string _data, uint _deadline)`: This is used when deploying a new StandardBounty contract, and is particularly useful when applying the proxy design pattern, whereby bounties cannot be initialized in their constructors. Here, the data string should represent an IPFS hash, corresponding to a JSON object which conforms to the schema (described below).
 - `fulfillBounty(address[] _fulfillers, uint[] _numerators, uint _denomenator, string _data)`: This is called to submit a fulfillment, submitting a string representing an IPFS hash which contains the deliverable for the bounty. Initially fulfillments could only be submitted by one individual at a time, however users consistently told us they desired to be able to collaborate on fulfillments, thereby allowing the credit for submissions to be shared by several parties. The lines along which eventual payouts are split are determined by the fractions of the submission credited to each fulfiller (using the array of numerators and single denominator). Here, a bounty platform may also include themselves as a collaborator to collect a small fee for matching the bounty with fulfillers.
-- `acceptFulfillment(uint _fulfillmentId, StandardToken[] _payoutTokens, uint[] _tokenAmounts)`: This is called by the `issuer` or the `arbiter` to pay out a given fulfillment, using an array of tokens, and an array of amounts of each token to be split among the contributors. This allows for the bounty payout amount to move as it needs to based on incoming contributions (which may be transferred directly to the contract address). It also allows for the easy splitting of a given bounty's balance among several fulfillments, if the need should arise.
+- `acceptFulfillment(uint _fulfillmentId, StandardToken[] _payoutTokens, uint[] _tokenAmounts)`: This is called by the `issuer` or the `arbiter` to pay out a given fulfillment, using an array of tokens, and an array of amounts of each token to be split among the contributors. This allows for the bounty payout amount to move as it needs to be based on incoming contributions (which may be transferred directly to the contract address). It also allows for the easy splitting of a given bounty's balance among several fulfillments, if the need should arise.
    - `drainBounty(StandardToken[] _payoutTokens)`: This may be called by the `issuer` to drain a bounty of it's funds, if the need should arise.
 - `changeBounty(address _issuer, address _arbiter, string _data, uint _deadline)`: This may be called by the `issuer` to change the `issuer`, `arbiter`, `data`, and `deadline` fields of their bounty.
 - `changeIssuer(address _issuer)`: This may be called by the `issuer` to change to a new `issuer` if need be

ERCS/erc-3770.md

@@ -12,8 +12,8 @@ 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