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-155, EIP-170, EIP-712, ERC-1271, EIP-1559, EIP-2028, EIP-2718, EIP-2929, ERC-4337, EIP-6780, EIP-7702, EIP-7708, EIP-7819 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 Keystore. 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 are required. The core EIP now carries only protocol-visible behavior; exact Keystore storage, ABI, type hashes, and code live in the canonical Base repository.

Core Design ​

Keystore Contract: A system contract where accounts register actors. Each actor is identified by a 32-byte actorId derived by the authenticator and associated with an authenticator contract, uint16 scope, optional expiry, and optional policy fields. Address-derived actor IDs are right-aligned in the low 20 bytes after PR #12173.

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, sender, nonce_key, nonce_sequence, valid_after, valid_before,
  max_priority_fee_per_gas, max_fee_per_gas, gas_limit,
  account_changes, calls, metadata, 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 a short valid_before window and consensus replay identifier.

Validity Window: valid_after and valid_before are uint64 Unix milliseconds. Actor and lock expiries remain second-denominated.

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 the actor's packed actor_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, actor configuration is frozen. Nodes can cache the 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 opcodesNone7 (APPROVE, TXPARAM, FRAMEDATALOAD, FRAMEDATACOPY, FRAMEPARAM, SIGPARAM, SIGDATACOPY)
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 DEFAULT/SENDER frames; VERIFY and approval scope are statically excluded
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 Keystore actor configuration, 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 August 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.
  • Keystore alignment and validity windows (Aug 11, 2026): PR #12135 renames the Account Configuration contract to the Keystore, replaces a single expiry with millisecond valid_after/valid_before bounds, separates local epoch and sequence, consolidates signed changes, and moves contract internals to the canonical Base repository. The +214/-312 rewrite deliberately narrows the EIP to protocol surface.
  • Audit reconciliation (Aug 12, 2026): PR #12148 aligns self-actor revocation, canonical-authenticator enforcement, and expired unsequenced/JIT grant behavior with the Keystore implementation.
  • Actor ID encoding (Aug 14, 2026): PR #12173 right-aligns address-derived actor IDs in the low 20 bytes, matching the reference contract, and clarifies self-actor revocation.

Strengths ​

  • Cross-chain account standard: shared Keystore model for multi-chain wallets, with actor 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 Keystore and Nonce Manager are new protocol system contracts, with canonical contract internals maintained outside the core EIP.
  • 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.