ERC-7806 is an Ethereum standard that defines the minimal interface required for intent-centric smart accounts. Authored by the pseudonymous developer hellohanchen and first posted to the EIP repository on November 2, 2024, it introduces two composable interfaces: IStandard for validation, and IAccount for execution. The standard requires EIP-7702's SET_CODE_TX_TYPE to let EOAs delegate to account implementations without deploying a new contract, and deliberately omits the infrastructure requirements that make ERC-4337 complex. There is no EntryPoint contract, no alt-mempool bundler, no globally shared singleton. Any solver can submit signed intents on behalf of an account owner by calling IAccount directly through the standard transaction mempool.
​

ERC-7806 is an Ethereum Request for Comment that defines a minimal account abstraction standard for smart accounts built on EIP-7702. It specifies two interfaces: IStandard, which validates and unpacks signed intents, and IAccount, which executes the unpacked operations. The standard holds Draft status as of April 2026 and is authored by the pseudonymous developer hellohanchen.
​

The proposal targets a practical gap. ERC-4337's specification requires "multiple interdependent components including the Account, EntryPoint, Paymaster, and Bundler." Upgrading any single component can break others. Gas costs are elevated by the EntryPoint's verification loop. Despite the permissionless design, a small set of centralized bundler operators handles the majority of UserOperation throughput in practice. As of April 2026, BundleBear tracks over 1.07 billion UserOperations processed through ERC-4337 across 56.8 million accounts on 12 chains. That scale reflects ERC-4337's maturity, not its simplicity.
​

ERC-7806 strips the model to its minimum. Validation lives in a standalone IStandard contract. Execution lives in an IAccount. There is no shared global contract between them. Different intents can reference different IStandard implementations within the same account, so an account can support multiple validation schemas simultaneously without installing new modules or modifying its core code. The standard requires EIP-7702 as a dependency, meaning an EOA must use a Type 4 (SET_CODE_TX_TYPE) transaction to delegate its code field to an IAccount implementation before the account can receive and execute intents.
​

The choice of bytes-first encoding throughout the UserIntent schema is deliberate. By encoding all intent fields as raw bytes rather than typed structs, ERC-7806 avoids encoding dependencies between the core standard and its implementers. An IStandard implementation defines its own encoding for the header and instructions fields, its own validation logic, and its own replay-protection mechanism. Two IStandard implementations can coexist in the same ecosystem without any shared ABI dependency, and upgrading one does not affect the other.
​

ERC-7806 works through a five-step lifecycle: EOA owner delegates code via EIP-7702, signs a UserIntent packed as bytes, a solver submits the intent onchain, IStandard validates and unpacks operations, and IAccount executes in batch and compensates the solver. No step requires shared global infrastructure beyond the two interface contracts and the delegation.
​

The UserIntent schema contains five fields. Sender is the account address initiating the intent. Standard is the IStandard implementation address for this specific intent. Header is metadata interpreted by the standard. Instructions holds execution details in flexible format. Signatures contains validatable byte arrays. All fields use raw bytes format. This encoding design means the ERC-7806 core standard does not define what an intent means; the IStandard contract at the address in the standard field defines it. Different applications can deploy domain-specific IStandard contracts that encode intents in completely different ways, and an IAccount implementation only needs to call the IStandard's two functions without understanding the encoding itself.
​

The IStandard interface exposes two functions. validateUserIntent(bytes calldata intent) returns a 4-byte selector confirming validity. unpackOperations(bytes calldata intent) returns a tuple of a bytes4 execution mode and a bytes array of individual operations. The ERC-7806 specification strongly recommends that IStandard implementations be stateless. Because the same IStandard contract may be referenced by many EOAs that have delegated to the same IAccount code, any storage writes inside IStandard would create cross-account interference through the DELEGATECALL semantics that EIP-7702 imposes.
​

Replay protection is each IStandard's responsibility. The core ERC-7806 standard defines no built-in nonce scheme. A production IStandard should verify a chain ID, a nonce or timestamp, and any domain-specific replay identifiers as part of the validateUserIntent call. The reference RelayedExecutionStandard included in the ERC-7806 specification demonstrates one approach: it checks the sender's signature over the full packed intent, verifies chain ID and nonce against the account's storage, and unpacks instructions into a list of call targets and calldata arrays. The reference implementation runs to approximately 80 lines of Solidity, illustrating how compact the standard's footprint is compared to ERC-4337's full verification loop which spans the EntryPoint contract, the account's validateUserOp function, and the bundler's pre-flight simulation logic.
​

The IAccount interface exposes a single function: executeUserIntent(bytes calldata intent). The account calls the IStandard referenced in the intent for validation and unpacking, then executes the returned operations in batch, and returns a bytes result. The reference implementation, AccountImplV0, handles batch execution of call arrays atomically. ERC-7806 specifies no built-in reentrancy protection at the interface level; each IStandard defines its own, since reentrancy risks are tied to the specific logic of each validation and execution flow.
​

