EIP-8130 Account Configuration

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)
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-7623, EIP-7702, EIP-7708, EIP-7825, EIP-8037
Latest spechttps://github.com/ethereum/EIPs/blob/master/EIPS/eip-8141.md

Proposal status

EIP-8141 is a Draft and is only Considered for Inclusion in Hegotá. That is not a fork schedule or activation decision.

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 is EIP-8130's most direct competitor for the same design slot: a general native-AA transaction type. EIP-8141 lets account code validate inside constrained frames. EIP-8130 fixes the authenticator interface and canonical identities, though a contract authenticator may still run metered EVM code. The difference is 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 including EIP-8250 (keyed nonces), EIP-8266 (expiring nonces), EIP-8272 (recent roots), and EIP-8288 (PQ/STARK aggregation). EIP-8288 remains open as of August 20. This differs from EIP-8130, whose Keystore, local-epoch, scope, and lock work has landed directly in one evolving file.

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: a VERIFY frame targeting address(0x8141) enforces an 8-byte unix-seconds deadline, since TIMESTAMP itself is on the banned-opcode list within the validation prefix.

PR #11941 (merged July 17) applies the EIP-7623 calldata floor to frame and signature data. 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 (Account Configuration)
Transaction type byte0x060x79 (renumbered from 0x7B; 0x7A payer-signature magic byte, renumbered from 0x7C)
Validation modelArbitrary EVM in VERIFY frames; any account code can approve any payer via APPROVEOnchain authenticator contracts, checked by node against a canonical allowlist; authenticate(hash, data) via STATICCALL, no wallet-code simulation required
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 listAuthenticator identity allowlist; nodes filter on authenticator address, not by executing or bounding arbitrary code
Composability modelSequential frames (up to MAX_FRAMES = 64) with per-frame mode (DEFAULT/VERIFY/SENDER) and per-frame valueTwo-level call phases ([[call,...],[call,...]]); phase-atomic, phase-independent commit, no frame "modes"
Signature schemesARBITRARY, SECP256K1, P256 at the outer envelope level; any scheme addable via account code + APPROVE, no protocol change neededFixed canonical authenticator set (k1, P256, WebAuthn, delegate) extensible via a companion ERC allowlist, not per-account code
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)Codeless EOAs auto-delegate to DEFAULT_ACCOUNT_ADDRESS; inline self-actor secp256k1 resolves in one SLOAD; createAccount/importAccount revoke the implicit EOA owner by default (quantum-safe-by-default posture)
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 (SENDER/POLICY/NONCE/SELF_PAYER/SPONSOR_PAYER) plus POLICY-gated single-target call restriction, stored onchain across transactions
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 (EIP-8250, EIP-8266, EIP-8272, EIP-8288)Direct evolution of one EIP-8130 file, with 43 merged PRs through August 20
PQ storyUnder the proposal, ARBITRARY plus account code can express a PQ verifier; the outer signatures list is a forward-compat hook for aggregation (open EIP-8288)No PQ authenticator currently defined; future direct use depends on canonical-set adoption, whose activation process remains unspecified
Nonce modelStandard nonce field in the envelope2D nonce_key/nonce_sequence via a NONCE_MANAGER_ADDRESS precompile, plus a nonce-free mode (NONCE_KEY_MAX) with replay_id-based dedup in a fixed-capacity consensus ring buffer

Activity ​

EIP-8141 has 61 commits to its canonical file. Twelve commits landed after the July 28 snapshot: #12007 and #12008 added mempool lifecycle and log semantics; #12042 fixed SIGPARAM copy ordering; #12066 tightened validation opcodes; #12121 updated links; #12062 added state gas; #12026 clarified floors and value; #12061 removed transaction-level receipt status; #12109 tightened atomic-batch approval scope; #12113 fixed initial address access; #12167 relaxed part of the banned-opcode list; and #12187 added SIGDATACOPY.

Six direct PRs are open as of August 20: #12041 (canonical paymaster bytecode), #12157 (precompile-targeted frame dispatch), #12160 (state dependency set), #12162 (higher pending limit for validation-stable accounts), draft #12198 (expiry frame mode), and draft #12203 (expiry-verifier nonce clarification). The four long-standing July PRs closed on August 14, and scheme-registry #12011 plus canonical-paymaster #12012 closed earlier without merge. Open sibling work includes EIP-8288 in #11772.

The proposal was added to the Hegotá hard-fork "Considered for Inclusion" list via PR #11537. EIP-2542 moved to Withdrawn status on June 30, citing EIP-8141 as its superseder. ERC-8286 (Modular Accounts for Frame Transactions, ERC PR #1794) remains open as of August 20.

The forum reaches post #167. Post #167 (August 13) flags a payer-griefing risk when an ARBITRARY signature's message is empty: signature bytes are billed but excluded from the canonical signature hash, so a relay could pad them. The post proposes a hard length rule, a committed length, or a transaction-level bound; no reply appears in the current thread snapshot.

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; new validation patterns don't require a companion-ERC allowlist process the way EIP-8130's canonical authenticator set does.
  • 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, already load-bearing for the EIP-8288 PQ/STARK aggregation sibling.
  • Broadest review surface of the proposals covered here: 61 canonical-file commits, a CFI listing, a formal supersession of EIP-2542, and an open ERC building on it (ERC-8286).

Weaknesses ​

  • Mempool complexity is real and structural: nodes must enforce banned-opcode lists, a MAX_VERIFY_GAS cap, and validation-prefix shape-matching, none of which is needed under EIP-8130's identity-allowlist check.
  • 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 achieves its scope, policy, and lock feature set with zero opcode changes.
  • 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 (EIP-8250, EIP-8266, EIP-8272, EIP-8288) means a reader has to track five separate spec documents to understand the full feature set, versus EIP-8130's single evolving file.

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