ERC-7806: Minimal intent-centric EOA smart account

Abstract

---

This proposal defines a standard interface for intent-centric smart accounts. It enables externally owned accounts (EOAs) to delegate contract code to a smart account implementation, allowing them to sign intents. These intents can then be executed by solvers (or relayers) on behalf of the account owner, streamlining interactions and expanding the capabilities of EOAs.

Motivation

---

Account Abstraction (AA) is a highly discussed topic in the blockchain industry, as it enhances the programmability of accounts, enabling features such as:

• Batch Execution
• Gas Sponsorship
• Access Control

The introduction of ERC-4337 established a permissionless standard for AA, unlocking a wide range of powerful features. However, ERC-4337 has several limitations:

• Complexity: The standard requires multiple interdependent components, including the Account, EntryPoint, Paymaster, Bundler, and additional plugins (ERC-6900, ERC-7579. Running a bundler demands significant engineering expertise and introduces operational overhead.
• Compatibility: Component dependencies make upgrades cumbersome, often requiring multiple smart contracts to be updated simultaneously. This creates fragmentation within the ecosystem. one version update, also divides the ecosystem.
• Cost: Processing UserOperation transactions consumes a high amount of gas.
• Trust Assumption: Despite being designed as a permissionless standard, ERC-4337 still relies on centralized entities. Paymasters, for instance, are typically centralized, as they must either trust account owners to reimburse gas costs or manage external funding sources. Similarly, bundlers operate within a miner extractable value (MEV) environment, requiring users to trust them for transaction inclusion.

ERC-7521 introduced a smart contract account (SCA) solution with an intent-centric design. It allows solvers to fulfill account owners' intents while maintaining flexibility for custom execution logic and ensuring forward compatibility.

With the introduction of SET_CODE_TX_TYPE=0x04, EOAs can now set contract code dynamically, granting them programmability similar to SCAs. This presents an opportunity to develop a new standard that extends AA capabilities to EOAs while addressing the aforementioned challenges.

By simplifying execution, improving efficiency, and enhancing user experience, this proposal aims to accelerate the adoption of intent-centric account abstraction smart contracts.

Solvers, Relayers, Paymasters, and Bundlers—All in One

In an intent-centric system, solvers play a crucial role in fulfilling user intents and are rewarded accordingly. This proposal introduces an open execution model, where any solver can participate, fostering a competitive environment that benefits users.

With integrated gas abstraction, solvers can cover gas fees using native tokens while receiving other tokens from the EOA account as compensation. Additionally, solvers can further optimize costs by bundling multiple intent executions into a single blockchain transaction.

Each solver is free to develop its own strategies for maximizing profitability. This proposal does not impose restrictions on how solvers execute intents, ensuring flexibility and adaptability in diverse execution scenarios.

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.

UserIntent schema

Each intent is a packed data structure containing sufficient information about the operations the account owner wants to execute. The core structure of a UserIntent object is as follows:

Field	Type	Description
sender	address	The address of the account initiating the intent.
standard	address	The IStandard implementation responsible for validating and parsing the UserIntent
header	bytes	Metadata associated with the UserIntent, interpreted by standard. Stored as bytes for flexibility.
instructions	bytes[]	The execution details of the UserIntent, interpreted by standard. Stored as bytes[] to allow flexibility.
signatures	bytes[]	Validatable signatures required for execution, interpreted by standard.

Fields Explanations

• header: The bytes header can carry information about how to validate the intent or how to prevent double-spending. For example, header can contain an uint256 nonce to check if the nonce is used already.
• instructions: These bytes instructions can just be concatenated (address,value,calldata) or can be standardized values, for example (erc20TokenAddress,1000) means the instructions can use up to 1000 of the specified ERC-20 token. It is NOT REQUIRED that all instructions MUST be provided by the EOA owner to allow dynamically carry out other operations during intent executions, but the IStandard design needs to carefully handle this case.
• signatures: The bytes signatures field can support different signing methods. It is NOT REQUIRED that all signatures MUST be provided by the EOA owner, some of them MAY be provided by solver, relayer or anyone else.

Pack UserIntent as Bytes

The UserIntent object is packed and encoded into bytes calldata userIntent. There is no strict schema requirement for the data structure. Each IAccount and IStandard implementation can define its own encoding and decoding methods for handling the bytes data.

Here is an example of packed-encoded format:

Section	Value Type	Description
userIntent[0:20]	address	sender
userIntent[20:40]	address	standard
userIntent[40:42]	uint16	Length of header
userIntent[42:44]	uint16	Length of instructions
userIntent[44:46]	uint16	Length of signatures
Next headerLength bytes	bytes	The actual header data
Next instructionsLength bytes	bytes	The actual instructions data
Next signatureLength bytes	bytes	The actual signatures data
Remaining bytes	bytes	Extra data, such as nested intents for further execution

IStandard Interface

Each standard defines how to parse and validate a UserIntent. Implementations of standard must conform to the IStandard interface:

The IStandard interface is responsible for defining and enforcing the validation logic for UserIntent objects.

It operates similarly to the EntryPoint in ERC-4337 and ERC-7521.

The extensibility of bytes4 return types allows future upgrades without modifying the function signatures.

IAccount Interface

On the account side, IAccount provides the interface for executing bytes calldata intent:

Using SET_CODE_TX_TYPE=0x04, EOAs can delegate contract code to an IAccount implementation, enabling them to function as smart accounts. A single account implementation can be shared across multiple EOAs, meaning:

• It only needs to be deployed and audited once.
• Each EOA owner is responsible for delegating their account to a secure IAccount implementation.

It is RECOMMENDED that each account leverages IStandard to validate and unpack operations, check Reference Implementation for examples. Account smart contract can be stateless to avoid sharing storage space with other delegated contracts.

Rationale

---

Usage of Bytes

Defining UserIntent object as a struct would improve readability and make it easier to work with in Solidity. For example:

However, this approach has several drawbacks:

• Mandating all IAccount and IStandard implementations to follow this specific struct format reduces flexibility.
• The use of bytes[] introduces additional gas costs due to Solidity's dynamic array encoding.

Since all objects within the UserIntent structure are optional and their usage depends on IStandard and IAccount implementations, the bytes format ensures maximum flexibility while preserving compatibility.

Execution in EOA Contract Code

With SET_CODE_TX_TYPE=0x04, EOAs gain the ability to execute contract code. Executing transactions directly from an EOA provides several key benefits:

• Preserves EOA Control: Execution remains fully controlled by the account owner. If needed, the EOA owner can easily disable all smart contract functionalities by un-delegating the contract code.
• Consistent msg.sender Behavior: Since the execution originates from an EOA, msg.sender always resolves to the EOA address, simplifying authentication and permission checks.
• Stateless Execution: The execution logic can be designed to be stateless, allowing the IAccount implementation to avoid storing persistent data, reducing storage costs.

If an EOA does not require smart contract execution, or if executing an intent is too expensive, the owner can still use the account as a regular EOA without any modifications.

Validation in the Standard Contract

Validation logic often relies on contract state. For example, a weighted multi-owner signature scheme needs to track the weight assigned to each signer. Keeping intent validation entirely within IStandard offers multiple advantages:

• Simplified Implementation: By mirroring the EntryPoint concept from ERC-4337 but in a simpler form, IStandard focuses solely on validation.
• Easier Auditing and Maintenance: Since IStandard is responsible only for validation, it becomes easier for contract engineers to implement, audit, and maintain.
• Modular Validation: The IStandard interface is inherently modular, allowing for more complex validation mechanisms. For instance, a "compound" standard could decompose an intent into smaller components, validate each separately, and then combine the results.

Gas Abstraction

This design enables gasless transactions by allowing any address to initiate a transaction on behalf of the intent's sender.

• The sender can specify how and what to pay in the intent’s header or instructions.
• Payments can be made in any token from the sender’s account.
• The transaction cost can be covered by transferring tokens from the sender’s account to tx.origin (the address submitting the transaction).

No re-entry protection enforced

This proposal does not enforce built-in re-entry protection mechanisms such as nonces. The rationale behind this decision is that certain intents are inherently designed to be executed multiple times.

Instead of a global re-entry protection mechanism, each standard should define its own protection rules based on its intended use case. Implementers are encouraged to:

Backwards Compatibility

---

This IAccount standard shares the same backwards compatibility considerations as the introduction of EOA contract code execution (SET_CODE_TX_TYPE=0x04).

Reference Implementation

---

Helper Library

This PackedIntent is a library to decode (address sender, address standard, uint16 headerLength, uint16 instructionsLength, uint16 signaturesLength) from a packed encoded intent. The following IAccount and IStandrd implementations both follow PackedIntent schema.

Relayed Execution Standard

This RelayedExecutionStandard allows relayer to execute the operations on chain and take ERC-20 token from the intent sender, thus achieve a gas-less experience for the sender.

Sample Account

The following IAccount implementation uses a StandardRegistry to maintain allowlist of standards and just batch execute all operations returned from IStandard.unpackOperations.

As shown above, the implementation of IAccount is stateless and simple, so that it can be compatible with different IStandard. While the IStandard implementation is complex because it needs to define its own schema. But both contracts will be public and audited, to ensure the security of intent execution.

Security Considerations

---

The security of this standard primarily depends on the implementation of both IStandard and IAccount. Each component must ensure that user intents are validated and executed safely. Additionally, solvers are responsible for securing their own execution environments to prevent unintended exploits.

Auditability of both Validation and Execution

To ensure security and maintain ecosystem integrity, it is critical that both the standard (IStandard) and account (IAccount) implementations are:

• Publicly auditable: Open access to contract code allows security researchers to identify potential vulnerabilities.
• Well-reviewed and shared: Public discussions and peer reviews help strengthen security assumptions.
• Secure against compatibility risks: Ensuring compatibility between different standard and account implementations can prevent unintended interactions that may lead to exploits.

Delegated Contract Storage Risks

If an IAccount implementation maintains state (instead of being stateless), it could:

• Interfere with other delegated contracts sharing the same storage.
• Be manipulated by unauthorized users if storage is not properly protected.

Strongly RECOMMEND stateless execution to prevent storage conflicts.

Copyright

---

Copyright and related rights waived via CC0.