The solver model is central to IAccount execution. Solvers are off-chain or onchain actors that submit valid signed intents to the network on behalf of account owners. The ERC-7806 model is solver-agnostic: any address can submit a valid signed intent. Solver compensation is settled inside the execution phase rather than through a paymaster pre-approval step. This contrasts with ERC-4337's paymaster architecture, where gas sponsorship requires upfront deposits into a specific paymaster contract and withdrawal flows that add operational overhead. ERC-7806 solvers collect fees from the account during execution itself, which aligns solver incentives with successful execution and removes deposit management from the critical path.
​

ERC-7806, ERC-4337, and ERC-7579 each take a different approach to smart account architecture. ERC-4337 uses a shared EntryPoint and bundler infrastructure. ERC-7579, a Draft from December 2023, adds formal module types (validator, executor, fallback, hook) on top of ERC-4337. ERC-7806 is a minimal two-interface standard that requires neither the EntryPoint nor a module registry.
​

The most actionable distinction between ERC-7806 and ERC-4337 is infrastructure overhead. ERC-4337 requires teams to run or integrate a bundler, manage EntryPoint deposits, and build for ERC-4337's specific UserOperation encoding with its packed and unpacked variants across v0.6, v0.7, and v0.9. ERC-7806 requires an IStandard, an IAccount, and an EIP-7702 delegation. The difference in lines of supporting infrastructure code is substantial. For teams building their first smart account product or running a lean embedded-wallet stack, ERC-7806's surface area is far smaller.
​

Against ERC-7579, ERC-7806 is narrower in scope and more opinionated about intent encoding. ERC-7579 defines formal module types (validator, executor, fallback, hook) and requires implementing accountId, supportsExecutionMode, supportsModule, and module installation functions. ERC-7579 is designed for accounts that need a rich module ecosystem where third-party validators and executors can be installed and uninstalled without changing the core account contract. ERC-7806 is designed for accounts where simplicity and EIP-7702 compatibility matter more than a formal module registry. The two are not mutually exclusive in principle; an account could implement both ERC-7579's module interfaces and ERC-7806's IAccount interface, though no reference implementation combining them exists in the ERC-7806 specification.
​

ERC-7806's minimal design makes it suited for embedded wallets, lightweight mobile accounts, and intent-based applications where the full ERC-4337 stack would add disproportionate complexity and cost. The stateless IStandard model and solver-agnostic execution also fit protocol designs where users express desired outcomes rather than specific transaction sequences.
​

Embedded wallets, where a smart account is provisioned inside a mobile app or web product without the user ever seeing a wallet interface, benefit from ERC-7806's minimal footprint. An app SDK can delegate an EOA to a lightweight IAccount implementation via EIP-7702, configure a single IStandard for signature validation, and enable gasless transactions through solver-settled execution. The user never interacts with gas or bundlers. Because ERC-7806 avoids EntryPoint and bundler overhead, the deployment and maintenance cost for apps running millions of embedded accounts scales linearly with user count rather than adding infrastructure layers at each order of magnitude.
​

The stateless recommendation also reduces storage collision risks in shared-code scenarios. When many EOAs delegate to the same IAccount implementation, EIP-7702's DELEGATECALL semantics ensure that state written during execution is isolated to each account's own storage. The IStandard, recommended stateless, does not write to any account's storage at all, eliminating a class of cross-account interference that is a known risk in shared-singleton architectures.
​

ERC-7806's architecture maps naturally onto intent-based protocols. The UserIntent schema's bytes-format flexibility lets applications define domain-specific intent languages. A DeFi swap intent might encode token-in, token-out, slippage tolerance, and execution deadline in the instructions field, with an IStandard that validates the account's signature and verifies the swap parameters against current market conditions. A payment intent might encode recipient, amount, and currency, with an IStandard that confirms the sender's authorization and validates the nonce. Each application deploys its own IStandard, and any solver that can interpret that IStandard's encoding can compete to execute.
​

The solver-payment model fits competitive solver markets better than ERC-4337 paymasters. In ERC-4337, gas sponsorship requires upfront deposits into a specific paymaster contract, and the paymaster's coverage policies determine what transactions get sponsored. In ERC-7806, the solver collects its fee from the account during the execution phase itself. New solvers can enter a market by implementing the relevant IStandard without any pre-existing relationship with a paymaster. This lowers the barrier to solver participation and increases inclusion competition for intent-based transactions.
​

The minimal interface footprint makes ERC-7806 useful for prototyping and testing smart account behavior without deploying full ERC-4337 infrastructure. A developer can write an IStandard, deploy it to a testnet, delegate an EOA via EIP-7702, and test intent execution without running a bundler or managing a separate mempool. The reference implementations for IStandard (RelayedExecutionStandard) and IAccount (AccountImplV0) are included in the ERC-7806 specification and can be deployed with standard Ethereum tooling like Hardhat or Foundry. This makes ERC-7806 a practical entry point for teams exploring account abstraction before committing to a full ERC-4337 integration.
​

ERC-7806 places security responsibilities on IStandard implementers rather than encoding them in a shared contract. This is both a strength and a structural risk. Shared infrastructure like ERC-4337's EntryPoint receives concentrated security review from a large developer community. ERC-7806 IStandard contracts are individually deployed and individually audited, which means security quality varies with each implementing team's rigor and resources.
​

