A Technical Introduction to Ethereum’s Frame Transactions

1. Introduction

EIP-8141 introduces a new EIP-2718 transaction type, FRAME_TX_TYPE (0x06), called Frame Transaction. A frame transaction is an ordered sequence of execution steps, each targeting a contract address, carrying an independent data payload, and operating in a designated mode. The node executes frames sequentially within a single transaction context, while the protocol imposes one validity condition on the sequence as a whole: at least one frame must call the APPROVE opcode with a payment scope before execution terminates. All other behavior, including sender authentication, signature verification, and fee payment logic, is defined by EVM code in the frame bodies.

2. Motivation

Ethereum's transaction format encodes ECDSA verification and ETH-denominated fee payment directly into the protocol, making both the signing scheme and the gas token fixed constants, not parameters. Account abstraction, in various forms since EIP-86, has been an attempt to relax these constraints without introducing a new transaction type. EIP-4337 approximated abstraction by routing UserOperation objects through a singleton EntryPoint contract via an alternative mempool, delegating validation to contract code while keeping the underlying transaction format unchanged. EIP-7702 instead extended EOA flexibility at the protocol margin without resolving the core coupling.

The progression from EOA to smart contract wallet to frame transactions follows a consistent direction towards native account abstraction. While EOAs offer no programmability at the account level, Smart contract wallets, as deployed under ERC-4337, introduce programmable validation but require a bundler network, a separate mempool, and an EntryPoint singleton to mediate between user intent and EVM execution. Frame transactions complete this progression by eliminating the intermediary layer entirely: the account's validation code is called directly by the node as a VERIFY frame, with no wrapper contract, no alt-mempool, and no bundler reputation system. Native account abstraction means the protocol itself understands the structure of authentication and gas payment, rather than deferring that understanding to a contract deployed at a well-known address.

EIP-8141 addresses the constraint at the transaction type level: validation logic is invoked as a VERIFY frame rather than mediated through an EntryPoint. The node processes the frame sequence natively, which eliminates the bundler, the alt-mempool, and the EntryPoint contract from the execution path. The only protocol-level requirement is that some frame calls APPROVE, leaving the signature scheme, the fee token, and the account model all defined by user-deployed code. This minimal protocol surface is what makes frame transactions a general foundation rather than a fixed feature set: ERC-20 gas payment, multisig authorization, passkey-based signing, in-transaction account deployment, and batched operations all emerge from composing frames, without any of these use cases requiring protocol changes of their own.

The timing of the proposal is also relevant to a separate roadmap concern: Ethereum's current transaction signing model is built entirely on ECDSA over secp256k1, which is vulnerable to Shor's algorithm on a sufficiently capable quantum computer. Because frame transactions decouple the signing scheme from the protocol (authentication is user-defined EVM code in a VERIFY frame) they provide a native migration path to post-quantum signature schemes such as Falcon or hash-based constructions. An account can verify a Falcon signature in its VERIFY frame today, at the cost of higher gas for on-chain verification. As dedicated EVM precompiles for post-quantum primitives are introduced, that cost decreases, while the account model does not need to change. Frame transactions are therefore not only compatible with Ethereum's post-quantum roadmap, they are the transaction-layer mechanism through which that transition becomes possible without a forced migration of existing addresses.

3. Frame Transaction Structure

The transaction format is an RLP-encoded tuple: [chain_id, nonce, sender, frames, max_priority_fee_per_gas, max_fee_per_gas, max_fee_per_blob_gas, blob_versioned_hashes], where frames = [[mode, target, gas_limit, data], ...], there is no top-level signature field. The sender field is an address asserted by the transaction submitter; the protocol does not verify it cryptographically at the envelope level. Other transaction functionalities follow already used standards: tx.nonce must equal state[sender].nonce before execution begins, gas pricing follows EIP-1559 and blob commitments are carried via blob_versioned_hashes per EIP-4844. The maximum frame count per transaction is 1000.

Frame Transaction structure. The transaction includes a sequential list of frames, each executed in order with its own individually specified mode and target.

Frame Modes

The lower 8 bits of the mode field select the execution context, while bits 9 and 10 restrict which APPROVE scopes the frame may invoke.

DEFAULT (mode = 0) executes the frame as a standard EVM call where the caller address is ENTRY_POINT, this is the general-purpose mode for contract calls that do not require sender identity.

VERIFY (mode = 1) executes the frame as a STATICCALL, meaning that during the execution of this frame state mutation is disallowed. The frame must invoke APPROVE before returning or the transaction is deemed invalid.

The data field of every VERIFY frame is zeroed out when computing sig_hash, so the signature bytes inside a VERIFY frame sign over the rest of the transaction without signing over themselves. FRAMEDATALOAD and FRAMEDATACOPY return zero when targeting a VERIFY frame, making its data inaccessible to all other frames in the sequence.

