Draft · Standards Track · Core

EIP-8130

Account Abstraction by Account Configuration

Native account abstraction. Performant, flexible, and built for the next generation of accounts.

No new opcodesNo EVM changesFastFlexibleLow Cost
Overview

What EIP-8130 provides

Foundational primitives for the next generation of wallet UX. Extensible and permissionless — build anything on top. Designed for high performance from the protocol up.

Flexible Authentication

Passkeys, hardware keys, or any signature scheme — all plugging into the same protocol. New auth methods can be added by anyone, no protocol change needed.

Built to Go Fast

Validation is optimizable. Nodes can cache, parallelize, and fast-path known algorithms. Gets faster and cheaper over time as clients optimize.

Shared Foundation

Protocol-level owner management that every wallet shares. Clients optimize one code path. Wallets skip reimplementing auth from scratch and ship features faster.

Flexible Gas Payment

Apps can pay gas for their users. Users can pay gas with ERC-20 tokens. New payment methods can be added by anyone, no protocol change needed.

New Capabilities

Privacy systems, high throughput accounts, and custom chain integrations — all built on a single transaction type. One transaction type, infinite capabilities.

Native Account Abstraction

Cheap, fast aa transactions without bundlers, entrypoints or special transaction receipt handling.

Features

Everything you need, nothing you don't

Gas abstraction, full owner management, low cost, familiar interfaces.

Authentication

Any Key Type

K1, WebAuthn, multisig, post-quantum. Extensible with permissionless verifier deployment for any signature scheme.

Gas

Flexible Gas Payment

Self-pay, sponsorship, ERC-20 gas and permissionless payment method deployment.

Throughput

High Throughput

Nonceless and 2D nonce transactions remove coordination overhead for parallel processing. Lock account configuration to unlock elevated mempool limits.

Execution

Call Phases

Native call phases with direct dispatch. Each phase is atomic. Completed phases persist even if later ones revert.

Accounts

Sub Accounts

One key can sign for a hierarchy of sub-accounts. A single owner controls multiple wallets with no extra keys.

Access Control

Scoped Owners

Each owner has an explicit role enforced natively by the account.

SENDERPAYERCONFIGSIGNATURE
Portability

Cross-Chain Key Sync

Fully portable owner management across chains with a single signed operation. One account, all EVM chains supported.

Onboarding

Existing and New Accounts

EOAs, existing smart wallets and new accounts can use the full feature set. Accounts can be created and synced in a single transaction.

Extensibility

Native Performance

Verifiers can be promoted to native implementations, lower costs for any wallet using it and increasing node performance.

Examples

See it in action

Real use cases, shown simply first — with full technical details for when you want them.

My Wallet

One tap does all of this

Deploy smart account
Register passkey as owner
Sponsor covers gas
Account Types

Every account has a path

Existing smart contracts migrate without redeployment. EOAs get instant AA. New accounts deploy with deterministic addresses.

Existing Smart Contracts

ERC-4337 wallets, Safes, and more

  1. 1Register owners via importAccount() — account's isValidSignature (ERC-1271) authorizes
  2. 2Update wallet to use ITxContext.getOwnerId() for per-owner authorization
  3. 3Ship — wallet accepts AA transactions alongside existing ERC-4337 flows

Zero redeployment. Existing validation logic (isValidSignature, validateUserOp) verifies the initial owner registration.

EOAs

Existing externally-owned accounts

  1. 1Send an AA transaction — that's it
  2. 2Protocol auto-delegates to DEFAULT_ACCOUNT_ADDRESS (EIP-7702 write)
  3. 3Account immediately functions as a smart wallet with owner infrastructure

Override anytime with a delegation entry in account_changes or a standard 7702 transaction. EOA owner is implicitly authorized by default.

New Accounts

Fresh smart accounts with CREATE2

  1. 1Include create entry in account_changes with bytecode and initial_owners
  2. 2Address derived via CREATE2 from ACCOUNT_CONFIG_ADDRESS — deterministic, counterfactual
  3. 3Owners registered, bytecode placed, then calls run initialization

