Merge branch 'master' into master

ERCS/erc-7208.md

@@ -4,7 +4,8 @@ title: On-Chain Data Containers
 description: Interoperability by abstracting logic away from storage
 author: Rachid Ajaja <[email protected]>, Alexandros Athanasopulos (@Xaleee), Pavel Rubin (@pash7ka), Sebastian Galimberti Romano (@galimba), Daniel Berbesi (@berbex), Apostolos Mavropoulos (@ApostolosMavro), Barbara Marcano (@Barbara-Marcano), Daniel Ortega (@xdaniortega)
 discussions-to: https://ethereum-magicians.org/t/erc-7208-on-chain-data-container/14778
-status: Review
+status: Last Call
+last-call-deadline: 2025-01-15
 type: Standards Track
 category: ERC
 created: 2023-06-09

ERCS/erc-7527.md

@@ -163,7 +163,7 @@ interface IERC7527Agency {
      * @dev OPTIONAL - This method can be used to improve usability and clarity of Agency, but interfaces and other contracts MUST NOT expect these values to be present.
      * @return the description of the agency, such as how `getWrapOracle()` and `getUnwrapOracle()` are calculated.
      */
-    function description() public view returns (string);
+    function description() external view returns (string memory);
 }
 ```
 

ERCS/erc-7555.md

@@ -41,7 +41,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 ### Definitions
 - **Smart account** - An ERC-4337 compliant smart contract account that has a modular architecture.
-- **Domain** - A string of text acting as an identification to a server or wesbite (eg: `ethereum.org` or `ABCDE12345.com.example.app`).
+- **Domain** - A string of text acting as an identification to a server or website (eg: `ethereum.org` or `ABCDE12345.com.example.app`).
 - **EOA** - Accounts that are controlled by a single private key.
 - **Provider** - A third party service provider that is able to authenticate a user and produce a keypair for the user.
 

ERCS/erc-7578.md

@@ -4,7 +4,8 @@ title: Physical Asset Redemption
 description: Provides the holder of physical asset backed NFTs readily available real-world information on the underlying physical asset.
 author: Lee Vidor (@V1d0r), David Tan <[email protected]>, Lee Smith <[email protected]>, Gabriel Stoica (@gabrielstoica)
 discussions-to: https://ethereum-magicians.org/t/erc-7578-physical-asset-redemption/17556
-status: Review
+status: Last Call
+last-call-deadline: 2025-01-14
 type: Standards Track
 category: ERC
 created: 2023-08-01
@@ -219,7 +220,7 @@ contract ERC7578 is ERC721, IERC7578 {
 
 ## Security Considerations
 
-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.
+To ensure authenticity, token properties must be set only via 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 represented asset. Additionally, proper access control mechanisms should be implemented to prevent unauthorized modifications of token properties after they are set.
 
 ## Copyright
 

ERCS/erc-7579.md

@@ -36,7 +36,9 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
   - Validator: A module used during the validation phase to determine if a transaction is valid and should be executed on the account.
   - Executor: A module that can execute transactions on behalf of the smart account via a callback.
   - Fallback Handler: A module that can extend the fallback functionality of a smart account.
-- **Entrypoint** - A trusted singleton contract according to [ERC-4337](./eip-4337.md) specifications.
+- **EntryPoint** - A trusted singleton contract according to [ERC-4337](./eip-4337.md) specifications.
+- **Validation** - Any functionality used to determine if an execution should be made on the account. When using ERC-4337, this function will be `validateUserOp`.
+- **Execution** - Any functionality used to execute an operation from or on the users account. When using ERC-4337, this will be called by the EntryPoint using `userOp.callData`.
 
 ### Account
 
@@ -53,7 +55,7 @@ To comply with this standard, smart accounts MUST implement the execution interf
 ```solidity
 interface IExecution {
     /**
-     * @dev Executes a transaction on behalf of the account.
+     * @dev Executes a transaction on behalf of the account. MAY be payable.
      * @param mode The encoded execution mode of the transaction.
      * @param executionCalldata The encoded execution call data.
      *
@@ -63,7 +65,7 @@ interface IExecution {
     function execute(bytes32 mode, bytes calldata executionCalldata) external;
 
     /**
-     * @dev Executes a transaction on behalf of the account.
+     * @dev Executes a transaction on behalf of the account. MAY be payable.
      *         This function is intended to be called by Executor Modules
      * @param mode The encoded execution mode of the transaction.
      * @param executionCalldata The encoded execution call data.
@@ -213,8 +215,10 @@ interface IModuleConfig {
 
 Hooks are an OPTIONAL extension of this standard. Smart accounts MAY use hooks to execute custom logic and checks before and/or after the smart accounts performs a single or batched execution. To comply with this OPTIONAL extension, a smart account:
 
-- MUST call the `preCheck` function of one or multiple hooks during an execution on the account
-- MUST call the `postCheck` function of one or multiple hooks during an execution on the account
+- MUST call the `preCheck` function of one or multiple hooks before any call or batch of calls going through execute or executeFromExecutor
+- MUST call the `postCheck` function of one or multiple hooks after any call or batch of calls through execute or executeFromExecutor
+- Is RECOMMENDED to call `preCheck` and `postCheck` before and after executing calls to `installModule` or `uninstallModule`
+- Is RECOMMENDED to call `preCheck` and `postCheck` before and after executing calls through other (custom) functions called execution
 
 #### ERC-1271 Forwarding
 
@@ -238,7 +242,7 @@ ERC-165 support (see below) is one example of such an approach. Note, that it is
 
 #### 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.
+Smart accounts MAY 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.
 
 ### Modules
 

ERCS/erc-7656.md

@@ -33,6 +33,8 @@ The expansion of the registry's capabilities to manage contracts implementing an
 
 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.
 
+### Registry Interface
+
 The interface `IERC7656Registry` is defined as follows:
 
 ```solidity
@@ -101,6 +103,8 @@ interface IERC7656Registry {
 
 Any `ERC7656Registry` implementation MUST support the `IERC7656Registry`'s interface ID, i.e., `0xc6bdc908`.
 
+### Deployment Requirements
+
 The registry MUST deploy each token-linked service as an [ERC-1167](./eip-1167.md) minimal proxy with immutable constant data appended to the bytecode, similarly to existing token-bound account proposals.
 
 The deployed bytecode of each token-bound service MUST have the following structure:
@@ -114,6 +118,8 @@ ERC-1167 Footer               (15 bytes)
 <tokenId (uint256)>           (32 bytes)
 ```
 
+### Recommended Service Interface
+
 Any contract created using a `ERC7656Registry` SHOULD implement the `IERC7656Service` interface:
 
 ```solidity
@@ -130,7 +136,7 @@ interface IERC7656Service {
 }
 ```
 
-or an account interface or both. This flexibility makes existing account contracts compatible with this proposal out-of-the-box.
+but if the service is a specific type of contract that implements its own interface, like for example token bound smart-wallets, supporting that interface ID is acceptable, to make it compatible out-of-the-box with alternative existing standards.
 
 ## Rationale
 
@@ -176,37 +182,34 @@ contract LinkedService is IERC7656Service, EIP5313 {
 }
 ```
 
-
 ## Security Considerations
 
-### Fraud Prevention when linking accounts to NFTs
+### Ownership Cycles
 
-In order to enable trustless sales of token bound accounts, decentralized marketplaces will need to implement safeguards against fraudulent behavior by malicious account owners.
+If a token-linked service functions as a smart wallet, an ownership cycle can render all assets permanently inaccessible. For example, if an ERC-721 token is transferred to the same smart wallet that it owns, neither the token nor the wallet’s assets can be retrieved, because the wallet cannot transfer the token back.
 
-Consider the following potential scam:
+Preventing more complex ownership cycles on-chain is difficult, as it would require searching an unbounded number of possible transfers. Consequently, this proposal does not address cycle prevention. Projects adopting this proposal SHOULD include their own safeguards against such scenarios.
 
-- Alice owns an ERC-721 token X, which owns token bound account Y.
-- Alice deposits 10ETH into account Y
-- Bob offers to purchase token X for 11ETH via a decentralized marketplace, assuming he will receive the 10ETH stored in account Y along with the token
-- Alice withdraws 10ETH from the token bound account, and immediately accepts Bob's offer
-- Bob receives token X, but account Y is empty
+### Fraud Prevention when linking accounts to NFTs
 
-To mitigate fraudulent behavior by malicious account owners, decentralized marketplaces SHOULD implement protection against these sorts of scams at the marketplace level. Contracts which implement this EIP MAY also implement certain protections against fraudulent behavior.
+Token-linked services can take many forms—such as subscription services, smart wallets, or renting platforms—and a malicious seller could exploit this flexibility by altering or removing critical components just before finalizing a sale. For instance, the seller might transfer out assets from a wallet service, revoke access from a subscription, or break a rental agreement at the last moment, leaving the buyer with a compromised or worthless service.
 
-Here are a few mitigations strategies to be considered:
+Because this proposal accommodates a wide range of services, there is no one-size-fits-all fraud mitigation strategy. However, a common approach is to implement a lock mechanism that restricts changes for a certain period before the sale is completed, or until the buyer confirms the purchase. Such functionality MAY be included by service developers but is not mandated by this proposal.
 
-- Attach the current token bound account state to the marketplace order. If the state of the account has changed since the order was placed, consider the offer void. This functionality would need to be supported at the marketplace level.
-- Attach a list of asset commitments to the marketplace order that are expected to remain in the token bound account when the order is fulfilled. If any of the committed assets have been removed from the account since the order was placed, consider the offer void. This would also need to be implemented by the marketplace.
-- Submit the order to the decentralized market via an external smart contract which performs the above logic before validating the order signature. This allows for safe transfers to be implemented without marketplace support.
-- Implement a locking mechanism on the token bound account implementation that prevents malicious owners from extracting assets from the account while locked
+### Malicious or Unverified Implementations
+Since the registry cannot ensure that only the legitimate NFT owner can create services for a given token, there is a risk that malicious or unverified code could be used. Users and marketplaces SHOULD carefully review or audit any implementation before linking it to an NFT.
 
-Preventing fraud is outside the scope of this proposal.
+### Upgradability and Governance Risks
+If a token-linked service is upgradable, the current owner (or a compromised owner) could upgrade the contract to exfiltrate assets or change functionality unexpectedly. Projects SHOULD implement secure upgrade mechanisms, such as time-locked upgrades or multi-signature approvals.
 
-### Ownership Cycles
+### Re-entrancy and Cross-Contract Interactions
+Token-linked services (especially those that hold assets or interact with external protocols) may be vulnerable to re-entrancy attacks or other cross-contract exploits. Implementers SHOULD follow standard security patterns and best practices.
 
-All assets held in a token bound account may be rendered inaccessible if an ownership cycle is created. The simplest example is the case of an ERC-721 token being transferred to its own token bound account. If this occurs, both the ERC-721 token and all of the assets stored in the token bound account would be permanently inaccessible, since the token bound account is incapable of executing a transaction which transfers the ERC-721 token.
+### Denial of Service (DoS)
+If a service is designed or implemented incorrectly, it may become impossible to execute certain calls or transfer ownership, resulting in a DoS scenario. Implementers SHOULD consider fail-safes or recovery methods to prevent indefinite lockouts.
 
-Ownership cycles can be introduced in any graph of n>0 token bound accounts. On-chain prevention of cycles with depth>1 is difficult to enforce given the infinite search space required, and as such is outside the scope of this proposal. Application clients and account implementations wishing to adopt this proposal are encouraged to implement measures that limit the possibility of ownership cycles.
+### User Education and Phishing Risks
+Even with secure smart contracts, end-users can still be tricked into interacting with fraudulent services. Clear user interfaces, warnings, and contract verifications (e.g., Etherscan or similar tools) SHOULD be encouraged to reduce phishing and social engineering risks.
 
 ## Copyright
 

ERCS/erc-7683.md

@@ -133,9 +133,9 @@ struct Output {
 /// @notice Instructions to parameterize each leg of the fill
 /// @dev Provides all the origin-generated information required to produce a valid fill leg
 struct FillInstruction {
-	/// @dev The contract address that the order is meant to be settled by
-	uint64 destinationChainId;
-	/// @dev The contract address that the order is meant to be filled on
+	/// @dev The chain that this instruction is intended to be filled on
+	uint256 destinationChainId;
+	/// @dev The contract address that the instruction is intended to be filled on
 	bytes32 destinationSettler;
 	/// @dev The data generated on the origin chain needed by the destinationSettler to process the fill
 	bytes originData;

ERCS/erc-7734.md

@@ -4,7 +4,8 @@ title: Decentralized Identity Verification (DID)
 description: A privacy-preserving method for decentralized identity verification, enabling secure integration of identity management in dApps.
 author: Anushka Yadav (@64anushka) <[email protected]>
 discussions-to: https://ethereum-magicians.org/t/discussion-on-decentralized-identity-verification-did-standard/20392
-status: Review
+status: Last Call
+last-call-deadline: 2025-01-21
 type: Standards Track
 category: ERC
 created: 2024-06-26