Frame Transactions and the Post-Quantum Transition on Ethereum

Introduction

Ethereum's transaction format hardcodes ECDSA over secp256k1, which Shor's algorithm breaks on a large enough quantum computer. Replacing it without forcing every address to migrate requires accounts that define their own validation logic, so post-quantum security on EVM chains runs through account abstraction.

ERC-4337, the design in use today, makes it possible to deploy a smart account that can verify a SPHINCS+ signature in validateUserOp, but its UserOperation reaches the chain inside an ordinary transaction that a bundler sends from an EOA, signed with secp256k1. A quantum attacker who recovers a bundler's key, exposed by its first signed transaction, cannot touch user funds, since every UserOperation still passes the account's post-quantum check. The attacker can, however, drain the bundler's gas funds, replace its bundles using its pending nonces, and delay or drop the operations it carries. Every bundler sends from an ECDSA account, including one a user runs alone, so the attack can be repeated on all of them: funds stay safe, but accounts can no longer transact.

EIP-8141 (opens in a new tab) (frame transactions) remove the need for ECDSA completely. A frame transaction has no transaction-level signature, instead, it's validated by the account's own VERIFY frame, the node calls that code directly without an EntryPoint or bundler, and anyone can relay the transaction without holding a key. An account that verifies a post-quantum signature and pays its own fees is therefore post-quantum for both its funds and its ability to transact.

This article describes frame transactions as specified in October 2026 and what their rules mean for accounts that verify post-quantum signatures. EIP-8141 has been Scheduled for Inclusion in the Hegotá upgrade since August 27, 2026, alongside FOCIL, according to the Hegotá meta EIP (opens in a new tab). The specification is still open, and its format, gas model and mempool rules may change again before inclusion.

Frame transaction structure

EIP-8141 defines a new EIP-2718 transaction type, FRAME_TX_TYPE = 0x06. A frame transaction is an ordered list of frames, each frame is a call with its own mode, flags, target, gas limits, value and calldata, and frames run in order within one transaction context.

Payload

The payload is the RLP serialization of:

[chain_id, nonce, sender, frames, signatures, fees, blob_versioned_hashes]

frames     = [[mode, flags, target, limits, value, data], ...]
limits     = [execution, state]
signatures = [[scheme, signer, msg, signature], ...]
fees       = [max_priority_fee_per_gas, max_fee_per_gas, max_fee_per_blob_gas]

The submitter asserts sender and the envelope does not authenticate it. tx.nonce must equal the sender's nonce in state. Fees follow EIP-1559, and blobs are optional and follow EIP-4844. A transaction can contain at most MAX_FRAMES = 64 frames.

Frame modes

The mode field selects how a frame executes:

• DEFAULT (0): a regular call with ENTRY_POINT (address(0xaa)) as the caller.
• VERIFY (1): a STATICCALL with ENTRY_POINT as the caller, so the frame cannot write state. If a VERIFY frame reverts or halts exceptionally, the whole transaction is invalid.
• SENDER (2): a call with tx.sender as the caller. Execution must already be approved when a SENDER frame is reached, otherwise the transaction is invalid.

Flags and atomic batches

The flags field controls what a frame may approve and how its failure affects other frames. The signature hash covers it, so only the signer sets it:

• Bits 0-1: the approval scope the frame may use (0x0 none, 0x1 payment, 0x2 execution, 0x3 both).
• Bit 2: ATOMIC_BATCH_FLAG (0x4), valid only on DEFAULT and SENDER frames.
• Bits 3 and up: reserved.

APPROVE reverts if the requested scope is not allowed by the frame's flags. A sponsor's pay frame with flags 0x1 can approve payment but never execution, and a frame with 0x0 cannot approve anything. Because the scope is visible in the transaction bytes, nodes can classify frames without executing them: the public mempool's self_verify, only_verify and pay roles are VERIFY frames with flags 0x3, 0x2 and 0x1.

Frames are normally independent: a reverted frame does not stop the next one. The atomic batch flag groups consecutive frames into an all-or-nothing unit, closed by the first frame without the flag. If any frame in the batch fails, state returns to where it was before the batch and the remaining frames are skipped, with receipt status 2:

frame 0  VERIFY  flags 0x3   validates and approves
frame 1  SENDER  flags 0x4   token.approve(dex, amount)
frame 2  SENDER  flags 0x0   dex.swap(...), closes the batch

If the swap fails, the approval is undone with it. VERIFY frames and approval scopes are not allowed inside a batch, so a failed batch can never undo the nonce increment, the fee payment or the execution approval. Batching moves from account code, such as the executeBatch functions of ERC-4337 accounts, into the protocol: accounts get smaller, and EOAs get atomic batches without deploying code.