The ERC-7806 specification identifies four requirements. First, both IStandard and IAccount code must be public and auditable before production deployment. Second, IStandard implementations are strongly recommended to be stateless to prevent storage interference across accounts sharing the same implementation code. Third, solvers are responsible for securing their execution environments, since any address can act as a solver. Fourth, each IStandard must define its own replay-protection mechanism, since ERC-7806 provides no built-in nonce or chain ID check in the core interface.
​

The bytes-first encoding that makes ERC-7806 flexible also concentrates validation risk in the IStandard. An IStandard that fails to validate intent fields completely could authorize unintended operations at the account level. The intent bytes should be treated as untrusted input, with every field the authorization logic depends on verified explicitly. In particular, the chain ID should be checked to prevent cross-chain replay, the nonce or timestamp should be checked to prevent replay within a chain, and the signature should cover the complete packed intent bytes rather than a partial digest to prevent signature malleability attacks. The EIP-712 typed structured data standard is a natural fit for IStandard signature schemes, as it provides domain separation, human-readable signing prompts, and protection against cross-protocol replay in a well-audited encoding format.
​

The solver model introduces a separate consideration. Because any address can submit a valid intent, account owners should verify that their IStandard's validateUserIntent function checks the sender's authorization independently of who submits the intent. The validation and execution separation in ERC-7806 is designed so that a malicious solver cannot forge a valid intent; they can only submit one. Provided the IStandard validates the account owner's signature over the full intent bytes, a malicious solver gains nothing by submitting the same signed intent twice beyond normal replay-protection checks.
​

Teams building IStandard implementations should study prior smart account audits for known vulnerability classes. The ERC-4337 EntryPoint v0.6 audit by Quantstamp and the broader history of smart account exploits across early ERC-4337 deployments provide a useful reference for the categories of validation bugs most likely to appear in new account abstraction implementations, including signature scope issues, storage access side effects, and missing nonce checks.
​

ERC-7806 reduces the infrastructure cost of smart account deployments at scale. Gas paid in any token, batched payment operations in a single intent, and solver-delegated execution remove the friction points that have limited EVM-based consumer payments. The solver-settled model means end users never interact with gas or bundlers directly.
​

The intent-centric model also maps well to how payments actually work. A payment is an expression of a desired outcome (transfer N tokens from sender to recipient) rather than a specific transaction sequence. ERC-7806's IStandard design allows payment-focused applications to define payment intents as a domain-specific standard, with solvers competing to execute those intents across chains and liquidity venues. This composability is difficult to achieve cleanly in ERC-4337, where the execution model is tightly coupled to UserOperation encoding and bundler policies.
​

Eco supports smart account-compatible infrastructure across 15 chains including Ethereum, Base, Arbitrum, Optimism, Polygon, and Solana. As ERC-7806 matures from Draft status toward production deployments, Eco Routes handles cross-chain routing and settlement so that applications using emerging account abstraction standards do not need to rebuild routing logic per chain.
​

ERC-7806 holds Draft status as of April 2026. Reference implementations are available in the specification but no production deployment is confirmed on Ethereum mainnet. Developers can test IStandard and IAccount implementations on testnets using standard tooling and EIP-7702-compatible EOA delegation. Monitor the ERC-7806 specification for status updates.
​

Yes. ERC-7806 lists EIP-7702 as a required dependency. An EOA uses EIP-7702's SET_CODE_TX_TYPE (Type 4 transaction) to delegate its code field to an IAccount implementation before it can receive and execute intents. EIP-7702 activated in the Ethereum Pectra hard fork in 2025 and is available on Ethereum mainnet and compatible EVM chains.
​

IStandard handles intent validation and operation unpacking; it is not a gas sponsorship mechanism. Gas sponsorship in ERC-7806 is handled by the solver, which settles payment inside the execution phase rather than through a pre-funded paymaster contract. ERC-4337 paymasters require upfront EntryPoint deposits; ERC-7806 solvers collect fees directly from the account during execution, removing deposit management from the infrastructure stack.
​

Not directly. ERC-7806 uses a different intent schema, different validation interfaces, and the standard mempool rather than the alt mempool. ERC-4337 bundler and paymaster infrastructure is not compatible with ERC-7806 intents out of the box. Teams migrating from ERC-4337 to ERC-7806 would need to build or adopt a solver that understands the IStandard interface and submit intents through standard mempool transactions.
​

ERC-7806 applies wherever EIP-7702 is supported. Any EVM-compatible chain that has activated Pectra or an equivalent EIP-7702 integration can support ERC-7806 deployments. As of April 2026, EIP-7702 is live on Ethereum mainnet and being integrated on EVM-compatible L2s including Base, Optimism, and Arbitrum.
​

Sources and methodology. ERC-7806 specification pulled from eips.ethereum.org on April 30, 2026. ERC-4337 adoption figures (1.07B UserOperations, 56.8M accounts) from BundleBear, April 2026. ERC-7579 specification pulled from EIP-7579. EIP-7702 activation status verified against Ethereum Pectra hard fork records. All figures reflect state as of April 30, 2026.
​