EIP-8141 Frame Transaction

Appearance

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: ethereum/EIPs eip-8130.md

At a Glance ​

What it is. An account-abstraction standard where accounts declare their validation logic by registering an onchain authenticator contract (formerly called a verifier), without running wallet 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 authenticator, 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 authenticator interface (8130). Base is actively implementing 8130, which matters for how L2s adopt native AA in practice.

Overview ​

Summary provided by the author before the verifier-to-authenticator rename:

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 actors with onchain authenticator contracts. Transactions declare which authenticator 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 actors. Each actor is identified by an actorId (32-byte identifier derived by the authenticator from public key material) and associated with an authenticator contract, scope byte, optional expiry, and optional policy fields.

Authenticators: Contracts that implement authenticate(hash, data) via STATICCALL and return the authenticated actorId. The protocol routes by authenticator address:

  • K1_AUTHENTICATOR (address(1)) - native secp256k1, no EVM execution needed
  • Canonical authenticators - accepted by compliant nodes through the canonical set
  • Non-canonical authenticators - usable inside ordinary EVM/account-configuration flows, but not accepted for direct 8130 transaction authentication unless a node diverges from the canonical set

Implicit EOA Authorization: Every existing EOA can send AA transactions immediately, no registration needed. If the inline default-EOA config has not revoked the secp256k1 self actor and actorId == bytes32(bytes20(account)), it is 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 authenticator 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 authenticator via STATICCALL (or using a native implementation)
  3. Checking the returned actorId against the stored config

Nodes maintain a canonical authenticator set. For canonical authenticators with known gas bounds, no tracing infrastructure is needed. Non-canonical authenticators are rejected for direct 8130 transaction authentication unless a node intentionally diverges from the spec.

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 ​

AspectEIP-8130EIP-8141
Validation modelDeclarative: authenticator address in tx -> STATICCALL authenticatorProgrammable: arbitrary EVM in VERIFY frames
New opcodesNone6 (APPROVE, TXPARAM, FRAMEDATALOAD, FRAMEDATACOPY, FRAMEPARAM, SIGPARAM)
Mempool safetyStructural: canonical authenticator set, no wallet code executionBehavioral: banned opcodes, gas caps, validation prefix rules
Signature schemesDeploy authenticator contract, add to canonical setAccount code plus protocol signatures or ARBITRARY witnesses; verifier calls APPROVE
ExtensibilityPermissionless authenticator deployment, but nodes only accept canonical authenticators on the 8130 pathFully arbitrary within frame architecture
Gas sponsorshippayer + payer_auth fieldsVERIFY frame for sponsor
Atomic batchingCall phases (array of arrays)Flags field bit 2 on consecutive frames of any mode; validation-prefix batches are excluded from the restrictive mempool
Account creationCREATE2 via account_changesDEFAULT deploy frame through any trace-compatible factory
EOA supportImplicit secp256k1 authorization, auto-delegation to default walletDefault code (secp256k1 only; P256 is outer-list protocol validation but not default-code authorization)
Owner managementOnchain owner_config storage, portable config changesAccount code defines its own owner model
Cross-chainConfig changes with chain_id = 0 replay across chainsNot addressed
EIP-7702Delegation via account_changes entriesNo authorization list (PQ incompatible)
Async executionCompatible (no EVM in validation)Incompatible with async models (requires EVM for inclusion)

