ERC-7582: Modular Accounts with Delegated Validation

Abstract

This proposal standardizes a method for adding plugins and composable logic to smart contract accounts built on existing interfaces like ERC-4337 (e.g., ERC-4337's IAccount). Specifically, by formalizing how applications can use the ERC-4337 Entry Point NonceManager and the emission of the IEntryPoint UserOperationEvent to account for plugin interactions, as well, as how to extract designated validators (in this case, by means of IAccount's validateUserOp), accounts can specify how they call plugin contracts and grant special executory access for more advanced operations. Furthermore, this minimalist plugin approach is developer-friendly and complimentary to existing account abstraction standards by not requiring any additional functions for contracts that follow the IAccount interface (itself minimalist in only specifying one function, validateUserOp).

Motivation

Smart contract accounts (contract accounts) are a powerful tool for managing digital assets and executing transactions by allowing users to program their interactions with blockchains. However, they are often limited in their functionality and flexibility without sufficient consensus around secure abstraction designs (albeit, the adoption of ERC-4337 is the preferred path of this proposal). For example, contract accounts are often unable to support social recovery, payment schedules, and other features that are common in traditional financial systems without efficient and predictable schemes to delegate execution and other access rights to approximate the UX of custodial and more specialized applications.

Account abstraction standards like ERC-4337 have achieved simplification of many core contract account concerns such as transaction fee payments, but to fully leverage the expressive capability of these systems to accomplish user intents, minimalist methods to delegate contract account access and validation to other contracts would aid their UX and extend the benefits of centering operations around the Entry Point.

While the IAccount interface from ERC-4337 does not specify a way to add custom validation logic to contract accounts to support plugins and similar extensions without upgrades or migrations, it nevertheless contains sufficient information to do so efficiently. This proposal therefore offers a method for adding plugins and other composable validation logic to smart contract accounts built on existing interfaces with singleton nonce-tracking like ERC-4337's IAccount and NonceManager.

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.

We leverage the key in ERC-4337 semi-abstracted nonce as the pointer to validator identifier. If a non-sequential key (>type(uint64).max) is used as an ERC-4337 Entry Point UserOperation (userOp) nonce, the validateUserOp function in the sender contract account MUST extract the validator identifier, this MAY be the address itself or a pointer to the validator address in storage. Once the validator contract address is extracted, the proposed contract account (henceforth, shall be referred to as MADV account) MUST forward the userOp calldata to the validator. This calldata SHOULD be the entire userOp. In response to this delegated validation, the validator contract MUST return the ERC-4337 validationData, and the MADV sender account MUST return this as the validationData to the Entry Point.

In all of the above validation steps, the validator contract MUST respect the ERC-4337 Entry Point conventions. Note, that while validator key data might be included elsewhere in a UserOperation to achieve similar contract account modularity, for example, by packing this data into the signature field, this proposal opts to repurpose nonce for this pointer to minimize calldata costs and to benefit from the EntryPoint's getNonce accounting, as well as the discoverability of user plugin interactions in the UserOperationEvent which exposes nonce but not other userOp data.

ERC-4337 references:

PackedUserOperation interface

IAccount interface

NonceManager interface

UserOperationEvent

Rationale

This proposal is designed to be a minimalist extension to ERC-4337 that allows for additional functionality without requiring changes to the existing interface. Keeping the proposal's footprint small.

Further, by repurposing the nonce field for the validator identifier we minimize calldata costs and leverage existing getNonce accounting. The UserOperationEvent emits nonce which can be used for tracking validator invocations without additional events. Other options like packing the validator identifier into the signature field were considered but were rejected due to potential for conflict with other signatures schemes and increased opaqueness into validator invocation.

This proposal allows for MADV accounts to specify their own method for extracting the validator address from the nonce. This provides flexibility to account developers and supports both "just in time" validators as well as a more predictable storage pattern for plugin reuse.

The requirement is simply to use nonce for encoding an identifier and to return the validationData from the extracted validator contract to the EntryPoint in line with the requirements of the ERC-4337 validateUserOp function.

Backwards Compatibility

No backward compatibility issues found.

Reference Implementation

See the MADV reference implementation for a simple example of how to implement this proposal.

Security Considerations

As this proposal introduces no new functions and leaves implementation of the validator extraction method and approval logic open to developers, the surface for security issues is intentionally kept small. Nevertheless, specific validator use cases require further discussion and consideration of the overall ERC-4337 verification flow and its underlying security.

Copyright

Copyright and related rights waived via CC0.