This proposal defines a factory capable of deploying generic services linked to specific contracts, such as ERC-4337 accounts or ERC-721 tokens (NFTs). These linked services extend the functionalities of the target contract, operating under the ownership of the contract's or NFT's owner without requiring modifications to the original contract's code. This approach enables extending existing contracts with new capabilities while maintaining backward compatibility with deployed instances.
Existing projects, like token-bound accounts, successfully bind smart accounts to NFTs, allowing registries to deploy accounts owned by specific token IDs. However, these standards have two key limitations:
This ERC proposes a more versatile factory specification that enables the deployment of proxies pointing to any contract that enhances the associated contract's capabilities, whether it's an NFT or an account contract.
Universal Linkability: Enables services to be linked to any compatible contract type, not just NFTs, creating a unified approach to contract extension.
Non-Invasive Enhancement: Services can add functionality to existing smart accounts without modifying the underlying contract, maintaining compatibility with infrastructure like wallets and indexers.
Backward Compatibility: Maintains compatibility with existing token-bound accounts while extending functionality to new use cases.
Flexible Implementation: The mode parameter enables different linkage types (with or without token IDs) while ensuring consistent deterministic addressing.
Unified Extension Mechanism: Provides a standardized approach for extending existing contracts with new capabilities, reducing the need for specialized implementations across different use cases.
Social Recovery Services: Deploy a social recovery mechanism linked to an existing ERC-4337 wallet that can restore access if credentials are lost, without requiring the wallet to implement recovery functionality natively.
Customizable Permission Systems: Add granular permissions to an account (time-limited access, spending limits, multi-signature approvals) without rebuilding the account from scratch.
Account Abstraction Extensions: Implement advanced features like batch transactions, gas sponsorship, or session keys as linked services, allowing wallets to adopt these features selectively.
Identity and Reputation Services: Link verifiable credentials or reputation systems to accounts, enabling privacy-preserving identity verification.
Enhanced Token Utility: Provide NFTs with financial capabilities like staking, lending, or revenue distribution.
Dynamic Metadata Services: Enable NFT metadata to evolve based on on-chain activities without changing the NFT itself.
Fractional Ownership: Implement fractional ownership mechanisms for high-value NFTs through linked contracts.
Conditional Access Control: Create time-locked or challenge-based access to NFT-gated content or services.
Real World Asset Management: Extend NFTs to represent and manage real-world assets (RWAs) by linking services that handle compliance, legal documentation, custody verification, transfer restrictions, and regulatory reporting without requiring specialized NFT standards for each asset class.
The keywords "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.
The IERC7656Factory interface is defined as follows:
The mode parameter serves as a selector for how the linked contract should be interpreted and utilized. Currently, ERC-7656 defines two standard modes:
LINKED_ID Mode (0x000000000000000000000000): Used when linking a service to an NFT or any contract that requires a token/entity ID. This mode ensures compatibility with existing token-bound account systems.
NO_LINKED_ID Mode (0x000000000000000000000001): Used when linking a service to a contract that doesn't require an ID parameter, such as an ERC-4337 account. In this case, the linkedId parameter is still present in the interface for consistency but SHOULD be set to zero if not used to store alternative data relevant to the service.
The mode parameter (being bytes12) allows for future extensions beyond these initial modes, enabling more complex linkage patterns as ecosystem needs evolve.
Any ERC7656Factory implementation MUST support the IERC7656Factory interface ID (0x9e23230a).
Each linked service MUST be deployed as an ERC-1167 minimal proxy, appending immutable constant data to the bytecode. The deployed bytecode structure is:
Total bytecode size: 183 bytes
Linked services SHOULD implement the IERC7656Service interface:
When implementing a linked service, developers SHOULD consider the following patterns:
Ownership Verification: Services SHOULD include mechanisms to verify that operations are authorized by the current owner of the linked contract or token.
Mode-Specific Logic: Services SHOULD implement conditional logic based on the mode parameter to handle both NFT-linked and account-linked scenarios appropriately.
Cross-Chain Awareness: Services SHOULD check that operations are being performed on the chain specified in the chainId parameter to prevent cross-chain replay attacks.
The design of ERC-7656 is guided by several key principles that address limitations in current contract extension methods:
Rather than creating separate standards for NFT extensions and account extensions, ERC-7656 employs a unified factory approach. This design choice stems from recognizing the fundamental similarity between linking services to tokens and linking services to accounts - both involve extending functionality while maintaining a clear ownership relationship.
The mode parameter uses 12 bytes instead of a simple boolean flag because the 12-byte format reserves space for future linking modes beyond the initial two (NFT linking and account linking). For example, if a service is associated to an ERC-1155 token but requires that the balance of the user is more than 1000 tokens, the mode could be 0x000000000000000000003e802, where the least significant byte, 0x02 is the primary mode and the rest is the minimum required balance. Similarly, someone can think of a service associated to ERC-20 tokens that requires a specific balance where the required balance can be put in the linkedId field, and the mode specified accordingly.
ERC-7656 follows a deterministic addressing pattern, appending immutable data to the contract bytecode rather than storing it in contract storage. This ensures that:
Unlike standards that enforce specific interfaces or behaviors on linked contracts, ERC-7656 remains agnostic about the implementation details of linked services. This deliberate design choice allows developers maximum flexibility to create specialized services while maintaining a consistent deployment and ownership model.
ERC-7656 maintains compatibility with token-bound accounts when used with the LINKED_ID mode (0x000000000000000000000000). This ensures that existing applications and infrastructure supporting token-bound accounts can continue operating without modification.
For contracts using the NO_LINKED_ID mode (0x000000000000000000000001), specialized interfaces may be required, but the core factory mechanism remains consistent.
See ERC7656Factory.sol for an example implementation of IERC7656Factory.
For convenience, the bytecode of the reference implementation has been deployed at 0x76565d90eeB1ce12D05d55D142510dBA634a128F on Ethereum mainnet, and will be later deployed at the same address to all primary mainnets and selected testnets.
An example of implementation of IERC7656Service:
Smart wallets linked to NFTs that are then held by the same wallet can create ownership cycles, potentially rendering assets inaccessible. Implementers should include safeguards to prevent or detect such cycles.
A malicious seller could alter or revoke service permissions just before finalizing a sale. Lock mechanisms preventing last-minute changes may be implemented, especially for NFT marketplaces integrating with ERC-7656 services.
The registry cannot enforce legitimate ownership when linking services. Users should review or audit implementations before deployment. Front-end applications integrating ERC-7656 should display warnings when interacting with unverified implementations.
Linked services that are upgradable pose risks of unexpected changes or asset exfiltration. Secure upgrade mechanisms with timelock controls or multi-signature governance should be implemented when upgradeability is required.
Linked services interacting with assets or external protocols may be vulnerable to reentrancy exploits. Implementers should follow security best practices such as the checks-effects-interactions pattern and consider reentrancy guards.
Services operating in different modes (LINKED_ID vs NO_LINKED_ID) may have different security requirements. Implementations should validate that operations are appropriate for the service's configured mode.
Even with secure contracts, users may fall victim to fraudulent services masquerading as legitimate ones. Clear UI warnings, verification tools, and educational resources should be provided by applications integrating ERC-7656.
Licensed under CC0.