ERC-7897: Wallet-Linked Services for Smart Accounts

Define a registry for modular services linked to ERC-4337 wallets.

Metadata

Status: WithdrawnStandards Track: ERCCreated: 2024-04-15

Authors

Francesco Sullo (@sullof)

Requires

EIP-165, EIP-1167, EIP-4337, EIP-6551, EIP-7656

Links

GitHub page Discussion on Ethereum Magicians

Abstract

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.

Motivation

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.

Specification

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 IERC7897Registry is defined as follows:

Deployment Requirements

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:

Recommended Service Interface

Any contract created using an ERC7897Registry SHOULD implement the IERC7897Service interface:

Access Control

Services SHOULD implement access control to restrict critical operations to the wallet owner. For example:

Rationale

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.

Reference Implementation

Security Considerations

Ownership and Control

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.

Upgradeability Risks

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.

Reentrancy and Cross-Contract Interactions

Services interacting with external protocols SHOULD follow best practices to prevent reentrancy attacks.

User Education

Clear user interfaces and warnings SHOULD be provided to reduce phishing and social engineering risks.

Testing

Implementers SHOULD thoroughly test the registry and services on testnets to ensure correctness and security before deploying to mainnet.