ERC-6315 Namespaced account abstraction (ERC-2771 Namespaced Account Abstraction)
Review · Accounts & wallets · created 2023-01-11
An extension of ERC-2771 that, when handling meta-transactions such as gas fee sponsorship, gives each forwarder its own separate address space (namespace) so the receiving contract does not need to pre-trust the forwarder.
Why it is needed
On Ethereum, meta-transactions, where a third party submits a transaction on chain on behalf of a user, are used, and the widely used ERC-2771 handles this through a 'trusted forwarder.' In this structure, the receiving contract must pre-trust a specific forwarder, so the forwarder must gain the trust of every receiving contract, and users cannot freely use forwarders outside that trust relationship. This proposal introduces a namespace scheme that gives each forwarder its own separate address space, aiming for trustless account abstraction that handles meta-transactions without requiring the receiving contract's prior trust. The receiving contract directly checks, at the moment the call comes in, whether the caller is a namespaced forwarder, and also distinguishes which forwarder manages an address that has passed through a forwarder.
What to implement
function isNamespacedTransaction() external view returns (bool);: Tells whether the caller is a namespaced forwarder. If the receiving contract calls this function as a read-only call and it returns true, the call is treated as a namespaced transaction.function transferNamespaced(address toForwarder, address toAddress, uint256 amount);: An example of a namespaced version of ERC-20's transfer. Tokens are sent by specifying the recipient as a pair of the forwarder address and the address it manages.function approveNamespaced(address spenderForwarder, address spenderAddress, uint256 amount);: An example of a namespaced version of ERC-20's approve. The party being granted permission is specified as a pair of the forwarder address and the managed address.function transferFromNamespaced(address fromForwarder, address fromAddress, address toForwarder, address toAddress, uint256 amount);: An example of a namespaced version of ERC-20's transferFrom. Both the sender and the recipient are each specified as a pair of a forwarder address and a managed address.
In depth
Namespaced forwarder interface
The forwarder implements the INamespacedForwarder interface. This interface has only the single function isNamespacedTransaction(), declared as external view, returning a bool. The receiving contract uses this function's return value to determine whether the caller is a namespaced forwarder.
Procedure for determining the sender and forwarder
When a function is called, the Recipient contract MUST run the caller's isNamespacedTransaction() method via STATICCALL. If this call reverts or returns false, it MUST proceed as a normal transaction, identifying the caller as the sender and the forwarder as the zero address. If true is returned, it is treated as a namespaced transaction, the sender is determined using ERC-2771's procedure for extracting the transaction signer's address, and the caller is identified as the forwarder. Unlike ERC-2771, forwarders are not pre-registered in a list; the determination is made dynamically at call time.
Rules for extending Namespaced functions
If the receiving contract has a function with an address type parameter, it MUST also provide an additional function with Namespaced appended to the original name. The new function takes two addresses instead of one: the first is the forwarder address, and the second is the address managed by that forwarder. For functions with multiple address parameters, such as ERC-20's transferFrom, a version that takes two addresses for each original parameter must be provided. When all forwarder addresses are the zero address, the original function MUST behave identically to the new function. As an ERC-20 extension example, the source presents three functions: transferNamespaced, approveNamespaced, and transferFromNamespaced.
Registering the ERC-165 interface ID
The receiving contract MUST implement ERC-165. When registering the ERC-165 interface ID, it must register, alongside the original interface's ID, a second interface ID formed by XORing the function selectors of that interface's Namespaced functions. This allows external parties to query whether a given contract supports the namespace extension.
Backward compatibility and use in other standards
Contracts that are already deployed cannot change their code, so they cannot benefit from this namespacing proposal. The same limitation applies to ERC-2771. When another standard uses this proposal, it is recommended (SHOULD) to provide both the original interface ID and the Namespaced interface ID, and the Namespaced version functions must not (MUST NOT) be included in the standard's own interface declaration.
Design Rationale
Instead of creating a separate new interface for every frequently used EIP, the approach taken appends an address parameter to existing functions. The source explains this choice was made so the namespacing proposal could apply to a broader range of cases.
Proposal status
This proposal is currently in Review status. Since it is still under review, its content may change or progress may stall.
Things to watch out for
- The trust structure changes: This proposal restructures trust relationships. A forwarder no longer needs to be trusted by the receiving contract, but instead must be trusted by the users who use it. The responsibility for choosing a forwarder shifts to the user.