SENDER (mode = 2) executes the frame with caller = tx.sender. It is gated on sender_approved = true: if that flag is not set when the frame is reached, the transaction is invalid. This mode is used for calls where the sender's address must appear as msg.sender, such as storage writes protected by an ownership check or dapp interactions.

The APPROVE Opcode

APPROVE (0xaa) exits the current execution context and updates transaction-scoped approval state. It takes offset, length, and scope from the stack and behaves as RETURN with the following additional effects per scope value. If the currently executing account is not frame․target, APPROVE reverts.

APPROVE(0x1) sets sender_approved = true. It is valid only when frame․target == tx.sender and sender_approved is not already set.

APPROVE(0x2) requires sender_approved = true, increments sender.nonce, deducts the full projected gas cost from frame․target, and sets payer_approved = true.

APPROVE(0x3) performs both operations atomically and is valid only when frame․target == tx.sender.

The usable scope values are further constrained by bits 9 and 10 of the frame.mode field. If (frame.mode>>8) & 3 == 0, any scope may be used. If it equals 1, only scope 0x1 is permitted; if it equals 2, only scope 0x2; and if it equals 3, only scope 0x3. Using a non-permitted scope results in an exceptional halt.

After all frames execute, the node checks that payer_approved = true. A transaction where no frame called APPROVE(0x2) or APPROVE(0x3) is invalid regardless of the state changes produced by other frames.

Execution Semantics

Frames are executed in index order. If frame․target is null, the call targets tx.sender. If a frame reverts, its state changes are discarded and execution continues with the next frame. This differs from legacy transaction semantics where a revert aborts the entire transaction. The practical consequence is that a SENDER frame performing a deterministic state write, such as a key rotation, can be safely placed after a DEFAULT frame whose outcome is not guaranteed, as it will execute unconditionally.

TXPARAM exposes transaction and frame metadata to executing code: the current frame index, mode, gas limit, total frame count, and sig_hash are all readable from within the EVM. FRAMEDATALOAD and FRAMEDATACOPY extend the same interface to frame data fields, with the VERIFY frame restriction noted above.

EOA Default Code

When a frame targets an account with no code, the protocol substitutes a default execution. For a VERIFY frame, this default reads the first byte of frame․data as a signature scheme selector, verifies the corresponding ECDSA signature against sig_hash, and calls APPROVE on success. This preserves usability for EOAs without requiring a smart account deployment, and gives existing addresses access to gas sponsorship and batching without migration.

4. Mempool Validity and DoS Constraints

Current transaction validation is constant-time: a node checks nonce, balance, and signature against static fields. Frame transactions instead break this property: a VERIFY frame executes arbitrary EVM code during validation, which means a node admitting frame transactions into the mempool must simulate at least the VERIFY frames to determine whether APPROVE will be called. This simulation is bounded by the frame's gas_limit, but it is not free, and it can be repeated for every re-evaluation triggered by state changes affecting the simulated frame's dependencies.

The attack surface is straightforward: an attacker submits a large volume of frame transactions whose VERIFY frames are valid at simulation time but invalidated by a cheap state change, forcing repeated eviction and re-admission cycles. ERC-4337 addressed an equivalent problem through a restricted opcode set for validation: the UserOperation validation functions were prohibited from reading mutable state outside the sender's own storage, making their validity stable against external state changes. EIP-8141 does not currently encode equivalent restrictions at the protocol level: the EIP delegates this to relay policy, specifying only that nodes should apply stricter admission rules than consensus requires, without defining what those rules are.

The working direction, based on active development by the EIP authors, involves two layered constraints. The first is a structural admission requirement: mempools would require all frame transactions to begin with a VERIFY frame as a baseline condition for acceptance. A transaction whose first frame is DEFAULT or SENDER cannot be safely validated without executing potentially unbounded logic, so it is rejected at the mempool boundary rather than simulated. This gives nodes a cheap pre-filter before any EVM execution is required.

The second constraint is a verification gas cap: chains can define a maximum gas budget for the VERIFY frame or frames collectively, bounding the EVM execution a node must perform per transaction during admission. For mempools that prioritize throughput or operate under tighter resource constraints, a further restriction is available: accepting only transactions that use the EOA default code path, whose validation cost is fixed and known in advance, since it reduces to a single ECDSA verification against sig_hash.

These two constraints together replicate the effective guarantees of ERC-4337's validation opcode restrictions, but through structural rules rather than an opcode blacklist. The tradeoff is that the rules remain outside the EIP draft for now, meaning mempool behavior is implementation-defined until a standard relay ruleset is formally specified. Client teams have conditioned support on this being resolved before the Hegota fork. The structural admission requirement and the verification gas cap represent the current working answer, but neither is yet normative.