EIP-8130 Keystore Accounts

Appearance

EIP-8141: Frame Transaction ​

AuthorFelix Lange (@fjl), Vitalik Buterin, lightclient (Matt), Yoav Weiss, Alex Forshtat, Dror Tirosh, Shahaf Nacson, Derek Chiang (@derekchiang), Toni Wahrstätter (@nerolation), Stavros Vlachakis (@svlachakis)
Status/CategoryDraft, Core (Standards Track)
CreatedJanuary 29, 2026 (submitted as PR #11202)
RequiresEIP-1559, EIP-2718, EIP-2780, EIP-3529, EIP-3607, EIP-4844, EIP-7594, EIP-7702, EIP-7708, EIP-7778, EIP-7825, EIP-7976, EIP-8037
Latest spechttps://github.com/ethereum/EIPs/blob/master/EIPS/eip-8141.md

Proposal status

EIP-8141 is a Draft that is Scheduled for Inclusion in Hegotá as of PR #12251 (Aug 27), "with the understanding that AA will ship in Hegotá and the specific implementation may change, including EIP number." The AA breakout series targets a final decision by Devcon (November 3). SFI is not activation.

At a Glance ​

What it is. A new EIP-2718 transaction type (0x06) built around "frames": a sequence of up to 64 purpose-labeled sub-calls (DEFAULT, VERIFY, SENDER modes) that let any account code run arbitrary EVM logic to validate a signature, approve a payer, and execute a batch, all inside one transaction.

Problem it solves. It targets the same territory as ERC-4337 and EIP-7702, native programmable validation and gas sponsorship, plus a post-quantum off-ramp, by letting account code decide for itself how to authenticate a transaction rather than pinning authentication to a fixed set of protocol-recognized schemes.

Why an EIP-8130 reader should care. EIP-8141 was EIP-8130's most direct competitor for the same design slot, a general native-AA transaction type, and it is the one now scheduled for L1. Since EIP-8130 became a transport-neutral Keystore in October, the relationship is partly complementary: the Keystore names EIP-8141 frame accounts as consumers, and the direct transaction-format competitor is EIP-8430. The underlying difference remains programmable validation shape versus a standardized authentication boundary, not EVM versus no EVM.

Overview ​

EIP-8141's transaction envelope is [chain_id, nonce, sender, frames, signatures, max_priority_fee_per_gas, max_fee_per_gas, max_fee_per_blob_gas, blob_versioned_hashes]. The frames field is an ordered list of [mode, flags, target, limits, value, data] entries. limits now carries separate execution- and state-gas budgets. A transaction can carry validation, payment approval, and execution frames as first-class sub-calls.

This puts EIP-8141 at the "more general" end of the native-AA design space: it does not define a fixed authentication interface at all. Instead it gives account code a primitive, the APPROVE opcode, that any contract can call to tell the protocol "this frame's target is authorized to pay and/or execute." What counts as valid authentication is therefore whatever logic the account happens to run, not a value chosen from a canonical registry.

Core Design ​

Frame modes. Three modes govern how a frame's sub-call is dispatched:

  • DEFAULT (0): called from ENTRY_POINT, used for general execution and post-op logic (e.g. sponsor refunds).
  • VERIFY (1): STATICCALL semantics; a frame that carries approval authority must call APPROVE to succeed.
  • SENDER (2): called from tx.sender, requires an approval already granted (sender_approved) by a prior VERIFY frame.

APPROVE (0xaa). The central opcode. It terminates the calling frame successfully and sets transaction-scoped approval flags: 0x1 payment, 0x2 execution, 0x3 both. Only the frame's resolved target may call it, and double-approval within a transaction is blocked. This is the mechanism by which arbitrary account code becomes a validator: there is no fixed authenticator interface, just a frame that either calls APPROVE or doesn't.

Seven new opcodes. APPROVE (0xaa), TXPARAM (0xb0), FRAMEDATALOAD (0xb1), FRAMEDATACOPY (0xb2), FRAMEPARAM (0xb3), SIGPARAM (0xb4), and SIGDATACOPY (0xb5). PR #12187 added SIGDATACOPY so raw signature-byte copying has static stack requirements. This remains the largest new EVM surface among the proposals compared here.

Outer signatures list. A dedicated signatures = [[scheme, signer, msg, signature], ...] field, separate from the frame execution model, with three protocol-recognized schemes: ARBITRARY (0x0) (no protocol crypto check; raw bytes introspectable via SIGPARAM, used for custom or PQ verifiers), SECP256K1 (0x1), and P256 (0x2). The outer list was added by PR #11481 (merged May 22) as a forward-compat hook for PQ signature aggregation; the ARBITRARY scheme and SIGPARAM came later in PR #11837 (July 6). PR #11937 (July 17) fixed secp256k1 recovery IDs to 0/1 and required low-s signatures; PR #11984 (July 21) applied the same canonical low-s rule to P256. Every ARBITRARY entry now carries a flat 100-gas verification charge via PR #11976 (July 20), in addition to data cost.

EOA default code. Codeless accounts get built-in behavior without deployment: a VERIFY frame uses signature index 0 when its allowed scope includes execution, or index 1 for payment-only approval, then calls APPROVE; SENDER and DEFAULT frames complete value transfers instead of reverting. PR #11954 (merged July 17) restored the payment-only index so a codeless EOA can sponsor another sender. P256 was removed from default code by PR #11621 (May 11). It remains a valid outer signature scheme, but accounts wanting passkey-style default-code authorization must deploy code. EIP-3607 (which normally forbids contract-code senders) is explicitly carved out for frame transactions via PR #11272 (merged May 5), since SENDER frames intentionally originate from contract accounts.

Constants. MAX_FRAMES was reduced from 10^3 in the original submission to 64 via PR #11521 (merged April 14), a significant tightening of the transaction's worst-case shape mid-review. The merged draft still has no explicit signatures-list cap. PR #11935 proposed MAX_SIGNATURES = 64 but closed in favor of the per-entry gas charge in PR #11976.

Optional blobs. PR #11985 (merged July 23) completed the previously partial blob fields: blob-carrying frame transactions now follow EIP-4844 fee and block limits and use the EIP-7594 pooled wrapper, with the resolved payer covering blob fees. Unlike EIP-4844 transactions, frame transactions may carry zero blobs.

Compose-by-requires sibling EIPs. EIP-8141 extends via sibling proposals: EIP-7906 (transaction assertions, ASSERT frame mode), EIP-8046, EIP-8209 (commit-reveal frames), EIP-8250 (keyed nonces), EIP-8266 (expiring nonces), EIP-8272 (recent roots), EIP-8288 (in-mempool signature and proof aggregation, merged September 9 via PR #11772), EIP-8369, and EIP-8397 (Frame Authenticator Signatures, merged October 14). EIP-7906, EIP-8250, and EIP-8272 became Considered for Inclusion on September 24. EIP-8130 has since adopted the same pattern, with EIP-8430 and four extension drafts.

EIP-8397: Frame Authenticator Signatures. Merged via PR #12244 (leekt), it adds an AUTHENTICATOR signature scheme: authenticator.authenticate(digest, proof) returns a key_id that must equal the one the transaction claims. It runs in an enforced pure context at a fixed 52,600 gas, with no registry or allowlist, and leaves account authorization to the VERIFY frame. Its interface is essentially EIP-8130's IAuthenticator; the difference is enforced statelessness in place of a canonical set, and no enshrined Keystore. Its own text notes that two such signatures (sender plus sponsor) exceed the 100,000-gas public-mempool cap. Neither the EIP nor its forum post mentions EIP-8130.

Mempool Strategy ​

EIP-8141 explicitly separates execution generality from mempool relayability into two tiers:

  • Execution model (fully general): any account code can verify any signature scheme and approve any payer with arbitrary logic. This is not restricted at the protocol level; a frame transaction that doesn't fit any recognized shape is still consensus-valid.
  • Mempool model (restrictive tier): public relay requires one of four validation-prefix shapes: [self_verify], [deploy]→[self_verify], [only_verify]→[pay], or [deploy]→[only_verify]→[pay]. Validation plus signature verification is capped at 100,000 gas; trace rules restrict opcodes, writes, and mutable-state dependencies. Canonical paymasters receive a code-match exception and balance reservation; non-canonical paymasters are allowed only under a one-pending-transaction cap per paymaster.

A transaction that misses those shapes can remain consensus-valid while failing this public-relay policy. An expansive ERC-7562-style tier is discussed for other cases. This distinction is about validation shape, not canonical versus non-canonical paymasters: the current restrictive policy explicitly admits a tightly rate-limited non-canonical paymaster.

PR #12001 (merged July 23) lets nodes directly evaluate a prefix made only from protocol-defined default code, the expiry verifier, or the canonical paymaster. That fast path uses the same MAX_VERIFY_GAS accounting and admission dependencies as simulation, so common EOA and canonical-paymaster transactions need signature checks and a few state reads rather than EVM tracing. Custom validation and deploy frames still use the generic trace rules.

The EXPIRY_VERIFIER frame (PR #11662, merged May 14) is the only sanctioned path for reading TIMESTAMP-derived expiry, since TIMESTAMP is banned in the validation prefix. PR #12387 (Oct 6) moved it from address(0x8141) to an ordinarily deployed contract at 0x81413f0cF12e9b6a49B1D0439E081c577D57FfFf, reasoning that it is "not special in any way beyond the public mempool recognizing it."

PR #11941 (merged July 17) applied a calldata floor to frame and signature data; PRs #12209 and #12395 (August 21, September 29) moved it from EIP-7623 to EIP-7976's uniform token count. PR #11940 (July 21) then specified one transaction-level EIP-3529 refund counter, while PR #11969 (July 28) reconciled unused per-frame gas, the refund cap, the calldata floor, payer escrow, blob charges, and final settlement. Frame receipts report gross per-frame gas and therefore do not generally sum to transaction-level gas_used. PRs #11955 and #11987 also exclude VERIFY frames from atomic batches, removing ambiguous rollback of payment approval and nonce effects.

PR #12062 (merged August 13) added state gas as a second resource dimension. Each frame now carries execution and state limits; receipts and payer settlement account for both. PRs #12007 and #12008 added replacement, eviction, aggregate payer exposure, and log semantics. Later August merges tightened the validation opcode list, atomic-batch approval scope, and initial accessed-address set.

Key Differences from EIP-8130 ​

AspectEIP-8141 (Frame Transaction)EIP-8130 (Keystore) with EIP-8430
ScopeOne transaction type plus sibling EIPsA transport-neutral Keystore; the 0x79 transaction type moved to open EIP-8430
Transaction type byte0x060x79 in EIP-8430 (renumbered from 0x7B; 0x7A payer-signature magic byte)
Validation modelArbitrary EVM in VERIFY frames; any account code can approve any payer via APPROVE. EIP-8397 adds fixed-gas pure authenticatorsauthenticate(hash, data) authenticators: canonical set everywhere, gas-capped contracts on permissive chains; no account-code simulation
New opcodes7 (APPROVE, TXPARAM, FRAMEDATALOAD, FRAMEDATACOPY, FRAMEPARAM, SIGPARAM, SIGDATACOPY)0 (no EVM changes; two precompiles handle nonce state and transaction context)
Mempool safety mechanismTwo-tier: fully general execution, but public relay requires matching one of 4 validation-prefix shapes, MAX_VERIFY_GAS (100,000) cap, banned-opcode listAcceptance policy by authenticator identity, with MAX_AUTHENTICATION_GAS bounding non-canonical authenticators
Composability modelSequential frames (up to MAX_FRAMES = 64) with per-frame mode (DEFAULT/VERIFY/SENDER) and per-frame valueEIP-8430 call phases of [to, value, data]; phase-atomic, phase-independent commit, no frame "modes"
Signature schemesARBITRARY, SECP256K1, P256, and EIP-8397's AUTHENTICATOR; any scheme addable via account code + APPROVECanonical set (k1, P256, WebAuthn, delegate), changed on L1 only by hard fork; other authenticators per chain policy
Default/EOA behaviorCodeless accounts get built-in VERIFY (secp256k1 against tx.signatures[0]) and value-transfer completion in SENDER/DEFAULT frames; P256 default code removed (PR #11621)EOAs use EIP-8430 with their own key and are never auto-delegated; the inline self-actor is an implicit admin; createAccount/importAccount revoke it by default
Gas sponsorshipDEFAULT post-op frame refunds sponsor; approval scope bit 0x1 marks payment authorizationDedicated payer/payer_auth fields with domain-separated signature hash (AA_TX_TYPE vs AA_PAYER_TYPE); SELF_PAYER/SPONSOR_PAYER scope bits gate who may act as payer
Session/scoped keysApproval scope bits (payment/execution) set through APPROVE; execution approval is one transaction-global flag authorizing every later SENDER frame, so validation must bind the full frame listPersistent per-actor scope bitmask (OPERATOR/SELF_PAYER/SPONSOR_PAYER/POLICY/NONCE) plus POLICY-gated single-target restriction; draft PR #12462 would cut it to two bits
Account lock / rate-limit signalNot part of the base specKeystore Lock and Unlock signed changes let nodes grant higher limits to accounts with a frozen actor set
Feature growth mechanismCompose-by-requires sibling EIPs (nine as of October 21)49 merged PRs to one file, now plus EIP-8430 and four extension drafts
PQ storyARBITRARY plus account code, or an EIP-8397 authenticator, can express a PQ verifier; merged EIP-8288 specifies in-mempool aggregationNo PQ authenticator defined; on L1 canonical adoption takes a hard fork, while permissive chains can accept a capped contract authenticator
Nonce modelStandard nonce field; keyed nonces via sibling EIP-8250EIP-8430 2D nonces (nonce_key 0 is the account nonce) plus nonce-free replay_id mode; a forum post proposed sharing EIP-8250's nonce manager

Activity ​

EIP-8141 has 74 commits to its canonical file, 13 since the August 20 snapshot, none over 100 lines. The notable ones are #12226 (EIP-7778 refund accounting), #12209 and #12395 (calldata floor moved to EIP-7976), #12387 (expiry verifier as a deployed contract), #12453 (frame-mode set membership so siblings can add modes), and #12458 (approval context rolls back with an enclosing revert). Thirteen direct PRs are open, including canonical paymaster bytecode (#12041), a max_fee bound adapted from EIP-7999 (draft #12414), and a fix committing elided signature lengths into the signature hash (draft #12502).

The proposal moved from Considered to Scheduled for Inclusion in Hegotá via PR #12251 (Aug 27) after ACDE #244. The forum's meeting summary of Frame Transaction breakout #2 (Aug 25), which debated EIP-8130 directly, records an outcome that L1 should not enshrine opinionated account models and a next step of a companion keystore EIP. A later breakout (Sep 22) heard an ETH Labs presentation of an EIP-8130 implementation on top of frames; no public artifact was found. EIP-2542 moved to Withdrawn on June 30, citing EIP-8141 as its superseder. ERC-8286 (Modular Accounts for Frame Transactions, ERC PR #1794) merged July 28, and ERC-7902 was rewritten onto frame transactions (ERC PR #2091, merged Oct 20).

The forum reaches post #178. Posts #168-170 (Aug 24) answered post #167's payer-griefing concern by committing to signature length, which became draft PR #12502. Post #178 (karlb, Oct 20) notes that the ERC-20 sponsorship example lets a user execute for free if the fee transfer fails.

Key participants beyond the author list include Giulio2002 and ch4r10t33r, who sparred over PQ verification gas-cost comparisons in the cross-proposal thread https://ethereum-magicians.org/t/frame-transactions-vs-schemedtransactions-for-post-quantum-ethereum/28056 (Giulio2002's ~63,000 gas VERIFY-frame estimate versus ch4r10t33r's objection that it conflates ERC-4337 EntryPoint overhead with frame overhead).

Strengths ​

  • Maximum validation flexibility: if activated, account code could express custom authorization, including a PQ verifier using ARBITRARY, without registering a new protocol signature scheme.
  • No fixed authenticator registry to govern or extend; EIP-8397's permissionless pure authenticators reach the protocol-validated path without the canonical-set process EIP-8130 uses.
  • Frame modes cleanly separate validation, payment approval, and execution as distinct sub-call purposes, which maps naturally onto existing ERC-4337-style wallet architectures during migration.
  • The outer signatures list is a deliberately built forward-compat hook, now load-bearing for merged EIP-8288 aggregation and EIP-8397 authenticators.
  • Broadest review surface and the strongest fork signal of the proposals covered here: 74 canonical-file commits, Scheduled for Inclusion in Hegotá, three CFI siblings, a formal supersession of EIP-2542, and merged ERCs building on it.

Weaknesses ​

  • Mempool complexity is real and structural: nodes must enforce banned-opcode lists, a MAX_VERIFY_GAS cap, and validation-prefix shape-matching. Privacy applications argue 100,000 gas is too low, and devnets are testing 300,000 to 500,000.
  • Transactions falling outside the four recognized validation-prefix shapes do not qualify for the restrictive public-mempool policy, which can push them toward another relay tier or private submission.
  • APPROVE_EXECUTION sets one transaction-global flag for every later SENDER frame. Custom validation that does not bind the full frame list can authorize substituted calls, an unchecked-fields risk documented in PR #11939.
  • Seven new opcodes is the largest EVM surface-area addition among the general-purpose competing proposals; EIP-8130 and EIP-8430 add none.
  • A forum dispute compared frame-based Falcon verification with an earlier, pre-merge EIP-8202 draft that still contained Falcon. It remains useful history about dispatch overhead, but is not a comparison with EIP-8202's current two-scheme text.
  • Feature growth via requires-linked sibling EIPs means a reader tracks ten spec documents to understand the full feature set. EIP-8130 now follows the same pattern, so this is no longer a point of contrast.

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