Merge branch 'master' into openmind-erc

ERCS/erc-6734.md

@@ -4,11 +4,11 @@ title: L2 Token List
 description: Token List that ensures the correct identification of tokens from different Layer 1, Layer 2, or Sidechains.
 author: Kelvin Fichter (@smartcontracts), Andreas Freund (@Therecanbeonlyone1969), Pavel Sinelnikov (@psinelnikov)
 discussions-to: https://ethereum-magicians.org/t/canonical-token-list-standard-from-the-eea-oasis-community-projects-l2-standards-working-group/13091
-status: Draft
+status: Review
 type: Standards Track
 category: ERC
 created: 2023-03-20
-requires: 155, 3220
+requires: 155
 ---
 
 ## Abstract
@@ -133,12 +133,7 @@ The chainId property utilized MUST allow for the requirements of the [EIP-155](.
 
 Namely, transaction replay protection on the network that is identified by the chainId property value. Note, that for replay protection to be guaranteed, the chainId should be unique. Ensuring a unique chainId is beyond the scope of this document.
 
-[[R4]](#r4) testability: EIP-155 requires that a transaction hash is derived from the keccak256 hash of the following nine RLP encoded elements `(nonce, gasprice, startgas, to, value, data, chainid, 0, 0)` which can be tested easily with existing cryptographic libraries. EIP-155 further requires that the `v` value of the secp256k1 signature must be set to `{0,1} + CHAIN_ID * 2 + 35` where `{0,1}` is the parity of the `y` value of the curve point for which the signature `r`-value is the `x`-value in the secp256k1 signing process. This requirement is testable with available open-source secp256k1 digital signature suites. Therefore, [[R4]](#r4) is testable. 
-
-<a name="d2"> **[D2]** </a>
-The `chainId` property SHOULD follow [EIP-3220](./eip-3220.md) draft standard.
-
-[[D2]](#d2) testability: The [EIP-3220](./eip-3220.md) draft standard can be tested because the crosschain id is specified as a concatenation of well-defined strings, and using open source tooling can be used to parse and split a crosschain id, the obtained string segments can be compared against expected string lengths, and context dependent, the values for the strings specified in the standard. Consequently, [[D2]](#d2) is testable.
+[[R4]](#r4) testability: EIP-155 requires that a transaction hash is derived from the keccak256 hash of the following nine RLP encoded elements `(nonce, gasprice, startgas, to, value, data, chainid, 0, 0)` which can be tested easily with existing cryptographic libraries. EIP-155 further requires that the `v` value of the secp256k1 signature must be set to `{0,1} + CHAIN_ID * 2 + 35` where `{0,1}` is the parity of the `y` value of the curve point for which the signature `r`-value is the `x`-value in the secp256k1 signing process. This requirement is testable with available open-source secp256k1 digital signature suites. Therefore, [[R4]](#r4) is testable.
 
 <a name="o1"> **[O1]** </a>
 The `humanReadableTokenSymbol` property MAY be used.
@@ -491,10 +486,10 @@ This document defines the conformance levels of a canonical token list as follow
 * **Level 2:** All MUST and SHOULD requirements are fulfilled by a specific implementation as proven by a test report that proves in an easily understandable manner the implementation's conformance with each requirement based on implementation-specific test-fixtures with implementation-specific test-fixture inputs.
 * **Level 3:** All MUST, SHOULD, and MAY requirements with conditional MUST or SHOULD requirements are fulfilled by a specific implementation as proven by a test report that proves in an easily understandable manner the implementation's conformance with each requirement based on implementation-specific test-fixtures with implementation-specific test-fixture inputs.
 
-<a name="d3"> **[D3]** </a> 
+<a name="d2"> **[D2]** </a> 
 A claim that a canonical token list implementation conforms to this specification SHOULD describe a testing procedure carried out for each requirement to which conformance is claimed, that justifies the claim with respect to that requirement.
 
-[[D3]](#d3) testability: Since each of the non-conformance-target requirements in this documents is testable, so must be the totality of the requirements in this document. Therefore, conformance tests for all requirements can exist, and can be described as required in [[D3]](#d3).
+[[D2]](#d2) testability: Since each of the non-conformance-target requirements in this documents is testable, so must be the totality of the requirements in this document. Therefore, conformance tests for all requirements can exist, and can be described as required in [[D2]](#d2).
 
 <a name="r5"> **[R5]** </a> 
 A claim that a canonical token list implementation conforms to this specification at **Level 2** or higher MUST describe the testing procedure carried out for each requirement at **Level 2** or higher, that justifies the claim to that requirement.

ERCS/erc-6909.md

@@ -4,7 +4,7 @@ title: Minimal Multi-Token Interface
 description: A minimal specification for managing multiple tokens by their id in a single contract.
 author: JT Riley (@jtriley-eth), Dillon (@d1ll0n), Sara (@snreynolds), Vectorized (@Vectorized), Neodaoist (@neodaoist)
 discussions-to: https://ethereum-magicians.org/t/eip-6909-multi-token-standard/13891
-status: Draft
+status: Review
 type: Standards Track
 category: ERC
 created: 2023-04-19

ERCS/erc-7007.md

@@ -4,8 +4,7 @@ title: Verifiable AI-Generated Content Token
 description: An ERC-721 extension for verifiable AI-generated content tokens using Zero-Knowledge and Optimistic Machine Learning techniques
 author: Cathie So (@socathie), Xiaohang Yu (@xhyumiracle), Conway (@0x1cc), Lee Ting Ting (@tina1998612), Kartin <kartin@hyperoracle.io>
 discussions-to: https://ethereum-magicians.org/t/eip-7007-zkml-aigc-nfts-an-erc-721-extension-interface-for-zkml-based-aigc-nfts/14216
-status: Last Call
-last-call-deadline: 2024-09-30
+status: Final
 type: Standards Track
 category: ERC
 created: 2023-05-10
@@ -233,4 +232,4 @@ In the opML scenario, it is important to consider that the `aigcData` might chan
 
 ## Copyright
 
-Copyright and related rights waived via [CC0](../LICENSE.md).
+Copyright and related rights waived via [CC0](../LICENSE.md).

ERCS/erc-7578.md

@@ -104,15 +104,15 @@ interface IERC7578 {
      * @dev Does NOT revert if token doesn't exist
      * @param tokenId The token ID of the minted token
      */
-    function getProperties(uint256 tokenId) external view returns (Properties memory properties);
+    function getPropertiesOf(uint256 tokenId) external view returns (Properties memory properties);
 }
 ```
 
 When `properties` are set, the `PropertiesSet(uint256 indexed tokenId, Properties properties)` event is emitted.
 
 When `properties` are removed, the `PropertiesRemoved(uint256 indexed tokenId)` event is emitted.
 
-The `getProperties(uint256 tokenId)` function MUST return the unique `properties` of a token. If the ERC-721 token is burned or has no properties set, it SHOULD return an empty `Properties` struct.
+The `getPropertiesOf(uint256 tokenId)` function MUST return the unique `properties` of a token. If the ERC-721 token is burned or has no properties set, it SHOULD return an empty `Properties` struct.
 
 ## Rationale
 
@@ -158,7 +158,7 @@ contract ERC7578 is ERC721, IERC7578 {
     /**
      * @inheritdoc IERC7578
      */
-    function getProperties(uint256 tokenId) public view override returns (Properties memory properties) {
+    function getPropertiesOf(uint256 tokenId) public view override returns (Properties memory properties) {
         properties = _properties[tokenId];
     }
 
@@ -172,7 +172,7 @@ contract ERC7578 is ERC721, IERC7578 {
      *
      * Emits a {PropertiesSet} event
      */
-    function _setProperties(uint256 tokenId, Properties calldata properties) internal {
+    function _setPropertiesOf(uint256 tokenId, Properties calldata properties) internal {
         _properties[tokenId] = Properties({
             tokenIssuer: properties.tokenIssuer,
             assetHolder: properties.assetHolder,
@@ -194,7 +194,7 @@ contract ERC7578 is ERC721, IERC7578 {
      *
      * Emits a {PropertiesRemoved} event
      */
-    function _removeProperties(uint256 tokenId) internal {
+    function _removePropertiesOf(uint256 tokenId) internal {
         delete _properties[tokenId];
         emit PropertiesRemoved(tokenId);
     }
@@ -207,7 +207,7 @@ contract ERC7578 is ERC721, IERC7578 {
     function _update(address to, uint256 tokenId, address auth) internal virtual override returns (address) {
         address from = _ownerOf(tokenId);
         if (to == address(0)) {
-            _removeProperties(tokenId);
+            _removePropertiesOf(tokenId);
         } else if (from == address(0)) {
             if (bytes(_properties[tokenId].tokenIssuer).length == 0) revert PropertiesUninitialized();
         }
@@ -219,7 +219,7 @@ contract ERC7578 is ERC721, IERC7578 {
 
 ## Security Considerations
 
-To ensure the authenticity of a token's properties, the `_setProperties()` method should only be called inside a method that is restricted to a trusted Externally Owned Account (EOA) or contract. This trusted entity must verify that the properties accurately reflect the real physical attributes of the token.
+To ensure the authenticity of a token's properties, the `_setPropertiesOf()` method should only be called inside a method that is restricted to a trusted Externally Owned Account (EOA) or contract. This trusted entity must verify that the properties accurately reflect the real physical attributes of the token.
 
 ## Copyright
 

ERCS/erc-7579.md

@@ -91,6 +91,13 @@ The account MAY also implement the following function in accordance with ERC-433
 function executeUserOp(PackedUserOperation calldata userOp, bytes32 userOpHash) external;
 ```
 
+If an account chooses to implement `executeUserOp`, this method SHOULD ensure the account executes `userOp.calldata` except 4 most significant bytes, which are reserved for `executeUserOp.selector` as per ERC-4337. Thus the `userOp.callData[4:]` should represent the calldata for a valid call to the account. It is RECOMMENDED that the account executes a `delegatecall` in order to preserve the original `msg.sender` to the account. 
+
+Example:
+```
+(bool success, bytes memory innerCallRet) = address(this).delegatecall(userOp.callData[4:]);
+```
+
 The execution mode is a `bytes32` value that is structured as follows:
 
 - callType (1 byte): `0x00` for a single `call`, `0x01` for a batch `call`, `0xfe` for `staticcall` and `0xff` for `delegatecall`
@@ -223,6 +230,9 @@ If the smart account has a fallback handler installed, it:
 - MUST route to fallback handlers based on the function selector of the calldata
 - MAY implement authorization control, which SHOULD be done via hooks 
 
+If the account adds features via fallback, these should be considered the same as if the account was implementing those features natively.
+ERC-165 support (see below) is one example of such an approach. Note, that it is only RECOMMENDED to implement view functions via fallback where this can lead to greater extensibility. It is NOT RECOMMENDED to implement core account logic via a fallback.
+
 #### ERC-165
 
 Smart accounts MUST implement ERC-165. However, for every interface function that reverts instead of implementing the functionality, the smart account MUST return `false` for the corresponding interface id.
@@ -268,6 +278,17 @@ interface IModule {
 }
 ```
 
+Note: A single module that is of multiple types MAY decide to pass `moduleTypeId` inside `data` to `onInstall` and/or `onUninstall` methods, so those methods are able to properly handle installation/uninstallation for various types.  
+Example:
+```solidity
+// Module.sol
+function onInstall(bytes calldata data) external {
+    // ...
+    (uint256 moduleTypeId, bytes memory otherData) = abi.decode(data, (uint256, bytes));
+    // ...
+}
+```
+
 #### Validators
 
 Validators MUST implement the `IModule` and the `IValidator` interface and have module type id: `1`.

ERCS/erc-7751.md

@@ -12,7 +12,7 @@ created: 2024-08-06
 
 ## Abstract
 
-This ERC proposes a standard for handling bubbled up reverts in Ethereum smart contracts using custom errors. This standard aims to improve the clarity and usability of revert reasons by allowing additional context to be passed alongside the raw bytes of the bubbled up revert. The custom errors should follow the naming structure `Wrap__` followed by a descriptive name and allow an arbitrary number of parameters, with the first being the address of the called contract and the second being the raw bytes of the bubbled up revert.
+This ERC proposes a standard for handling bubbled up reverts in Ethereum smart contracts using a dedicated custom error. This standard aims to improve the clarity and usability of revert reasons by allowing additional context to be passed alongside the raw bytes of the bubbled up revert. The `WrappedError` custom error should wrap reverts from called contracts and provide a consistent interface for parsing and handling reverts in tools like Etherscan or Tenderly.
 
 ## Motivation
 
@@ -22,20 +22,22 @@ Currently, when a smart contract calls another and the called contract reverts,
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
 
-1. **Custom Error Naming Convention:**
-   - Custom errors that bubble up reverts MUST be prefixed with `Wrap__`.
-   - Example: `Wrap__ERC20TransferFailed`.
-2. **Parameters:**
-   - The first parameter MUST be the address of the called contract that reverted.
-   - The second parameter MUST be the raw bytes of the bubbled up revert.
-   - Additional parameters MAY be included to provide context.
-   - Example: `Wrap__ERC20TransferFailed(address token, bytes reason, address recipient)`.
+In order to wrap a revert, a contract MUST revert with the following error that corresponds to the following signature `0x90bfb865`:
 
-If no additional parameters are defined and a generic call reverts, the custom error `Wrap__SubcontextReverted(address, bytes)` SHOULD be thrown to ensure a consistent signature.
+```solidity
+error WrappedError(address target, bytes4 selector, bytes reason, bytes details);
+```
+
+Where:
+
+- `target` is the address of the called contract that reverted.
+- `selector` is the selector of the called function that reverted. If the call was an ETH transfer without any data, the selector MUST be `bytes4(0)`
+- `reason` is the raw bytes of the revert reason.
+- `details` is optional additional context about the revert. In cases where no additional context is needed, the `details` bytes can be empty. In cases with additional context, the `details` bytes MUST be an ABI encoded custom error declared on the contract that emits the `WrappedError` error.
 
 ## Rationale
 
-By including the called contract, raw revert bytes and additional context, developers can provide more detailed information about the failure. Additionally, by standardizing the way reverts are bubbled up, it also enables nested bubbled up reverts where multiple reverts thrown by different contracts can be followed recursively. The reverts can also be parsed and handled by tools like Etherscan and Foundry to further enhance the readability and debuggability of smart contract interactions, as well as facilitating better error handling practices in general.
+By including the called contract and function, raw revert bytes and additional context, developers can provide more detailed information about the failure. Additionally, by standardizing the way reverts are bubbled up, it also enables nested bubbled up reverts where multiple reverts thrown by different contracts can be followed recursively. The reverts can also be parsed and handled by tools like Etherscan and Foundry to further enhance the readability and debuggability of smart contract interactions, as well as facilitating better error handling practices in general.
 
 ## Backwards Compatibility
 
@@ -64,7 +66,9 @@ contract Token {
 contract Vault {
     Token token;
 
-    error Wrap__ERC20TransferFailed(address token, bytes reason, address recipient);
+    error WrappedError(address target, bytes4 selector, bytes reason, bytes details);
+    error ERC20TransferFailed(address recipient);
+
 
     constructor(Token token_) {
         token = token_;
@@ -73,15 +77,15 @@ contract Vault {
     function withdraw(address to, uint256 amount) external {
         // logic
         try token.transfer(to, amount) {} catch (bytes memory error) {
-            revert Wrap__ERC20TransferFailed(address(token), error, to);
+            revert WrappedError(address(token), token.transfer.selector, error, abi.encodeWithSelector(ERC20TransferFailed.selector, to));
         }
     }
 }
 
 contract Router {
     Vault vault;
 
-    error Wrap__SubcontextReverted(address target, bytes reason);
+    error WrappedError(address target, bytes4 selector, bytes reason, bytes details);
 
     constructor(Vault vault_) {
         vault = vault_;
@@ -90,7 +94,7 @@ contract Router {
     function withdraw(uint256 amount) external {
         // logic
         try vault.withdraw(msg.sender, amount) {} catch (bytes memory error) {
-            revert Wrap__SubcontextReverted(address(vault), error);
+            revert WrappedError(address(vault), vault.withdraw.selector, error, "");
         }
     }
 }
@@ -103,12 +107,13 @@ contract Test {
 
         try router.withdraw(amount) {} catch (bytes memory thrownError) {
             bytes memory expectedError = abi.encodeWithSelector(
-                Router.Wrap__SubcontextReverted.selector, address(vault), abi.encodeWithSelector(
-                    Vault.Wrap__ERC20TransferFailed.selector,
+                Router.WrappedError.selector, address(vault), vault.withdraw.selector, abi.encodeWithSelector(
+                    Vault.WrappedError.selector,
                     address(token),
+                    token.transfer.selector,
                     abi.encodeWithSignature("Error(string)", "insufficient balance"),
-                    address(this)
-                )
+                    abi.encodeWithSelector(Vault.ERC20TransferFailed.selector, address(this))
+                ), ""
             );
             assert(keccak256(thrownError) == keccak256(expectedError));
         }
@@ -122,21 +127,23 @@ When catching a revert from a called contract, the calling contract should rever
 
 ```solidity
 contract Foo {
-    error Wrap__SubcontextReverted(address target, bytes reason);
+
+    error WrappedError(address target, bytes4 selector, bytes reason, bytes details);
+    error MyCustomError(uint256 x);
 
     function foo(address to, bytes memory data) external {
         // logic
         (bool success, bytes memory returnData) = to.call(data);
         if (!success) {
-            revert Wrap__SubcontextReverted(to, returnData);
+            revert WrappedError(to, bytes4(data), returnData, abi.encodeWithSelector(MyCustomError.selector, 42));
         }
     }
 }
 ```
 
 ## Security Considerations
 
-This EIP does not introduce new security risks.
+Smart contracts could either drop or purposefully suppress the bubbled up reverts along the revert chain. Additionally, smart contracts may also lie or incorrectly report the wrapped reverts, so the information is not guaranteed to be accurate.
 
 ## Copyright