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-2718
Latest spechttps://github.com/ethereum/EIPs/blob/master/EIPS/eip-8141.md

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. The two take opposite bets on where validation complexity should live. EIP-8141 keeps validation fully programmable in the EVM (any account, any signature scheme, any logic) and pushes the resulting mempool-safety problem into a two-tier validation-prefix policy with banned opcodes and gas caps. EIP-8130 keeps the EVM out of the sender-authentication path entirely (a canonical authenticator allowlist checked by identity, not simulated) and pushes programmability into per-actor scope bits and policy-gated call targets. Reading EIP-8141 well means understanding the tradeoff EIP-8130 is explicitly declining to make.

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 the core structural idea: an ordered list of [mode, flags, target, gas_limit, value, data] entries, each one a purpose-labeled sub-call rather than a flat batch item. A single transaction can carry a validation frame, a payment-approval frame, and one or more execution frames, all as first-class, independently gas-metered 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.

Six new opcodes. APPROVE (0xaa), TXPARAM (0xb0), FRAMEDATALOAD (0xb1), FRAMEDATACOPY (0xb2), FRAMEPARAM (0xb3), SIGPARAM (0xb4). This is a materially larger EVM surface than any of its competitors, all of which ship with zero new opcodes.

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). This list was added by PR #11481 (merged May 22) explicitly as a forward-compat hook for future PQ signature aggregation.

EOA default code. Codeless accounts get built-in behavior without deployment: VERIFY frames check secp256k1 against tx.signatures[0] and call APPROVE; SENDER and DEFAULT frames complete value transfers instead of reverting. 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.

Compose-by-requires sibling EIPs. Rather than growing the base spec directly, EIP-8141 extends via requires-linked sibling proposals: EIP-8250 (keyed nonces), EIP-8266 (expiring nonces), EIP-8272 (recent roots), and EIP-8288 (PQ signature and STARK aggregation via a new DEP_VERIFY_FRAME_MODE = 3 and a block-header recursive_stark field, authored by vbuterin and Thomas Coratger, still open as of July 15 with proof-security review ongoing). This is a materially different growth model from EIP-8130, which has absorbed every new capability, scope bits, account lock, call policies, canonical authenticator set, directly into its own spec text across more than 40 merged PRs.

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): that programmability is only publicly relayable when it fits one of four recognized validation-prefix shapes: [self_verify], [deploy]→[self_verify], [only_verify]→[pay], [deploy]→[only_verify]→[pay]. Within these shapes, rules apply: validation-prefix gas plus signature-verification cost must be at most 100,000 (MAX_VERIFY_GAS); a list of banned opcodes (ORIGIN, TIMESTAMP, BLOCKHASH, SSTORE outside tx.sender, and others); no storage reads outside tx.sender; no atomic-batch flag inside the validation prefix; a canonical paymaster is verified by runtime-code match.

A transaction that doesn't match one of the four shapes is still valid at the consensus layer, but has to reach a block builder through a private channel rather than the public mempool. This is the specific mechanism critics point to as "high mempool complexity": nodes need banned-opcode enforcement, gas-cap accounting, and prefix-shape recognition just to decide public relayability, none of which EIP-8130's authenticator-identity allowlist requires. An expansive/permissive second mempool tier (ERC-7562-based) is intended to develop in parallel for use cases that exceed the restrictive policy's shapes.

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.

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 opcodes6 (APPROVE, TXPARAM, FRAMEDATALOAD, FRAMEDATACOPY, FRAMEPARAM, SIGPARAM)0 (no EVM changes; a precompile handles 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-resistant-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 per-APPROVE call, transaction-scoped onlyPersistent 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 specDedicated Account Lock mechanism (LOCKED/UNLOCK_INITIATED flags, unlock_delay) lets nodes grant higher mempool rate 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 the single EIP-8130 spec text (40+ merged PRs to date)
PQ storyNo authorization list dependency on ECDSA; ARBITRARY scheme plus account-code verification lets PQ schemes work today without a protocol change; outer signatures list built as a forward-compat hook for aggregation (EIP-8288)Canonical authenticator set extensible via companion ERC for new schemes (e.g. future PQ authenticator); DEFAULT_EOA_REVOKED-by-default posture framed explicitly as quantum-resistant
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 an extensive PR history: roughly 25 or more merged PRs since the January 29, 2026 submission (PR #11202), 5 open PRs as of July 15 (#11482, #11555, #11580, #11681, and #11772/EIP-8288), plus several closed/rejected PRs. Notable merged changes include the MAX_FRAMES reduction to 64 (PR #11521, April 14), the outer signatures list (PR #11481, merged May 22), the EXPIRY_VERIFIER frame (PR #11662, merged May 14), and the EIP-3607 carve-out for SENDER-frame contract senders (PR #11272, merged May 5).

The proposal was formally added to the Hegotá hard-fork "Considered for Inclusion" list via PR #11537 (merged April 30). It also became the first EIP to formally supersede another proposal: EIP-2542 was moved to Withdrawn status on June 30, citing EIP-8141 as its superseder. An application-layer standard has already begun building on it: ERC-8286 (Modular Accounts for Frame Transactions, ERC PR #1794), still open as of July 15.

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: any signature scheme, any authorization logic, any payer arrangement can be expressed in account code today, with no protocol change required to add a new scheme (PQ schemes work now via ARBITRARY plus account code).
  • 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 and adoption surface of any competing proposal covered on this site: 25+ merged PRs, a CFI listing, a formal supersession of EIP-2542, and an ERC already 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 are consensus-valid but not publicly relayable, pushing them toward private-channel submission and away from permissionless inclusion.
  • Six new opcodes is the largest EVM surface-area addition among the general-purpose competing proposals; EIP-8130 achieves its scope/policy/lock feature set with zero opcode changes.
  • Disputed PQ verification gas costs versus EIP-8202 (a "smart wallet tax" of roughly 30,000-48,000 gas for contract dispatch, storage, and EVM context, per Giulio2002's estimate, contested by ch4r10t33r) show the tradeoff of routing PQ verification through general account code rather than a protocol-native scheme.
  • 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.