EIP-8141 Frame Transaction

Appearance

EIP-8130 + EIP-8430: Keystore Accounts and AA Transaction Type ​

Author: Chris Hunter (@chunter-cb, Coinbase/Base) Standards: two sibling Core (Standards Track) drafts that together form one alternative to EIP-8141

  • EIP-8130 Keystore Accounts: Draft, created October 14, 2025; requires EIP-170, EIP-1014. Spec
  • EIP-8430 AA Transaction Type: Draft (PR #12385), created September 23, 2026; requires EIP-1559, EIP-2718, EIP-2929, EIP-7623, EIP-7702

History: EIP-8130 was "Account Abstraction by Account Configuration", a single EIP bundling the Keystore with its own transaction type. It was renamed Keystore Accounts by PR #12295 (Sep 3, 2026), and PR #12386 (merged Oct 8, 2026) moved the transaction type into EIP-8430.

At a Glance ​

What it is. Coinbase/Base's native-AA design, now specified as two sibling standards. EIP-8430 is a fixed-cost EIP-2718 transaction type (0x79) that gives today's secp256k1 EOAs batched calls, gas sponsorship, two-dimensional nonces, and in-band EIP-7702-style delegation. EIP-8130 is an onchain Keystore where each account registers actors, each bound to an authenticator contract, with a per-actor scope, expiry, and optional policy. EIP-8130 specifies how the Keystore plugs into EIP-8430's extension points.

Problem it solves. Delivers wallet UX features and a portable, crypto-agile authority model (passkeys, PQ authenticators, session keys, delegation) without executing wallet code during validation. Nodes check one signature per role, or one Keystore config read plus a known authenticator, instead of simulating account code.

Why an EIP-8141 reader should care. The pair is EIP-8141's most direct alternative. Both target native AA; they differ on whether validation is full EVM (8141) or a fixed transaction type with a declarative authority registry (8130 + 8430). The split also opened an interop path: the Keystore text names "EIP-8141 frame accounts" as a consumer, so the authority layer can sit under frames while the transaction formats compete. Base lists EIP-8430 as "Base Transactions" for its Everest upgrade.

Overview ​

The author's rationale for splitting into siblings (EIP-8430 thread, post #1, Sep 30): the transaction type is useful on its own and "can ship first" for today's EOAs, while the Keystore is useful without it "through ERC-4337, direct contract calls, or other native transports such as frame transactions (EIP-8141)." Both texts state that neither EIP requires the other, but each is designed around the other: EIP-8430 reserves an authenticator selector, an authorization-rules hook, and typed account-change entries, and EIP-8130 specifies how the Keystore fills them.

On its own, EIP-8430 authenticates only with native secp256k1 (K1_AUTHENTICATOR = address(1)). Richer and post-quantum authentication arrive through the Keystore integration. The Keystore's exact storage packing, typehashes, and function bodies live in the canonical Base repository, which EIP-8130 declares authoritative for contract internals.

Core Design ​

EIP-8430: the transaction type ​

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 is an array of phases. Calls inside a phase are atomic; completed phases persist if a later phase reverts. Calls carry native value, charged a static TX_VALUE_COST = 6,000.

Sponsorship: payer is empty for self-pay, 0x00 for an open payer recovered from payer_auth, or a named sponsor. AA_PAYER_TYPE = 0x7A domain-separates payer signatures, and payer authentication is metered outside gas_limit up to MAX_AUTHENTICATION_GAS (suggested 100,000).

Nonces: nonce_key selects a channel and nonce_sequence orders it through a Nonce Manager precompile at 0x8130...aa01. NONCE_KEY_MAX selects nonce-free mode, backed by a consensus replay_id ring buffer and a short validity window.

Validity window: valid_after and valid_before accept seconds or milliseconds, auto-detected at TIMESTAMP_MS_THRESHOLD = 10^11.

Account changes: typed entries; 0x01 is an in-band 7702-style delegation (secp256k1 only, for portability to 7702-only chains). With the Keystore, 0x02 creates an account and 0x03 applies a config change. The pre-split design auto-delegated codeless EOAs to a default account; EIP-8430 delegates nothing automatically.

Costs: AA_BASE_COST = 15,000 and K1_AUTH_COST = 5,100 (ecrecover plus one cold account read, pre-charging the Keystore lookup). The EIP-7623 calldata floor applies (PR #12320).

EIP-8130: the Keystore ​

Actors and authenticators: each actor is a 32-byte actorId derived by its authenticator, which implements authenticate(hash, data) -> actorId. The canonical set (k1 as a native sentinel at address(1), p256, passkey/WebAuthn, and a delegate authenticator) is what every natively validating consumer must accept at an enshrined cost. Any contract can be registered; whether a consumer accepts it on a validation path is that consumer's policy (Permissive, typically L1, or Canonical-only, typically L2).

Config slot: one actor_config slot packs authenticator(20) || expiry(6) || scope(2) || reserved(4). Validity is decided by that single read.

Scopes (after PR #12333): 0x0000 is admin; OPERATOR 0x01, SELF_PAYER 0x02, SPONSOR_PAYER 0x04, POLICY 0x08, NONCE 0x10. A POLICY actor may only call its policy_manager, which enforces limits such as session-key spend caps.

Change channels: signed account-change batches are sequenced on a local channel (local_epoch || local_sequence, with epoch bumps cancelling unlanded signatures) and a multichain channel that replays across chains with chain_id = 0.

Account lock: a locked account rejects authority changes until a timed unlock, letting consumers cache configuration and grant higher mempool rate limits.

Account types: an EOA's own key is an implicit admin self-actor with no Keystore write; existing smart accounts call importAccount() and return their actors via confirmKeystoreImport(); new accounts use CREATE2 through createAccount.

Consumers: a transaction type that validates against the Keystore natively (EIP-8430), a frame account whose VERIFY code calls it, an ERC-4337 account, or an application verifying signatures.

Mempool Strategy ​

The pair's key insight is unchanged by the split: validation never executes wallet code. For a plain EIP-8430 transaction a node performs one secp256k1 recovery per role plus nonce, balance, and validity-window checks. With the Keystore, it reads the actor's actor_config (one SLOAD), calls the declared authenticator via STATICCALL or a native implementation, and checks the returned actorId. Canonical authenticators with known gas bounds need no tracing, and account lock gives nodes a cacheable state where only nonce consumption can invalidate pending transactions.

A frame account that consumes the Keystore does so from its VERIFY frame, so EIP-8141's restrictive-tier rules still apply to that call. EIP-8397 gives frame accounts a protocol-level AUTHENTICATOR signature scheme whose authenticate(bytes32,bytes) interface is ABI-identical to the Keystore's IAuthenticator.

Key Differences from EIP-8141 ​

AspectEIP-8130 + EIP-8430EIP-8141
Validation modelDeclarative: fixed secp256k1, or one Keystore read plus authenticator STATICCALLProgrammable: arbitrary EVM in VERIFY frames plus protocol signatures
PQ pathVia a canonical PQ authenticator in the Keystore; none for EIP-8430 aloneAccount code, ARBITRARY witnesses, EIP-8397 authenticators, EIP-8288 aggregation
New opcodesNone (Nonce Manager and Tx Context precompiles)7
BatchingCall phases, per-phase atomicityAtomic-batch flag on consecutive DEFAULT/SENDER frames
Sponsorshippayer + payer_auth (self, open, or named)Sponsor VERIFY frame calling APPROVE
NoncesNonce Manager precompile, nonce-free ring bufferProtocol nonce; keyed nonces via EIP-8250, expiring nonces via EIP-8266
Owner managementOnchain actors, scopes, expiry, policies, lockAccount code defines its own model (ERC-8286 modules, ERC-8403 authority lifecycle)
Cross-chainMultichain change channel replays with chain_id = 0Not addressed in the base EIP
EOA supportNative secp256k1 transactions; no auto-delegation after the splitDefault code (secp256k1 only)
DelegationIn-band 7702-style account_changesNo authorization list
RelationshipKeystore names EIP-8141 frame accounts as a consumerDoes not reference the Keystore
Hegotá statusNot tracked in the L1 meta-EIPScheduled for Inclusion (Aug 27)

Activity ​

  • Threads: EIP-8130 and EIP-8430. Key participants: chunter (author), rmeissner (Safe), Helkomine, karlb (Celo), Agusx1211 (Sequence), chugarchugarr, AnkushinDaniil.
  • Jan – Jul 2026: sustained finalization of the then-single EIP, including the owners -> actors and verifier -> authenticator renames (June), the SELF_PAYER/SPONSOR_PAYER scope split (#11918, Jul 13), and renumbering the transaction type to 0x79/0x7A (#11903). karlb explored migrating Celo's CIP-64 fee-currency transactions onto it (posts #12-20). AllWalletDevs #40 (Jul 15) recorded a plan to launch on Base in September.
  • Aug 11 – 19, 2026: PRs #12135, #12148, and #12173 aligned the text with the canonical Keystore contract, added validity windows, reconciled audit findings, and right-aligned actor IDs. PR #12204 (Aug 19) added L1/L2 adoption profiles, bounded MAX_AUTHENTICATION_GAS, and seconds-or-milliseconds timestamps.
  • Keystore companion drafts (Aug 21 – 25): chunter opened EIP-8386 Transaction Events View, EIP-8387 Stateless Accounts, EIP-8388 Keystore Signatures for Execution Txs, and Keystore Expired Actor Pruning, all requiring EIP-8130. Editor jochem-brouwer requested changes on each; none has merged.
  • L1 alignment (Aug 25 – Sep 1): at Frame Transaction Breakout #2, chunter signalled Base could delay its fork to align with L1. ACDE #244 (Aug 27) moved EIP-8141 to SFI and set weekly AA calls, with a Devcon deadline, to reach either a shared transaction type or interop. At Breakout #3, chunter presented ideas for unifying the 8130 and 8141 authority models.
  • Decomposition proposals (Aug 27 – Sep 10): pedrouid's PR #12248 proposed splitting the design into three EIPs (a native 0x79 transaction, a portable Keystore, and advanced controls); editors asked for one EIP per PR and it closed Sep 3. pedrouid's open PRs #12293 and #12313 propose optional checkpointed Keystore and checkpointed-actor variants; Agusx1211 argued admin freshness across chains is still missing.
  • Rename and sync (Sep 3 – 16): #12295 renamed EIP-8130 to Keystore Accounts; #12333 reordered scope bits to match the canonical repository; #12320 applied the EIP-7623 calldata floor after karlb (post #33) measured type 0x79 walking around it.
  • Frames-based implementation (Sep 22): at Breakout #5, ETHLabs presented an EIP-8130 account standard built on top of frame transactions.
  • Sibling split (Sep 28 – Oct 8): PR #12385 (EIP-8430, numbered Sep 29, still awaiting one editor review) opened alongside #12386, which scoped EIP-8130 to the Keystore. Draft #12462 (Oct 8) proposes a thinner Keystore with two scope bits and no account lock.
  • EIP-8430 thread (Sep 30 – Oct 2): chugarchugarr proposed a per-entry replay projection because replay_id commits raw account_changes; AnkushinDaniil noted that EIP-8430's Nonce Manager and EIP-8250's manager for frame transactions would create two lanes for the same key on a chain with both. chunter is open to a shared manager "as long as it gives us the same capability."
  • Open interop work: AnkushinDaniil's #12341 proposes a model-neutral change digest so one signed key change carries across the Keystore, frame accounts, and chains (companion to ERC-8403). Coinbase's ERC-8168 payer service now builds both EIP-8130 + EIP-8430 and EIP-8141 transactions.
  • Base deployment: Cobalt shipped Sep 30 without native AA. Base's upgrades page now lists EIP-8430 as "Base Transactions" in the Everest upgrade (November 2026 planning target, dates to be announced); the Keystore is not yet on that page.

Strengths ​

  • Ships for today's EOAs: the EIP-8430 feature set needs no registration, smart account, or Keystore.
  • Predictable validation: fixed secp256k1 checks, or one config read plus a known authenticator; no tracing or banned-opcode lists, and native hot-path implementations remain possible.
  • Transport-neutral authority: the same Keystore actor means the same thing on EIP-8430, a frame account, an ERC-4337 account, or in ERC-1271 signature checks.
  • Crypto agility without migration: adopting a newly canonical scheme is a new actor, not a new address.
  • Built-in account management: scopes, expiry, policies, delegation, lock, and cross-chain replayable changes.

Weaknesses ​

  • No post-quantum path without the Keystore: EIP-8430 alone is secp256k1 only.
  • Expressiveness bounded by the authenticator interface: rules that need mutable state or multi-step logic move into policy managers or execution-time gates.
  • Canonical-set coordination: natively validating consumers must agree on the set; L1 changes it only by hard fork.
  • Cross-chain freshness: revocations take effect only where relayed, the open concern behind the checkpointed-Keystore and freshness-hook proposals.
  • Parallel infrastructure: a second nonce manager, context precompile, and replay buffer alongside any frame-transaction stack, unless the EIP-8250 manager is shared.
  • Off-spec internals and L2-first trajectory: Keystore internals are authoritative in an external repository, and neither EIP is tracked in the L1 Hegotá meta-EIP.

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