Merge branch 'ethereum:master' into master

ERCS/erc-1077.md

@@ -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-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-2309.md

@@ -88,7 +88,7 @@ Standardizing the `ConsecutiveTransfer` event gives decentralized platforms a st
 
 Take this example. I sell magical fruit and have a farm with 10,000 magical fruit trees each with different fruit and 1,000 new trees every few years. I want to turn each tree into a non-fungible token that people can own. Each person that owns one of my non-fungible tree tokens will receive a quarterly percentage of each harvest from that tree. The problem is that I would need to create and transfer each of these tokens individually - which will cost me a lot of time and money and frankly would keep me from doing this.
 
-With this extension I would be able to to mint my initial 10,000  tree tokens in one transaction. I would be able to quickly and cheaply mint my additional 1,000  tree tokens when a new batch is planted. I would then be able to transfer all of the 10,000+ tree tokens to a special smart contract that keeps track of the selling and distribution of funds in one transaction all while adhering to a specified standard.
+With this extension I would be able to mint my initial 10,000  tree tokens in one transaction. I would be able to quickly and cheaply mint my additional 1,000  tree tokens when a new batch is planted. I would then be able to transfer all of the 10,000+ tree tokens to a special smart contract that keeps track of the selling and distribution of funds in one transaction all while adhering to a specified standard.
 
 **Rationale to have a single event that covers minting, burning, and transferring**
 

ERCS/erc-2615.md

@@ -229,7 +229,7 @@ Powered by Truffle and Openzeppelin test helper.
 
 ## Implementation
 
