EIP-8130: AA by Account Configuration

---

Author: Chris Hunter (@chunter-cb, Coinbase/Base) Status: Draft | Category: Core (Standards Track) Created: October 14, 2025 Requires: EIP-2718 (EIP-7702 dependency dropped Apr 14; EIP-8130 now defines its own delegation indicator) Latest spec: chunter-cb/EIPs eip-8130.md

At a Glance

What it is. An account-abstraction standard where accounts declare their validation logic by registering an onchain verifier contract, without running EVM code during transaction validation.

Problem it solves. Lets wallets ship programmable validation (passkeys, PQ signatures, custom policies) without the mempool complexity and statelessness pressure that comes from executing arbitrary account code inside the validation path. Nodes filter transactions by looking up the declared verifier, not by simulating wallet code.

Why an EIP-8141 reader should care. EIP-8130 is EIP-8141's most direct competitor. Both target native AA; they differ on whether validation is full EVM (8141) or a constrained verifier interface (8130). Base is actively implementing 8130, which matters for how L2s adopt native AA in practice.

Overview

Summary provided by the author:

EIP-8130 is a full cross-chain account standard with verifier-based validation that is both programmable and operationally predictable. Enables any validation logic, batched calls, gas abstraction while giving nodes simpler policy surfaces, better validation performance, and lower VOPS/statelessness pressure than frame-based validation models. It also gives multi-chain wallets a shared account standard for portability and provides an operating model for high-throughput chains. Base is implementing.

Concretely, EIP-8130 introduces a new EIP-2718 transaction type and an onchain Account Configuration system. Instead of allowing arbitrary EVM execution during validation (as EIP-8141 does), accounts register owners with onchain verifier contracts. Transactions declare which verifier to use, enabling nodes to filter transactions without executing wallet code. No EVM changes (no new opcodes) are required. For implementation details, see the latest spec.

Core Design

Account Configuration Contract: A system contract where accounts register owners. Each owner is identified by an ownerId (32-byte identifier derived by the verifier from public key material) and associated with a verifier contract and a scope byte (permission bitmask).

Verifiers: Contracts that implement verify(hash, data) via STATICCALL. The protocol routes by verifier address:

• ECRECOVER_VERIFIER (address(1)) — native secp256k1, no EVM execution needed
• Any other address — call the verifier contract
• Nodes maintain an allowlist of trusted verifiers with known gas bounds

Implicit EOA Authorization: Every existing EOA can send AA transactions immediately, no registration needed. If the owner_config slot is empty and ownerId == bytes32(bytes20(account)), it's implicitly authorized.

Transaction Format:

AA_TX_TYPE || rlp([
  chain_id, from, nonce_key, nonce_sequence, expiry,
  max_priority_fee_per_gas, max_fee_per_gas, gas_limit,
  account_changes, calls, payer,
  sender_auth, payer_auth
])

Call Phases: Calls are organized into phases. Within a phase, calls are atomic (all-or-nothing). Completed phases persist even if later phases revert. This enables patterns like [[sponsor_payment], [user_action_a, user_action_b]].

2D Nonce System: nonce_key selects the channel, nonce_sequence is the sequence within it. NONCE_KEY_MAX enables nonce-free mode with expiry-only replay protection.

Account Changes: A single transaction can create an account (CREATE2), modify owner configuration, and set EIP-7702-style delegation, all before call execution.

Gas Sponsorship: payer field declares the sponsor, payer_auth authenticates them using the same verifier infrastructure. The payer is charged for all gas.

Mempool Strategy

EIP-8130's key insight: validation never executes wallet code. Nodes verify by:

1. Reading owner_config (1 SLOAD)
2. Calling the declared verifier via STATICCALL (or using a native implementation)
3. Checking the returned ownerId against the stored config

Nodes maintain a verifier allowlist. For allowlisted verifiers with known gas bounds, no tracing infrastructure is needed. Unknown verifiers can be accepted with gas caps and opcode tracing, or rejected entirely.

Account Lock: When locked, the owner set is frozen. Nodes can cache owner state and apply higher mempool rate limits since only nonce consumption can invalidate transactions.

Key Differences from EIP-8141

Aspect	EIP-8130	EIP-8141
Validation model	Declarative: verifier address in tx → STATICCALL verifier	Programmable: arbitrary EVM in VERIFY frames
New opcodes	None	5 (APPROVE, TXPARAM, FRAMEDATALOAD, FRAMEDATACOPY, FRAMEPARAM)
Mempool safety	Structural: verifier allowlist, no wallet code execution	Behavioral: banned opcodes, gas caps, validation prefix rules
Signature schemes	Deploy verifier contract, add to node allowlist	Write account code that calls APPROVE
Extensibility	Permissionless verifier deployment, but nodes must adopt	Fully arbitrary within frame architecture
Gas sponsorship	payer + payer_auth fields	VERIFY frame for sponsor
Atomic batching	Call phases (array of arrays)	Flags field bit 2 on consecutive SENDER frames
Account creation	CREATE2 via account_changes	DEFAULT frame to deployer contract
EOA support	Implicit authorization, auto-delegation to default wallet	Default code (ECDSA + P256 verification)
Owner management	Onchain owner_config storage, portable config changes	Account code defines its own owner model
Cross-chain	Config changes with chain_id = 0 replay across chains	Not addressed
EIP-7702	Delegation via account_changes entries	No authorization list (PQ incompatible)
Async execution	Compatible (no EVM in validation)	Incompatible with async models (requires EVM for inclusion)

Activity

• 18 PRs (15 merged, 2 open, 1 closed), active iteration from January through April 2026
• 9 EthMagicians posts at ethereum-magicians.org/t/eip-8130-account-abstraction-by-account-configurations/25952
• Key participants: chunter (author), rmeissner (Safe), Helkomine
• Implementation: Base is implementing (per the author)
• Recent: PR #11492 (merged Apr 14) introduced REVOKED_VERIFIER sentinel, added native delegation indicator (dropping the EIP-7702 dependency from requires), and added DelegationApplied event. PR #11526 (open, Apr 15) renames from → sender throughout the spec.

Strengths

• Cross-chain account standard: shared account standard for multi-chain wallets, with owner config changes that can replay deterministically across chains (chain_id = 0).
• Programmable but operationally predictable validation: verifier contracts are programmable (any logic can be expressed in a verifier), while the allowlist + known gas bounds give nodes predictable validation cost. Lower VOPS / statelessness pressure than frame-based validation models (no EVM during validation, simpler policy surfaces).
• Async-execution compatible: nodes can implement verifier logic natively for maximum throughput, compatible with Monad and async models (EIP-7886).
• Incremental scheme adoption: nodes add new signature schemes by updating their verifier allowlist, not via protocol upgrade.

Weaknesses

• Validation expressiveness is bounded by the verifier interface: verifiers implement verify(hash, data) → ownerId, which is pure. Rules that require mutable state or complex side-effecting logic (time-based policies, state-dependent authorization) have to be expressed within this pure-verifier shape. The author's framing is that this is still "programmable," since the verifier itself is arbitrary code; the counter-framing from EIP-8141 proponents is that the verifier shape constrains expressiveness compared to full EVM in VERIFY frames.
• Node-coordination risk: nodes independently decide which verifiers to accept. A fragmented allowlist ecosystem could limit transaction propagation.
• New system-level infrastructure: the Account Configuration Contract and Nonce Manager are new protocol system contracts.
• No value in calls: calls carry no ETH value; ETH transfers require wallet bytecode.

---

Continue with Competing Standards for the comparative analysis, or return to the Home page.