Receive funds at counterfactual addresses before creation. initial_owners are salt-committed — front-running safe.

Cross-Chain Invariant

Same Address, every chain.

The Account Configuration Contract deploys at the same deterministic address on every EVM chain. Your wallet works anywhere without reconfiguration — and a single signed operation can update owners across all chains at once.

Same address, every chain

Deterministic CREATE2 deployment — your wallet works anywhere without reconfiguration

One signature, all chains

Config changes with chain_id = 0 replay on any chain — shared sequence counters order them deterministically

Portable owner management

Rotate keys, add owners, revoke credentials — one signed operation propagates everywhere

AccountConfig address

0x47B8020e...8cA21

Ethereum
Base
Optimism
Arbitrum
Polygon

Same address on all chains

Sub Accounts

One key. Many accounts.

Use the delegate verifier to make a single signing key authorize transactions across multiple sub-accounts. One passkey or hardware key controls an entire portfolio — a game, an app, a burner — each isolated, all signed with the same credential.

1

Register delegate verifier

Sub-account owner_config → verifier = DELEGATE_VERIFIER, owner_id = parent_key_hash

2

Sign with parent key

Parent account authorizes the signature — sub-accounts accept it natively

3

Execute across any sub-account

Each sub-account remains isolated; assets, permissions, and bytecode are independent

Parent Key

passkey / hardware

Game A

App B

Burner C

All authorized by
the same credential

Transaction Pipeline

From signature to block

A transaction's journey through EIP-8130 — from arrival to finalized receipt.

01

Tx Arrives

Parse and validate basic fields

Check expiry, verify nonce, check lock state if config changes present.

02

Load Owner

Parse sender auth for owner lookup or recovery

Read verifier address from first 20 bytes of sender_auth. Read owner_config (1 SLOAD). Implicit EOA rule if slot empty.

03

Validate Signature

Run against configured verifier

ECRECOVER_VERIFIER (address(0)) runs natively. Known verifiers MAY use native implementations. Other verifiers run via STATICCALL.

04

Resolve Payer

Deduct gas from payer

Self-pay or committed sponsor. Gas deducted upfront — payer must have sufficient balance.

05

Apply Account Changes

Create entry and owner changes — before code runs

Register owners, place bytecode. All pre-execution.

06

Execute Call Phases

Direct dispatch — calls go to their targets with msg.sender = from

Phases execute in order. Each phase is atomic. Completed phases persist even if later phases revert.

07

Finalize & Refund

Unused gas refunded to payer. Receipt emitted.

Status: 0x01 (all succeeded) or 0x00 (revert). Per-phase statuses in phaseStatuses array.

Validation state

Minimal

World state trie and Account Config contract only

Revalidation

Instant

Single SLOAD for stateless verifiers — revalidate cryptographic signatures instantly

Cost

Low

Nodes can replace validation with optimized native code due to explicit verifiers in the transaction

Performance

Performant and Optimizable

Validation is flexible enough to support any signature scheme, yet structured so nodes can execute it efficiently. Execution stays fully programmable. And as verifiers mature, they can be promoted to native — instantly cheaper for every user, everywhere.

Constrained Validation

Nonce, balance, expiry checksSimple state reads — no simulation
Load owner config1 SLOAD at a known address
Run verifierNative or STATICCALL — deterministic
Revalidation is instantSame state input → same result, cacheable

Deterministic. Cacheable. Parallelizable.

Programmable Execution

Full EVM programmabilityBatch calls, custom logic, any pattern
Scoped owner permissionsEach owner has a defined scope. [SENDER, PAYER, CONFIG, SIGNATURE]
Verifiers upgrade to nativeGas drops for all users instantly, no action needed
Permissionless deploymentAny verifier contract works immediately

Full EVM. Your code. No restrictions.

Verifiers can be upgraded to native

When a verifier contract proves itself in production, node clients can replace the STATICCALL with native code — dropping gas costs for every user everywhere, instantly, with no wallet changes or user action required.

Technical Specification

Dive into the spec

The full technical details — transaction format, storage layout, gas calculations, and Solidity interfaces.