concept L1 I2I + I2U
Native Account Abstraction (EIP-8141)
Make every Ethereum account natively programmable by replacing the hardcoded ECDSA `ecrecover` check with user-defined validation logic at the protocol level. Transactions are processed through the regular mempool using transaction frames that separate validation from execution. The design removes bundler and relayer dependencies, enables native gas sponsorship, and unlocks privacy patterns that currently require trusted off-protocol infrastructure.
CR
High
Censorship Resistance
O
Yes
Open Source
P
Partial
Privacy
S
High
Security
CROPS context
I2I
Institutions can mandate organisation-wide validation policies (for example, post-quantum-only signatures, multi-party approvals, per-role gas budgets) on accounts they control. Both parties retain legal recourse for operational failures and counterparties can audit validation code.
I2U
End users choose their own validation logic (passkeys, multisig, post-quantum signatures) without institutional lock-in. Crucially, native gas sponsorship removes the trusted relayer that today links stealth-address recipients to a funding account, so users are not forced to trust an operator to transact.
Works best when
Multiple signature schemes must coexist (ECDSA, post-quantum, passkeys).
Stealth address or shielded pool recipients need gas without pre-funding.
Protocol must support future cryptographic migrations without address changes.
Avoid when
Current EOA and ECDSA model is sufficient.
No post-quantum or auth agility requirements.
Intent
Make every Ethereum account natively programmable by replacing the hardcoded ECDSA ecrecover check with user-defined validation logic at the protocol level. Transactions are processed through the regular mempool using transaction frames that separate validation from execution. The design removes bundler and relayer dependencies, enables native gas sponsorship, and unlocks privacy patterns that currently require trusted off-protocol infrastructure.
Components
- Frame transaction: ordered list of frames per transaction. Each frame specifies a mode (
VERIFY,SENDER,DEFAULT), target address, gas limit, and data. Frames execute sequentially with independent gas metering. - Account validation code: per-account logic executed inside
VERIFYframes. It can validate any signature scheme (ECDSA, ML-DSA, SLH-DSA, passkeys, multisig) or any zero-knowledge proof. APPROVEopcode: called insideVERIFYframes to authorise execution (0x0), payment (0x1), or both (0x2). Payment approval decides who pays gas at runtime, decoupling authorisation of execution from gas payment.- Regular mempool: carries frame transactions alongside legacy transactions. No separate mempool or bundler network.
Protocol
1
[user] Sign and submit a frame transaction containing an ordered list of frames to the regular mempool. 2
[contract] Execute `VERIFY` frames as static calls. Each must call `APPROVE` with a scope (`0x0` execution, `0x1` payment, `0x2` both). If no frame approves payment, the transaction is invalid. 3
[contract] After validation passes, execute `SENDER`-mode frames with the sender as caller, and `DEFAULT`-mode frames with the protocol entry point as caller. 4
[contract] Charge gas to whichever account approved payment, which may differ from the sender. Guarantees & threat model
Guarantees:
- Auth agility: accounts migrate between signature schemes without changing address or moving assets.
- No bundler dependency: transactions use the regular mempool, preserving censorship resistance.
- Native gas sponsorship: stealth-address recipients and shielded-pool withdrawals can transact immediately without pre-funded ETH and without a trusted relayer. Fresh addresses are not linkable via gas-funding transactions.
- Privacy improvement: removes the relayer and paymaster centralisation vector that exists with ERC-4337 and out-of-protocol gas sponsorship.
Threat model:
- Bugs in per-account validation code can lock funds or allow unauthorised spends. Auditing burden shifts to account owners or standardised library authors.
- A malicious sponsor approving payment for a transaction they did not submit is still constrained by the
APPROVEsemantics; however, gas griefing through failed validation needs careful fee handling at the protocol level. - Does not hide transaction content. Network-level metadata (IP, timing) remains a separate concern.
Trade-offs
- Draft status: EIP-8141 is being discussed as a potential headliner for a future fork but is not finalised. Production use is not available.
- Migration path: wallets, dApps, indexers, and tooling must be updated. Existing EOAs need an upgrade path.
- Validation code risk: custom validation logic introduces a new class of account-level vulnerabilities. Standardised, audited libraries mitigate this.
- Mempool propagation: nodes need to validate frame transactions before relaying, which slightly increases propagation cost compared to legacy transactions.
Post-quantum
low risk Vector: Per-account validation decouples the signature scheme from the address. Accounts can rotate ECDSA to ML-DSA or SLH-DSA without redeploying or moving funds.
Mitigation: Direct enabler of post-quantum migration on the execution layer. See Post-Quantum Threats.
Example
- A user receives funds at a stealth address. A sponsor (or the user's main account) approves payment for the stealth account's first transaction. No relayer, no paymaster, and no on-chain link between the stealth address and the funding account. The stealth account uses passkey validation initially. Later, the user rotates validation logic to ML-DSA for post-quantum safety: same address, same funds, new signature scheme.
Open-source implementations