Merge branch 'ethereum:master' into master

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-4626.md

@@ -576,7 +576,7 @@ For production implementations of Vaults which do not use EIP-4626, wrapper adap
 
 ## Reference Implementation
 
-See [Solmate EIP-4626](https://github.com/Rari-Capital/solmate/blob/main/src/mixins/ERC4626.sol):
+See [Solmate EIP-4626](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol):
 a minimal and opinionated implementation of the standard with hooks for developers to easily insert custom logic into deposits and withdrawals.
 
 See [Vyper EIP-4626](https://github.com/fubuloubu/ERC4626):

ERCS/erc-5173.md

@@ -317,14 +317,14 @@ Any realized profits (P) when an NFT is sold are distributed among the buyers/ow
 
 We define a sliding window mechanism to decide which previous owners will be involved in the profit distribution. Let's imagine the owners as a queue starting from the first hand owner to the current owner. The profit distribution window starts from the previous owner immediately to the current owner and extends towards the first owner, and the size of the windows is fixed. Only previous owners located inside the window will join the profit distribution.  
 
-![Future Rewards calculation formula](../assets/eip-5173/nFR_distribution_formula.png?raw=true)
+![Future Rewards calculation formula](../assets/eip-5173/nFR_distribution_formula.jpg?raw=true)
 
 In this equation:
 
 - P is the total profit, the difference between the selling price minus the buying price;
-- r is buyer reward ratio of the total P;
-- g is the common ratio of successive in the geometric sequence;
-- n is the actual number of owners eligible and participating in the future rewards sharing. To calculate n, we have n = min(m, w), where m is the current number of owners for a token, and w is the window size of the profit distribution sliding window algorithm
+- _R_ is buyer reward ratio of the total P;
+- _g_ is the common ratio of successive in the geometric sequence;
+- _n_ is the actual number of owners eligible and participating in the future rewards sharing. To calculate _n_, we have _n_ = min(_m_, _w_), where _m_ is the current number of owners for a token, and _w_ is the window size of the profit distribution sliding window algorithm
 
 #### Converting into Code
 
@@ -334,7 +334,7 @@ pragma solidity ^0.8.0;
 //...
 
 /* Assumes usage of a Fixed Point Arithmetic library (prb-math) for both int256 and uint256, and OpenZeppelin Math utils for Math.min. */
-function _calculateFR(uint256 P, uint256 r, uint256 g, uint256 m, uint256 w) pure internal virtual returns(uint256[] memory) {
+function _calculateFR(uint256 p, uint256 r, uint256 g, uint256 m, uint256 w) pure internal virtual returns(uint256[] memory) {
         uint256 n = Math.min(m, w);
         uint256[] memory FR = new uint256[](n);
 
@@ -344,11 +344,11 @@ function _calculateFR(uint256 P, uint256 r, uint256 g, uint256 m, uint256 w) pur
             if (successiveRatio != 1e18) {
                 int256 v1 = 1e18 - int256(g).powu(n);
                 int256 v2 = int256(g).powu(i - 1);
-                int256 v3 = int256(P).mul(int256(r));
+                int256 v3 = int256(p).mul(int256(r));
                 int256 v4 = v3.mul(1e18 - int256(g));
                 pi = uint256(v4 * v2 / v1);
             } else {
-                pi = P.mul(r).div(n);
+                pi = p.mul(r).div(n);
             }
 
             FR[i - 1] = pi;