Signatures

VERIFY frames and ordinary EVM code can reference the entries in the signatures list. Three schemes are defined:

• ARBITRARY (0x0): bytes the protocol does not verify. 100 gas.
• SECP256K1 (0x1): v || r || s, verified by the protocol. 2800 gas.
• P256 (0x2): r || s || qx || qy, verified by the protocol. 6700 gas. The signer address is keccak256(qx || qy)[12:].

The protocol checks every SECP256K1 and P256 entry before running any frame. Each entry signs either an explicit 32-byte digest or, with an empty msg, the canonical transaction hash: the hash of the whole transaction with the bytes of those signatures removed. Schemes the protocol does not verify, which today includes every post-quantum scheme, use an ARBITRARY entry instead, which EVM code reads with SIGDATACOPY.

Because ARBITRARY bytes are left out of the hash, a relayer can change them without changing TXPARAM(0x08). If a verifier accepts two encodings of the same signature, the transaction hash is malleable, so verifiers should accept exactly one.

The APPROVE instruction

APPROVE (0xaa) ends the current call frame like RETURN and records an approval for the transaction. The scope comes from the stack and must be allowed by the frame's flags, and APPROVE reverts if ADDRESS is not the frame's resolved target (a null target resolves to tx.sender). Approving execution, possible only for tx.sender, lets SENDER frames run. Approving payment requires execution to be approved first: it increments the sender's nonce, collects the transaction's maximum cost from the approving account and makes it the payer, which gets unused gas back. If no frame approves payment, the transaction is invalid.

Execution semantics

Frames run in index order. When a frame reverts, its state changes and any approval it set are discarded and the next frame runs, where a legacy transaction would abort entirely. Atomic batches, described above, are the exception. Transient storage is cleared between frames.

The validation prefix is the sequence of frames up to and including the first frame after which payer is set. The frames after it are the execution body. Public mempool rules apply only to the validation prefix.

Introspection

Six instructions, valid only inside frame transactions, expose the transaction to EVM code: TXPARAM (0xb0) for transaction fields, including the canonical signature hash; FRAMEPARAM (0xb3), FRAMEDATALOAD (0xb1) and FRAMEDATACOPY (0xb2) for any frame's parameters and calldata; SIGPARAM (0xb4) and SIGDATACOPY (0xb5) for signature entries. Validation code can therefore read every frame, and a paymaster can base its approval on what the transaction will execute.

Gas accounting

Each frame declares two gas budgets in limits, following EIP-8037: execution gas for computation and data, state gas for new state, and neither can draw on the other. The intrinsic cost is 12,000 plus 475 per frame, plus signature verification gas and calldata. Calldata is subject to the EIP-7976 floor of 64 gas per byte, signature bytes included, so post-quantum signatures, which are in the kilobytes range, set a high minimum cost.

Mempool validity and DoS constraints

Validating a frame transaction means simulating EVM code, and an attacker could make many pending transactions depend on one piece of state, then invalidate them all with a single change. The EIP addresses this with a public mempool policy based on ERC-7562, without staking or reputation. The rules relevant here are:

• Four allowed validation prefixes: [self_verify], [deploy, self_verify], [only_verify, pay] and [deploy, only_verify, pay], where deploy is a DEFAULT frame that creates the account.
• MAX_VERIFY_GAS = 100_000 for signature validation plus the prefix's declared execution budget.
• Storage reads only from tx.sender, and no environment-dependent opcodes such as TIMESTAMP or BALANCE.
• A canonical paymaster, recognized by its exact code, or any other paymaster limited to one pending transaction.
• At most one pending transaction per sender.

Two of these rules matter for post-quantum accounts:

• The 100k gas cap bounds on-chain signature verification.
• The canonical paymaster authorizes payments with a single secp256k1 key through ecrecover, so transactions sponsored through it depend on that key, and a post-quantum paymaster is non-canonical and limited to one pending transaction.

Specifically, the 100k gas cap is extremely tight for current stateless post-quantum signatures: typical SPHINCS+ variants are in the range of 150k-300k gas, SLH-DSA is around 1M gas and Falcon is above 650k gas for onchain verification. This limit needs to be set carefully in order not to prevent legitimate signature schemes from being used on Ethereum, while preventing malicious DoS attempts.

Conclusions

Frame transactions move account validation into the protocol. Without an ECDSA envelope, an account that verifies a post-quantum signature and pays its own fees no longer depends on anyone's ECDSA key to reach the chain, for its funds or for its ability to transact.