-[Github Reposotory](https://github.com/kohshiba/ERC-X).
+[Github Repository](https://github.com/kohshiba/ERC-X).
 
 ## Security Considerations
 

ERCS/erc-3448.md

@@ -182,7 +182,7 @@ function getMetadataWithoutCall () public pure returns (
 ```solidity
 /// @notice Returns the metadata of this (MetaProxy) contract.
 /// Only relevant with contracts created via the MetaProxy standard.
-/// @dev This function is aimed to to be invoked via a call.
+/// @dev This function is aimed to be invoked via a call.
 function getMetadataViaCall () public pure returns (
   address a,
   uint256 b,

ERCS/erc-4337.md

@@ -683,15 +683,19 @@ Still, it might require putting a "semi-valid" signature (e.g. a signature in th
 **Return Values:**
 
 * **preVerificationGas** gas overhead of this UserOperation
-* **verificationGasLimit** actual gas used by the validation of this UserOperation
-* **callGasLimit** value used by inner account execution
-* **paymasterVerificationGasLimit** value used for paymaster verification (if paymaster exists in the UserOperation)
-* **paymasterPostOpGasLimit** value used for paymaster post op execution (if paymaster exists in the UserOperation)
+* **verificationGasLimit** estimation of gas limit required by the validation of this UserOperation
+* **paymasterVerificationGasLimit** estimation of gas limit required by the paymaster verification, if the
+  UserOperation defines a Paymaster address
+* **callGasLimit** estimation of gas limit required by the inner account execution
+
+**Note:** actual `postOpGasLimit` cannot be reliably estimated. Paymasters should provide this value to account,
+  and require that specific value on-chain.
 
 ##### Error Codes:
 
 Same as `eth_sendUserOperation`
-This operation may also return an error if the inner call to the account contract reverts.
+This operation may also return an error if either the inner call to the account contract reverts,
+or paymaster's `postOp` call reverts.
 
 #### * eth_getUserOperationByHash
 

ERCS/erc-4527.md

@@ -127,7 +127,7 @@ chain-code-bytes = bytes .size 32
 
 If the chain-code is provided, then it can be used to derive child keys but if it isn’t provided, it is simply a solo key and the origin can be provided to indicate the derivation key path.
 
-If the signer would like to provide muliple public keys instead of the extended public key for any reason, the signer can use `crypto-account` for that.
+If the signer would like to provide multiple public keys instead of the extended public key for any reason, the signer can use `crypto-account` for that.
 
 ### Sending the unsigned data from the watch-only wallet to the offline signer
 

ERCS/erc-5023.md

@@ -28,7 +28,7 @@ Typical NFT standards such as EIP-721 and EIP-1155 do not define a sharing modal
 
 Sharing is an interesting concept as it can be thought and perceived in different ways. For example, when we talk about sharing we can think about it is as digital copying, giving a copy of a digital resource while retaining a version by ourselves. Sharing can also be fractional or sharing could be about giving rights to use a certain resource. The concept of shareability and the context of shareability can take different forms and one might use different types of implementatins for instances of shareable tokens. Hence we haven't restricted that the interface should require any specific token type.
 
-Shareable tokens can be made non-transferable at the contract implementaiton level. Doing so, makes them shareable non-transferable tokens. In the reference implementation we have distilled a general case from our use cases that defines a shareable non-transferable NFTs using the shareable NFT interface.
+Shareable tokens can be made non-transferable at the contract implementation level. Doing so, makes them shareable non-transferable tokens. In the reference implementation we have distilled a general case from our use cases that defines a shareable non-transferable NFTs using the shareable NFT interface.
 
 We believe that the wider audience should benefit from an abstraction level higher definition for shareability, such as this interface implementation, that defines minimum amount of functions that would be implemented to satisfy the concept of shareability.
 
@@ -49,11 +49,11 @@ interface IERC5023 is IERC165 {
 } 
 ```
 
-The Share event is expected to be emitted when function method share is succesfully called and a new token on basis of a given token id is minted and transferred to a recipient.
+The Share event is expected to be emitted when function method share is successfully called and a new token on basis of a given token id is minted and transferred to a recipient.
 
 ## Rationale
 
-Current NFT standards define transferable non-fungible tokens, but not shareable non-fungible tokens. To be able to create shareable NFTs we see that existing NFT contracts could be extended with an interface which defines the basic principles of sharing, namely the Event of sharing and the function method of sharing. Definition of how transferability of tokens should be handled is left to the contract implementor. In case transfering is left enable shareable tokens behave similarily to the existing tokens, except when they are shared, a version of token is retained. In case transfering is disabled, shareable tokens become shareable non-transferable tokens, where they can be minted and given or shared to other people, but they cannot be transferred away.
+Current NFT standards define transferable non-fungible tokens, but not shareable non-fungible tokens. To be able to create shareable NFTs we see that existing NFT contracts could be extended with an interface which defines the basic principles of sharing, namely the Event of sharing and the function method of sharing. Definition of how transferability of tokens should be handled is left to the contract implementor. In case transferring is left enable shareable tokens behave similarly to the existing tokens, except when they are shared, a version of token is retained. In case transfering is disabled, shareable tokens become shareable non-transferable tokens, where they can be minted and given or shared to other people, but they cannot be transferred away.
 
 Imagine that Bob works together with Alice on a project. Bob earns an unique NFT indicating that he has made effort to the project, but Bob feels that his accomplishments are not only out of his own accord. Bob wants to share his token with Alice to indicate that also Alice deserves recognition of having put effort on their project. Bob initiates token sharing by calling `Share` method on the contract which has his token and indicates which one of his tokens he wishes to share and to whom by passing address and token id parameters. A new token is minted for Alice and a `Share` event is initiated to communicate that it was Bob whom shared his token to Alice by logging addresses who shared a token id to whose address and which token id was this new token derived from.
 

ERCS/erc-5189.md

@@ -305,14 +305,14 @@ The payment is always made in the `feeToken`, which can be any token standard (E
 
 All units are expressed in the native token unit. The result of the fee calculation is then converted to the `feeToken` unit using the `feeScalingFactor` and `feeNormalizationFactor`.
 
-The gas units consider a fixed amount of gas (`fixedGas`) and a variable amount of gas (`gasLimit`). Allowing fixed costs caters for gas overheads which may be outside the scope of the on chain execution, such as calldata fees. This also allows repayment to be reduce when execution is cheaper than expected (such as when an inner call fails without reverting the top-level transaction), while still repaying the bundler.
+The gas units consider a fixed amount of gas (`fixedGas`) and a variable amount of gas (`gasLimit`). Allowing fixed costs caters for gas overheads which may be outside the scope of the on chain execution, such as calldata fees. This also allows repayment to be reduced when execution is cheaper than expected (such as when an inner call fails without reverting the top-level transaction), while still repaying the bundler.
 
 The expected gas repayment is calculated as follows:
 
 ```
 gasUnits = op.fixedGas + Min(gasUsed, op.gasLimit)
 feePerGas = Min(op.maxFeePerGas, block.baseFee + op.priorityFeePerGas)
-expectedRepayment = (gasUsed * feePerGas * op.feeScalingFactor) / op.feeNormalizationFactor
+expectedRepayment = (gasUnits * feePerGas * op.feeScalingFactor) / op.feeNormalizationFactor
 ```
 
 While the `endorser` MUST guarantee the repayment of `expectedRepayment`, the actual repayment amount MAY exceed this fee. E.g. For ease of development, a bundler MAY choose to only endorse operations that repay the maximum values provided by the operation.

ERCS/erc-5252.md

@@ -13,7 +13,7 @@ requires: 20, 721, 1155, 5114
 
 ## Abstract
 
-This EIP proposes a form of smart contract design pattern and a new type of account abstraction on how one's finance should be managed, ensuring transparency of managing investments and protection with self-sovereignty even from its financial operators. This EIP enables greater self-sovereignty of one's assets using a personal finance contract for each individual. The seperation between an investor's funds and the operation fee is clearly specified in the personal smart contract, so investors can ensure safety from arbitrary loss of funds by the operating team's control.
+This EIP proposes a form of smart contract design pattern and a new type of account abstraction on how one's finance should be managed, ensuring transparency of managing investments and protection with self-sovereignty even from its financial operators. This EIP enables greater self-sovereignty of one's assets using a personal finance contract for each individual. The separation between an investor's funds and the operation fee is clearly specified in the personal smart contract, so investors can ensure safety from arbitrary loss of funds by the operating team's control.
 
 This EIP extends [ERC-5114](./eip-5114.md) to further enable transferring fund to other accounts for mobility between managing multiple wallets.