This proposal defines a registry for generic services linked to smart accounts, with a special focus on ERC-4337 wallets, where services are contracts extending a wallet's functionality, owned by the wallet itself. It leverages ERC-1167 minimal proxies and deterministic addressing to enable permissionless innovation while maintaining backward compatibility with existing ERC-4337 wallets. To reach its goal, it takes the concept introduced with ERC-6551 and ERC-7656 standards that work for NFTs, and applies it to wallets.
Note: This proposal is not needed anymore since the same functionality can be achieved using ERC-7656 standard.
ERC-4337 (Account Abstraction) introduces programmable smart accounts. Existing proposals to extend wallet functionalities (e.g., ERC-6900) focus on internal modules. This proposal generalizes the concept of service binding, allowing any ERC-4337 wallet to attach external services (e.g., recovery, automation, compliance) without requiring changes to the wallet's core logic.
By enabling modular, non-invasive extensions, this standard fosters an open ecosystem of wallet-linked services while ensuring backward compatibility with existing ERC-4337 wallets.
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.
The interface IERC7897Registry is defined as follows:
The registry MUST deploy each wallet-linked service as an ERC-1167 minimal proxy with immutable constant data appended to the bytecode.
The deployed bytecode of each wallet-linked service MUST have the following structure:
Any contract created using an ERC7897Registry SHOULD implement the IERC7897Service interface:
Services SHOULD implement access control to restrict critical operations to the wallet owner. For example:
The technical foundation of ERC-7897 centers on the extension and generalization of contract types that can be associated with ERC-4337 wallets. Key decisions include:
Flexibility: Enables any ERC-4337 wallet to attach external services without modifying its core logic.
Permissionless Innovation: Developers can deploy services for any wallet, fostering an open ecosystem.
Backward Compatibility: Works with existing ERC-4337 wallets, including Safe, Argent, and Biconomy.
Deterministic Addressing: Uses CREATE2 + salt/chainId/wallet for predictable service deployments.
Wallet-linked services MUST be controlled by the ERC-4337 wallet owner to prevent unauthorized access. Implementers SHOULD include safeguards against malicious or unverified implementations.
If a service is upgradable, ensure secure upgrade mechanisms to prevent unauthorized changes. For example:
The owner of the service SHOULD be the wallet itself.
Only the wallet SHOULD be able to upgrade the implementation of the service.
Implement versioning to ensure backward compatibility between upgrades.
Use a timelock or multisig for critical upgrades to reduce the risk of malicious changes.
Services interacting with external protocols SHOULD follow best practices to prevent reentrancy attacks.
Clear user interfaces and warnings SHOULD be provided to reduce phishing and social engineering risks.
Implementers SHOULD thoroughly test the registry and services on testnets to ensure correctness and security before deploying to mainnet.
Copyright and related rights waived via CC0.