# Frame Transactions and the Post-Quantum Transition on Ethereum - URL: https://research.projecteleven.com/articles/frame-transactions-post-quantum-ethereum - Published: 2026-10-20 - Authors: Alessandro Baiocchi, Matteo Vicari - Categories: Cryptography, Ethereum A technical introduction to EIP-8141 frame transactions as specified in October 2026, why they matter for post-quantum accounts, and what the public mempool rules mean for post-quantum signatures. --- ## 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](https://eips.ethereum.org/EIPS/eip-8141) (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](https://eips.ethereum.org/EIPS/eip-8081). 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: ```text [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`: ```text 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.