From 5396daa138bf7783939767160a87439a9b5d816b Mon Sep 17 00:00:00 2001 From: Francesco Sullo Date: Mon, 4 Nov 2024 17:14:59 +0100 Subject: [PATCH 1/5] Moving to last call --- ERCS/erc-7656.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ERCS/erc-7656.md b/ERCS/erc-7656.md index b91e771d0c..fcf8e8da15 100644 --- a/ERCS/erc-7656.md +++ b/ERCS/erc-7656.md @@ -4,7 +4,8 @@ title: Generalized Token-Linked Services description: Define a registry for generic services linked to a specific NFT author: Francesco Sullo (@sullof) discussions-to: https://ethereum-magicians.org/t/variation-to-erc6551-to-deploy-any-kind-of-contract-linked-to-an-nft/19223 -status: Review +status: Last Call +last-call-deadline: 2024-12-12 type: Standards Track category: ERC created: 2024-03-15 From 4046a95ea1070181de07b1ec32c19e2501a3a282 Mon Sep 17 00:00:00 2001 From: Francesco Sullo Date: Tue, 26 Nov 2024 16:46:54 +0100 Subject: [PATCH 2/5] Remove reference to erc6551 --- ERCS/erc-7656.md | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/ERCS/erc-7656.md b/ERCS/erc-7656.md index 2a69d0f328..2189a3ac14 100644 --- a/ERCS/erc-7656.md +++ b/ERCS/erc-7656.md @@ -9,23 +9,23 @@ last-call-deadline: 2024-12-12 type: Standards Track category: ERC created: 2024-03-15 -requires: 165, 1167, 5313, 6551 +requires: 165, 1167, 5313 --- ## Abstract -This proposal introduces a variation of [ERC-6551](./eip-6551.md) that extends to all types of services linked to non-fungible tokens (NFTs), i.e., contracts extending an NFT, owned by a single NFT and thus by the owner of the NFT. It achieves this goal using generic language for functions, errors, and events, and avoids conflicting with the strict restrictions imposed by the original proposal. +This proposal defines a registry for generic services linked to specific non-fungible tokens (NFTs), i.e., contracts extending an NFT, owned by a single NFT and thus by the owner of the NFT. It achieves this goal using generic language for functions, errors, and events, and avoids conflicting with strict restrictions imposed by other proposals. ## Motivation -[ERC-6551](./eip-6551.md) aims to bind smart accounts to tokens, allowing its registry to deploy accounts owned by a specific tokenID. The issue we attempt to address with this new proposal is that [ERC-6551](./eip-6551.md) explicitly requires any contract deployed via the `ERC6551Registry` to implement `IERC6551Account` and `IERC6551Execute`, i.e., it must be an account. This requirement is underscored by the choices for the names of functions and events in the interface. Additionally, [ERC-6551](./eip-6551.md) specifies that the `ERC6551Registry` smart contract is deployed as a singleton at a specific address on any chain. Due to this centralization of services, projects building on it are prone to consider any contract deployed via that registry that is not an account as spam or invalid. +Existing proposals aim to bind smart accounts to tokens, allowing their registries to deploy accounts owned by specific token IDs. The issue we attempt to address with this new proposal is that these proposals often explicitly require any contract deployed via their registries to implement specific interfaces to handle assets and execute transactions, effectively mandating that the deployed contract must be an account. This requirement is underscored by the choices for the names of functions and events in their interfaces. Additionally, some proposals specify that their registry smart contracts are deployed as singletons at specific addresses on any chain. Due to this centralization of services, projects building on them are prone to consider any contract deployed via that registry that is not an account as spam or invalid. -With this new ERC, we propose a more generic registry that uses generic function/event names to allow the deployment of any kind of contract that makes sense when associated with an NFT, so that the contract is under the full control of the NFT's owner. In comparison with [ERC-6551](./eip-6551.md), since one of this proposal's goals is flexibility, there is no expectation for an `ERC7656Registry` contract to be deployed as a singleton, allowing any project to adjust it to their needs; consequently, we require that any registry explicitly supports the `IERC7656Registry` interface. +With this new ERC, we propose a generic registry that uses generic function/event names to allow the deployment of any kind of contract that makes sense when associated with an NFT, so that the contract is under the full control of the NFT's owner. Since one of this proposal's goals is flexibility, there is no expectation for an `ERC7656Registry` contract to be deployed as a singleton, allowing any project to adjust it to their needs; consequently, we require that any registry explicitly supports the `IERC7656Registry` interface. The expansion of the registry's capabilities to manage contracts implementing any kind of service beyond accounts provides several advantages: - **Flexibility**: Developers can allow NFTs to interact with a broader range of linked contracts, unlocking new use cases and functionalities (lending systems, vested asset distribution, fractional ownership, identity, etc.) -- **Compatibility**: By ensuring that account-like contracts can still be identified as such, the proposal maintains backward compatibility with [ERC-6551](./eip-6551.md). +- **Compatibility**: By ensuring that account-like contracts can still be identified as such, the proposal maintains backward compatibility with existing account-based proposals. - **Innovation**: This proposal encourages further innovation in the NFT space by removing limitations on the types of contracts that can be associated with NFTs, opening the door to pure-utility NFTs. @@ -101,9 +101,9 @@ interface IERC7656Registry { Any `ERC7656Registry` implementation MUST support the `IERC7656Registry`'s interface ID, i.e., `0xc6bdc908`. -Similarly to [ERC-6551](./eip-6551.md), 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. +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: +The deployed bytecode of each token-bound service MUST have the following structure: ``` ERC-1167 Header (10 bytes) (20 bytes) @@ -130,21 +130,23 @@ interface IERC7656Service { } ``` -or the `IERC6551Account` interface or both. This flexibility makes [ERC-6551](./eip-6551.md) accounts compatible with this proposal out-of-the-box. +or an account interface or both. This flexibility makes existing account contracts compatible with this proposal out-of-the-box. ## Rationale The technical foundation of [ERC-7656](./eip-7656.md) centers on the extension and generalization of contract types that can be associated with NFTs. This approach was chosen to address specific limitations and opportunities identified in the design and application of NFT-linked contracts. Key technical decisions in this proposal include: -- Generic Function/Event Names: The choice to adopt a generic naming convention for functions, errors, and events is deliberate. This design decision enables the [ERC-7656](./eip-7656.md) registry to support a wide array of contract types beyond mere accounts. By not prescribing specific roles or functionalities, we allow for greater innovation and flexibility in the types of applications that can be built on this standard. This also simplifies the interface and makes it more adaptable to various use cases. +- **Addressing ERC Proliferation and Contract Size Limitations**: The increasing number of ERC proposals extending the ERC-721 standard has led to complexity and potential confusion within the developer community. Since smart contracts have size limitations, incorporating multiple extensions into a single contract can become impractical or even impossible. [ERC-7656](./eip-7656.md) offers a solution by enabling the deployment of services that extend standard ERC-721 NFTs without requiring modifications to the ERC-721 standard itself. For example, instead of creating new ERCs to associate real-world assets with NFTs, developers can deploy specialized smart contracts owned by NFTs to add these features. This approach allows NFTs to seamlessly expand their capabilities while maintaining compliance with the existing ERC-721 standard, promoting a more efficient and modular development process. -- No Singleton Requirement for the Registry: Unlike its predecessor, [ERC-7656](./eip-7656.md) does not mandate that the registry be deployed as a singleton. This decision was influenced by the recognition that different projects may have unique requirements and constraints. By allowing for multiple instances of the registry, projects can customize and optimize the registry's deployment to fit their specific needs, enhancing the ecosystem's overall diversity and resilience. +- **Generic Function/Event Names**: The choice to adopt a generic naming convention for functions, errors, and events is deliberate. This design decision enables the [ERC-7656](./eip-7656.md) registry to support a wide array of contract types beyond mere accounts. By not prescribing specific roles or functionalities, we allow for greater innovation and flexibility in the types of applications that can be built on this standard. This also simplifies the interface and makes it more adaptable to various use cases. -- Explicit Support for the `IERC7656Registry` Interface: Requiring that any registry explicitly supports the `IERC7656Registry` interface is a technical decision aimed at ensuring interoperability and recognition. This requirement facilitates the identification and interaction with compliant registries, promoting a more standardized and cohesive ecosystem. +- **No Singleton Requirement for the Registry**: Unlike some previous proposals, [ERC-7656](./eip-7656.md) does not mandate that the registry be deployed as a singleton. This decision was influenced by the recognition that different projects may have unique requirements and constraints. By allowing for multiple instances of the registry, projects can customize and optimize the registry's deployment to fit their specific needs, enhancing the ecosystem's overall diversity and resilience. However, for convenience, the registry has been deployed to the `erc7656.eth` address on the most used networks. -- Flexibility in Contract Association: The proposal is designed to accommodate not just accounts, but any contract that can meaningfully be associated with an NFT. This decision stems from a technical evaluation of the evolving landscape of NFT use cases, recognizing the need for a standard that can support a broader range of functionalities, from complex financial instruments to identity verification systems. +- **Explicit Support for the `IERC7656Registry` Interface**: Requiring that any registry explicitly supports the `IERC7656Registry` interface is a technical decision aimed at ensuring interoperability and recognition. This requirement facilitates the identification and interaction with compliant registries, promoting a more standardized and cohesive ecosystem. -- Backward Compatibility: The proposal includes provisions for backward compatibility, particularly with account-like contracts from [ERC-6551](./eip-6551.md). This technical choice ensures that projects built on the earlier standard can transition to or leverage the new standard without discarding existing infrastructure or investments. +- **Flexibility in Contract Association**: The proposal is designed to accommodate not just accounts, but any contract that can meaningfully be associated with an NFT. This decision stems from a technical evaluation of the evolving landscape of NFT use cases, recognizing the need for a standard that can support a broader range of functionalities, from complex financial instruments to identity verification systems. + +- **Backward Compatibility**: The proposal includes provisions for backward compatibility, particularly with account-like contracts from existing standards. This technical choice ensures that projects built on earlier standards can transition to or leverage the new standard without discarding existing infrastructure or investments. These technical decisions collectively aim to broaden the scope and applicability of NFT-linked contracts, empower developers with more tools for innovation, and support a growing ecosystem of decentralized applications. By addressing both current limitations and future opportunities, [ERC-7656](./eip-7656.md) seeks to lay a flexible and robust foundation for the next generation of NFT technologies. @@ -155,6 +157,8 @@ The reference implementation of `ERC7656Registry` is mutated from `ERC6551Regist ```solidity contract ERC7656Registry is IERC7656Registry { + // this implementation is a variation of ERC6551Registry, which non being yet finalized cannot be referenced in this ERC. + function create( address implementation, bytes32 salt, @@ -272,7 +276,7 @@ contract LinkedService is IERC7656Service, EIP5313 { function token() public view virtual returns (uint256, address, uint256) { bytes memory footer = new bytes(0x60); - assembly { + assembly { extcodecopy(address(), add(footer, 0x20), 0x4d, 0x60) } return abi.decode(footer, (uint256, address, uint256)); From bf277d6104b470e0248c006310a72508a8e6ca53 Mon Sep 17 00:00:00 2001 From: Francesco Sullo Date: Tue, 26 Nov 2024 20:59:26 +0100 Subject: [PATCH 3/5] Fix links to ERC721 --- ERCS/erc-7656.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-7656.md b/ERCS/erc-7656.md index 2189a3ac14..024c66daf6 100644 --- a/ERCS/erc-7656.md +++ b/ERCS/erc-7656.md @@ -136,7 +136,7 @@ or an account interface or both. This flexibility makes existing account contrac The technical foundation of [ERC-7656](./eip-7656.md) centers on the extension and generalization of contract types that can be associated with NFTs. This approach was chosen to address specific limitations and opportunities identified in the design and application of NFT-linked contracts. Key technical decisions in this proposal include: -- **Addressing ERC Proliferation and Contract Size Limitations**: The increasing number of ERC proposals extending the ERC-721 standard has led to complexity and potential confusion within the developer community. Since smart contracts have size limitations, incorporating multiple extensions into a single contract can become impractical or even impossible. [ERC-7656](./eip-7656.md) offers a solution by enabling the deployment of services that extend standard ERC-721 NFTs without requiring modifications to the ERC-721 standard itself. For example, instead of creating new ERCs to associate real-world assets with NFTs, developers can deploy specialized smart contracts owned by NFTs to add these features. This approach allows NFTs to seamlessly expand their capabilities while maintaining compliance with the existing ERC-721 standard, promoting a more efficient and modular development process. +- **Addressing ERC Proliferation and Contract Size Limitations**: The increasing number of ERC proposals extending the [ERC-721](./eip-721.md) standard has led to complexity and potential confusion within the developer community. Since smart contracts have size limitations, incorporating multiple extensions into a single contract can become impractical or even impossible. [ERC-7656](./eip-7656.md) offers a solution by enabling the deployment of services that extend standard [ERC-721](./eip-721.md) NFTs without requiring modifications to the [ERC-721](./eip-721.md) standard itself. For example, instead of creating new ERCs to associate real-world assets with NFTs, developers can deploy specialized smart contracts owned by NFTs to add these features. This approach allows NFTs to seamlessly expand their capabilities while maintaining compliance with the existing [ERC-721](./eip-721.md) standard, promoting a more efficient and modular development process. - **Generic Function/Event Names**: The choice to adopt a generic naming convention for functions, errors, and events is deliberate. This design decision enables the [ERC-7656](./eip-7656.md) registry to support a wide array of contract types beyond mere accounts. By not prescribing specific roles or functionalities, we allow for greater innovation and flexibility in the types of applications that can be built on this standard. This also simplifies the interface and makes it more adaptable to various use cases. From 48e4022f172f4761993cfd13e33be961e6fdc797 Mon Sep 17 00:00:00 2001 From: Francesco Sullo Date: Wed, 27 Nov 2024 13:23:57 +0100 Subject: [PATCH 4/5] Minor change to the comment --- ERCS/erc-7656.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-7656.md b/ERCS/erc-7656.md index 024c66daf6..b2858b67fa 100644 --- a/ERCS/erc-7656.md +++ b/ERCS/erc-7656.md @@ -157,7 +157,7 @@ The reference implementation of `ERC7656Registry` is mutated from `ERC6551Regist ```solidity contract ERC7656Registry is IERC7656Registry { - // this implementation is a variation of ERC6551Registry, which non being yet finalized cannot be referenced in this ERC. +// this implementation is mutated from https://github.com/erc6551/reference function create( address implementation, From 95faddad78ec5c57b01bb3a1c46d3c852b83be99 Mon Sep 17 00:00:00 2001 From: Francesco Sullo Date: Wed, 27 Nov 2024 14:12:15 +0100 Subject: [PATCH 5/5] Removing reference to ERC6551Registry contract --- ERCS/erc-7656.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/ERCS/erc-7656.md b/ERCS/erc-7656.md index b2858b67fa..0d911d29fe 100644 --- a/ERCS/erc-7656.md +++ b/ERCS/erc-7656.md @@ -153,11 +153,9 @@ These technical decisions collectively aim to broaden the scope and applicabilit ## Reference Implementation -The reference implementation of `ERC7656Registry` is mutated from `ERC6551Registry`, with minor changes to rename over-specific functions, emit a different event and error, and a `supportsInterface` function that returns true only for the `IERC7656Registry` interfaceId. - ```solidity contract ERC7656Registry is IERC7656Registry { -// this implementation is mutated from https://github.com/erc6551/reference +// this implementation is a variation of https://github.com/erc6551/reference function create( address implementation,