Activity ​

  • Sustained iteration from January through July 2026
  • EthMagicians thread at ethereum-magicians.org/t/eip-8130-account-abstraction-by-account-configurations/25952
  • Key participants: chunter (author), rmeissner (Safe), Helkomine, karlb (Celo)
  • Implementation: Base is implementing (per the author)
  • Celo migration interest (Jun 5 – Jun 30, 2026): karlb explores migrating Celo's CIP-64 fee-currency transactions onto EIP-8130 (thread posts #12-20). Two paths under discussion: a backwards-compatible shim where an RPC layer repackages CIP-64 transactions as EIP-8130 transactions with a CIP64Verifier validating the original signature, or native EIP-8130 signing with fee abstraction expressed in the call structure (sequencer as payer). chunter (post #19, Jun 29) notes that since authenticators just verify a hash, the CIP-64 preimage can be computed on the 8130 path with the rest of the machinery unchanged; karlb (post #20, Jun 30) pushes back that this still requires execution-client changes. First concrete L2 migration interest in EIP-8130 beyond Base.
  • Recent merges (June-July 2026): a sustained finalization burst landed across Jun 1 – Jul 13. The first wave (Jun 1 – Jun 10) shipped #11752, #11757, #11764 (owners -> actors), #11765, #11766, #11767, #11769, #11782, #11785 (verifier -> authenticator), #11791, and #11794. PR #11751 (delegated account creation) closed Jun 18 without merge. The July wave added #11847 (actor-policy clarification and opaque metadata simplification, merged Jul 2), #11903 (renumber AA_TX_TYPE to 0x79, AA_PAYER_TYPE to 0x7A, and add eth_call/eth_estimateGas support for AA transaction fields, merged Jul 8), and #11918 (scope-grant rework, merged Jul 13): the single PAYER grant splits into SELF_PAYER and SPONSOR_PAYER (self-pay vs. sponsorship is now defined relationally, by whether the payer account equals the sender account), the SIGNER scope bit is removed in favor of an operational := admin || (SENDER && !POLICY) predicate for ERC-1271 signing, and the account-lock lifecycle simplifies to lock/unlock only through a dedicated signed applySignedLockChanges call. A companion PR, #11919 (opened Jul 13, still open), lets initial actors carry an optional expiry at account creation/import instead of only through a post-creation config change. The terminology and RPC surface are now much closer to implementation-ready.
  • Tx-type renumbering explained on the thread (Jul 6 – Jul 8, 2026): chunter posts #21 (Jul 6) and #22 (Jul 8, thread post) walk through the AA_TX_TYPE/AA_PAYER_TYPE renumbering to 0x79/0x7A shipped in PR #11903, agreeing to keep exploring alternative type numbers and noting the OP-stack CIP-64 fork keeps that migration execution-layer-only until deprecation.
  • Base deployment signal (Jul 15, 2026): the AllWalletDevs #40 summary records chunter saying Base plans to launch EIP-8130 in its September fork. ERC-8286, the modular-account standard for EIP-8141, was presented in the same meeting, giving wallet developers a direct comparison between the two native-AA paths.
  • ERC-8340 metadata companion (opened Jul 15, 2026): ERC PR #1883 defines a deterministic CBOR layout for EIP-8130's opaque metadata field, including attribution, memos, call/phase scope, and selectively disclosed offchain commitments. It is a draft application-layer companion and does not change EIP-8130's core authentication or execution rules.

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: authenticator contracts are programmable (any signature logic can be expressed in an authenticator), while the canonical set + known gas bounds give nodes predictable validation cost. Lower VOPS / statelessness pressure than frame-based validation models (no wallet code during validation, simpler policy surfaces).
  • Async-execution compatible: nodes can implement authenticator logic natively for maximum throughput, compatible with Monad and async models (EIP-7886).
  • Incremental scheme adoption: nodes add new signature schemes by updating the canonical authenticator set, not via protocol upgrade.

Weaknesses ​

  • Validation expressiveness is bounded by the authenticator interface: authenticators implement authenticate(hash, data) -> actorId, which is pure authentication. Rules that require mutable state or complex side-effecting logic (time-based policies, state-dependent authorization) have to be expressed through actor scope/policy and execution-time gates. The author's framing is that this is still "programmable"; the counter-framing from EIP-8141 proponents is that the authenticator shape constrains expressiveness compared to full EVM in VERIFY frames.
  • Canonical-set coordination risk: nodes must agree on which authenticators are canonical. A fragmented authenticator 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.