The case for scheme-agile native transactions as the cheapest, simplest path to quantum-resistant Ethereum in Hegota
The Problem
Ethereum’s transaction authentication relies on ECDSA over secp256k1. Shor’s algorithm breaks it. The community broadly agrees that lattice-based signatures, specifically Falcon (FN-DSA) and Dilithium (ML-DSA), are the most viable replacements. The debate has shifted from which algorithm to which transaction architecture delivers it.
SchemedTransactions (EIP-XXX): A new EIP-2718 transaction type (0x05) that replaces the legacy v, r, s signature fields with a scheme_id byte and a signature_data blob. Three schemes are defined at launch: secp256k1 (ECDSA), P256 (passkeys/WebAuthn), and Falcon-512 (post-quantum). The sender address is derived deterministically from the public key, exactly as it is today. No smart wallets, no account abstraction machinery.
This article argues that SchemedTransactions produce better gas economics than any path currently on the table, including Frame Transactions, while avoiding unnecessary protocol complexity and shipping post-quantum security independently of the account abstraction debate.
The Gas Numbers
The following benchmarks assume post-Glamsterdam gas repricing (reduced base cost for native ETH transfers). All figures are for a simple ETH transfer to a different address. The numbers are taken from pre-existing implementations of both the SchemedTransaction and Frame Transaction / precompile specifications in the Erigon client.
Estimation methodology
Gas costs are estimated using the SchemedTransaction intrinsic gas formula:
intrinsic_gas = base_cost + scheme_gas_surcharge
For a simple ETH transfer with no calldata and no access list, the cost reduces to the base intrinsic cost plus a flat surcharge that covers the extra signature/public key size and verification cost. The base cost is ~4,500 gas in the best case (post-Glamsterdam repricing) or ~21,000 gas in the average case today (current intrinsic cost).
For the smart wallet paths (EIP-8141 / ERC-4337), gas is estimated as:
gas = base_cost + (signature_size + public_key_size) × 16 + precompile_cost + smart_wallet_overhead
The × 16 factor is Ethereum’s per-byte calldata cost for non-zero bytes. NIST post-quantum schemes do not support public key recovery from the signature (unlike ECDSA’s ecrecover), so both the full signature and the full public key must be included in every transaction. The precompile costs are 3,000 gas for Falcon (EIP-8052) and 4,500 gas for Dilithium (EIP-8051). Smart wallet overhead covers contract dispatch, storage reads, and EVM execution context (~30,000 to ~48,000 gas).
Relevant sizes: Falcon-512 produces a ~666-byte signature with an 897-byte public key (1,563 bytes total). Dilithium-2 (ML-DSA-65) produces a ~2,420-byte signature with a 1,312-byte public key (3,732 bytes total).
SchemedTransaction surcharges
The SchemedTransaction EIP defines flat gas surcharges per scheme, calibrated to the extra bandwidth, propagation, and verification costs each algorithm imposes:
| Scheme | Surcharge | Rationale |
|---|---|---|
secp256k1 (0x00) |
0 | Same as today, no additional cost |
P256 (0x01) |
0 | Verification cost comparable to secp256k1 |
Falcon-512 (0x02) |
25,000 | ~24x larger signatures than ECDSA; covers size + verification |
Falcon (FN-DSA-512)
| Path | Best case in Glamsterdam (gas) | Avg case today (gas) |
|---|---|---|
| Direct Precompile + Smart Wallet | ~63,000 | ~82,880 |
| NTT Precompile + Smart Wallet | ~63,600 | ~83,580 |
| SchemedTransaction (native) | ~29,500 | ~46,000 |
Dilithium (ML-DSA-65)
| Path | Best case in Glamsterdam (gas) | Avg case today (gas) |
|---|---|---|
| Direct Precompile + Smart Wallet | ~111,500 | ~133,000 |
| NTT Precompile + Smart Wallet | ~223,900 | ~243,900 |
| Hypothetical SchemedTransaction (native) | ~69,000 | ~85,000 |
Note: The current SchemedTransaction EIP only defines Falcon-512 as the post-quantum scheme. Dilithium figures are hypothetical, assuming a proportional surcharge (~63,000 gas) were a Dilithium scheme_id added via a future EIP. The choice of Falcon over Dilithium is deliberate: Falcon’s combined signature + public key size (1,563 bytes) is less than half of Dilithium’s (3,732 bytes), making it the most practical choice for on-chain transactions where every byte costs gas.
What the numbers tell us
Falcon + SchemedTransaction is the clear winner. At ~29,500 gas in the Glamsterdam best case, a Falcon-authenticated native SchemedTransaction is roughly 1.4x the cost of today’s ECDSA EOA transfer (~21,000 gas). No other post-quantum path comes close to this ratio.
The NTT precompile backfires for Dilithium. The generic NTT precompile (EIP-7885) was designed for crypto-agility: one building block, many schemes. In practice, Dilithium verification needs substantially more NTT rounds than Falcon, and the EVM’s memory model turns this into a cost explosion. Dilithium via NTT (~223k to ~244k) costs roughly double what a direct Dilithium precompile achieves (~111k to ~133k). The generalization penalty is real, and it shows up in memory operations.
The NTT “shared building block” premise breaks down further on inspection. EIP-7885 promises that a single NTT precompile can serve as a common foundation for all lattice-based schemes. In reality, every scheme brings its own non-NTT operations that are equally critical to verification and equally expensive without dedicated precompile support. Falcon requires HashToPoint (hashing a message into a polynomial), which Dilithium does not use. Dilithium requires matrix expansion (expanding a seed into a full matrix of polynomials), which Falcon does not use. Hawk, a newer lattice-based scheme, requires fixed-point arithmetic operations that neither Falcon nor Dilithium needs. Each of these operations ends up demanding its own precompile to be gas-viable, so the NTT precompile does not actually consolidate precompile surface area. It just becomes one more precompile in a growing collection of scheme-specific ones. The crypto-agility argument for NTT as a shared primitive collapses: you still need per-scheme precompiles for everything that is not an NTT, and the NTT itself is the part that is cheapest to begin with.
The smart wallet tax is steep. Every path that routes through a smart wallet (ERC-4337 or EIP-8141 frame validation) pays an additional ~30,000 to ~48,000 gas in overhead for contract dispatch, storage reads, and EVM execution context. SchemedTransactions eliminate this entirely by treating PQ signature verification as a first-class protocol operation. The client verifies the Falcon signature at the transaction envelope level, exactly as it verifies ECDSA today.
Why the EVM Memory Model Is the Real Bottleneck
The critical bottleneck for on-chain PQ verification is not the NTT arithmetic itself. It is memory operations in the EVM.
The gas pricing model makes it worse. EVM gas costs do not always correlate with actual computational cost. A Keccak-256 hash costs 36 gas. A MULMOD on 256-bit integers costs 8 gas. Five multiplications are more expensive than a single hash, even though hash functions are typically more computationally intensive. Lattice-based schemes, which are arithmetic-heavy over small fields (not the 256-bit fields the EVM was designed around), hit the worst part of this mismatch.
This is why a direct precompile outperforms an NTT building-block precompile. The direct precompile executes the entire verification algorithm at native speed, bypassing EVM memory management entirely. The NTT precompile still requires the EVM to orchestrate the higher-level verification logic, marshalling data in and out of the precompile and managing intermediate state in EVM memory. That orchestration is where the gas cost accumulates.
For Falcon, the difference is negligible (~700 gas) because Falcon’s verification is NTT-light: one forward NTT and one inverse NTT, with the public key NTT precomputable off-chain. For Dilithium, which requires significantly more NTT operations and larger working memory, the overhead doubles the cost.
SchemedTransactions sidestep this problem entirely. Signature verification happens at the protocol level, inside the client, not inside the EVM. There are no EVM memory operations, no precompile calls, no gas metering of individual NTT steps. The client simply runs Falcon verification natively and charges a flat surcharge. This is the same model Ethereum uses for ECDSA today: ecrecover is not a precompile you call from a smart wallet. It is a protocol-level operation embedded in transaction validation.
Why a generic “flexible opcode” doesn’t solve this
One could imagine a flexible SIMD-style opcode (in the spirit of the never-adopted EIP-616) that lets the EVM perform vectorized arithmetic, essentially writing numpy-like operations at the opcode level. But this doesn’t escape the fundamental problem: the EVM gas model charges per operation, and the memory expansion costs remain. A flexible opcode still executes within the EVM’s memory and stack architecture. It might reduce instruction count, but it cannot eliminate the memory management overhead that dominates PQ verification costs. Moving verification outside the EVM, either via precompile or via protocol-level validation as SchemedTransactions do, is the only way to avoid this tax.
Frame Transactions Don’t Unlock New Use Cases Beyond EIP-7702
EIP-8141’s stated motivation is twofold: post-quantum readiness and full account abstraction. The post-quantum argument is that Frame Transactions allow accounts to define arbitrary validation logic, so any future signature scheme can be adopted without a hard fork.
But this conflates two separate problems.
For PQ signatures specifically, what you need is a transaction format that can carry a PQ signature and a protocol that verifies it natively. The validation logic itself is not complex. It is “check this Falcon signature against this public key.” The problem is that doing this inside the EVM is overly expensive, and making it viable through Frame Transactions would mean redesigning key aspects of the EVM itself, like memory costs or even how precompile input/output works. That is a much larger undertaking than the Frame Transaction EIP acknowledges. SchemedTransactions avoid this entirely with a single scheme_id byte and no EVM execution during validation.
For account abstraction generally, EIP-7702 already allows EOAs to delegate to contract code, enabling custom validation, batching, and gas sponsorship. The use cases that EIP-8141 proponents cite (passkey authentication, session keys, ERC-20 gas payment) are already achievable through EIP-7702 delegation combined with ERC-4337 infrastructure. SchemedTransactions also handle the passkey/WebAuthn case natively via scheme_id = 0x01 (P256), which is one of the primary motivations cited for Frame Transactions. Frame Transactions provide a cleaner protocol-level primitive for the remaining cases, but they do not enable fundamentally new functionality.
What Frame Transactions do introduce is significant protocol complexity:
-
DoS vectors in the mempool. Arbitrary EVM validation means nodes must trace transactions before knowing if they are safe to propagate. Failed validation after tracing is unpaid computation, which is a denial-of-service vector that requires reputation systems or tracing limits to mitigate. This is the core concern that delayed the ACD decision in March 2026.
-
New opcodes. EIP-8141 introduces APPROVE, TXPARAMLOAD, TXPARAMSIZE, and TXPARAMCOPY. That is new surface area in the EVM that must be implemented consistently across all clients (Geth, Nethermind, Besu, Erigon) or risk consensus failures.
-
Changed semantics. The ORIGIN opcode changes behavior under Frame Transactions, returning the frame’s caller rather than the transaction origin. Contracts that rely on
ORIGIN == CALLER(a discouraged but existing pattern) may break.
The abstraction is an illusion: you always need a precompile
Frame Transactions promise that any signature scheme can be implemented in a VERIFY frame without protocol changes. In theory, this is crypto-agility through abstraction. In practice, every meaningful verification scheme ends up requiring a precompile anyway.
P256 verification for WebAuthn passkeys? That needed a dedicated precompile (RIP-7212) because doing P256 in the EVM was prohibitively expensive. ML-DSA for the next generation of WebAuthn standards? That will need a precompile too (EIP-8051). Falcon? It already has its own precompile proposal (EIP-8052). The pattern is consistent: the EVM is not built for cryptographic verification at gas-competitive costs, so every real scheme that enters production use demands a precompile to make it viable.
This means Frame Transactions do not actually deliver crypto-agility without hard forks. They deliver the ability to call a precompile from a VERIFY frame, but the precompile itself still needs to be deployed through a protocol upgrade, which requires the same community consensus and hard fork process as any other EVM change. The “arbitrary validation logic” that EIP-8141 enables is, for cryptographic verification, just an abstraction layer over precompiles that were going to be needed regardless.
This creates an awkward situation specifically around post-quantum, which is supposed to be Frame Transactions’ flagship use case. To actually verify a Falcon or Dilithium signature inside a frame, you need the corresponding precompile. But if you already have the precompile, you can verify the signature at the protocol level, without frames, without EVM execution, without smart wallet overhead. The frame becomes an unnecessary indirection: it adds gas cost (smart wallet dispatch, frame orchestration) on top of a precompile that could have been called directly by the transaction validation logic. Frame Transactions promise to solve the PQ problem through abstraction, but the abstraction depends on the very precompiles that make the abstraction unnecessary.
The result is a path that costs more and does not fully solve the quantum problem on its own. Frame Transactions allow individual accounts to opt into PQ verification, but they do nothing about the legacy transaction types that remain active on the network. As long as type-0 (legacy) and other ECDSA-signed transactions are accepted by the protocol, Ethereum is not quantum-resistant. It is quantum-optional. Full quantum resistance eventually requires deprecating and forbidding ECDSA-only transaction types at the protocol level, which is itself a hard fork. Frame Transactions do not provide a mechanism for this transition; they assume coexistence indefinitely. A SchemedTransaction path, by contrast, introduces PQ-signed transactions as a first-class transaction type alongside legacy types, making the eventual deprecation of ECDSA types a clean protocol-level decision: stop accepting type-0 transactions after block N. No smart wallet migration, no account-by-account opt-in, just a transaction type sunset, the same mechanism Ethereum has used for every previous transaction format upgrade.
SchemedTransactions avoid all of the complexity listed above. Signature verification is a single, cheap, stateless check at the transaction envelope level, exactly like today’s ECDSA. No EVM execution during validation, no new opcodes, no changed semantics, no mempool tracing. Nodes validate a SchemedTransaction the same way they validate a legacy transaction: decode, verify signature, derive address, check nonce and balance, execute.
The SchemedTransaction Architecture
The SchemedTransaction design is deliberately minimal. It is an EIP-1559 transaction with two changes: the legacy v, r, s fields are replaced by scheme_id (1 byte) and signature_data (variable length).
How it works
-
Scheme selection. The sender chooses a
scheme_id(0x00for secp256k1,0x01for P256,0x02for Falcon-512) and signs the transaction with the corresponding algorithm. -
Signature verification. The client dispatches on
scheme_idand runs the appropriate verification routine. For secp256k1, this is the existingecrecover. For P256, it uses the EIP-7951 precompile logic. For Falcon, it runs native Falcon-512 verification. All of this happens at the protocol level, before EVM execution. -
Address derivation. For secp256k1 (
0x00), the address iskeccak256(pubkey)[12:], identical to legacy Ethereum, preserving full backward compatibility. For all other schemes, the address iskeccak256(scheme_id || pubkey)[12:], providing domain separation so that keys from different algorithms cannot collide on the same address. -
Gas accounting. The intrinsic gas is
base_cost + scheme_surcharge. In Glamsterdam the base cost for a simple ETH transfer drops to ~4,500 gas; today’s average is ~21,000 gas. Falcon’s 25,000 gas surcharge covers the bandwidth and verification cost of its ~1.5 KB signature + public key. secp256k1 and P256 have zero surcharge.
What this gives you
| Transaction Type | Best case in Glamsterdam (gas) |
|---|---|
| SchemedTransaction, Falcon-512 | ~29,500 |
| SchemedTransaction, P256 (passkey) | ~4,500 |
| Falcon + smart wallet (EIP-8141 path) | ~63,000 |
| Dilithium + smart wallet | ~111,500 |
| Dilithium via NTT + smart wallet | ~223,900 |
A Falcon SchemedTransaction costs ~29,500 gas in the Glamsterdam best case. That is roughly 6.5x the base cost of a simple P256 or secp256k1 transfer (~4,500 gas), but the delta is almost entirely the Falcon signature and public key hitting calldata costs. Through the smart wallet / Frame Transaction path, the overhead is ~63,000 to ~224,000 gas, which is 2x to 7.5x more than the SchemedTransaction path for the same cryptographic operation.
Why Falcon-512 and not Dilithium?
The SchemedTransaction EIP chooses Falcon-512 (NIST FIPS 206) as its post-quantum scheme because it has the smallest combined signature + public key size among NIST-standardized lattice-based schemes at the 128-bit security level. At 1,563 bytes total, Falcon is less than half the size of Dilithium-2’s 3,732 bytes. On a blockchain where every byte has a gas cost, this is decisive. Additional schemes, including Dilithium, can be added via future EIPs by registering new scheme_id values.
Ethereum Can Have Both, But SchemedTransactions Are More Useful Right Now
This is not an argument against Frame Transactions ever existing. Ethereum can adopt both. Nothing prevents Frame Transactions from being built on top of SchemedTransactions later, inheriting their native PQ verification and gas efficiency while adding programmable validation for the use cases that genuinely require it. Vitalik himself has acknowledged that constrained transaction primitives and full account abstraction serve different purposes. The two proposals are not mutually exclusive at the protocol level.
But right now, the Ethereum community faces a concrete, time-sensitive problem: deploying post-quantum transaction authentication before quantum adversaries become practical. The question is not “which architecture is more elegant in the abstract?” It is “which architecture ships PQ security fastest, cheapest, and with the least risk to the network?”
On that question, SchemedTransactions win decisively:
-
Cheaper by a factor of ~2x to ~7x depending on the comparison point.
-
Simpler. No new opcodes, no mempool tracing, no DoS mitigation complexity. The transaction validation model is identical to today’s: decode, verify signature, derive address, execute.
-
Faster to ship. A single new transaction type with a
scheme_iddispatch is a smaller, more auditable change than a full execution-frame overhaul. The ACD decision on EIP-8141 was already delayed in March 2026 because client teams want clearer mempool rules. SchemedTransactions do not have this problem because they introduce no new mempool validation complexity whatsoever. -
Sufficient. PQ signature verification does not require Turing-complete validation logic. It requires the client to call a different verification function based on a 1-byte field.
-
Bonus: native passkey support. SchemedTransactions also solve the P256/WebAuthn use case (
scheme_id = 0x01), which is one of the top cited motivations for Frame Transactions, at zero additional gas cost.
Frame Transactions solve a real problem: generalized account abstraction with full programmability. But that problem is not urgent in the same way PQ security is, and EIP-7702 already covers the practical AA use cases (session keys, batching, gas sponsorship) that users need today. The use cases that only Frame Transactions can enable (arbitrary on-chain validation, exotic multi-party auth flows) are important, but they are not blocking any current adoption.
SchemedTransactions are immediately useful. They provide a clean native path for PQ signatures and passkey wallets, they keep gas costs near-ECDSA levels, and they can ship without waiting for the AA debate to resolve. Once they are live and PQ security is deployed, the community can take its time getting Frame Transactions right, with proper mempool rules, thorough client testing, and no pressure from quantum threat timelines.
The pragmatic sequence is: SchemedTransactions first, Frame Transactions when they are ready. Not the other way around.
Summary
| Criterion | Frame Tx (EIP-8141) | SchemedTransaction |
|---|---|---|
| Best case in Glamsterdam (Falcon ETH transfer) | ~63,000 | ~29,500 |
| Avg case today (Falcon ETH transfer) | ~82,880 | ~46,000 |
| Native passkey (P256) support | Via EVM validation frame | Yes, zero surcharge |
| New opcodes required | Yes (4) | No |
| Mempool DoS complexity | High (tracing needed) | None (stateless sig check) |
| New use cases vs. EIP-7702 | Marginal | N/A (targets PQ + passkeys) |
| Address format change | Smart account migration | None (`hash(scheme_id |
| Protocol complexity | High | Low |
| Ships PQ independently of AA debate | No | Yes |
| Frame Txs buildable on top later? | N/A | Yes |
Gas estimates are derived from pre-existing implementations of both specifications in the Erigon client. SchemedTransaction costs use the EIP’s intrinsic gas formula: base_cost + scheme_surcharge (Falcon surcharge: 25,000 gas). Base cost: ~4,500 gas best case in Glamsterdam / ~21,000 gas avg case today. Smart wallet path estimates use: base_cost + (sig_bytes + pk_bytes) x 16 + precompile_cost + wallet_overhead. Falcon-512 sizes: 666-byte signature, 897-byte public key. Dilithium-2 sizes: 2,420-byte signature, 1,312-byte public key. Precompile costs per EIP-8052 (Falcon: 3,000 gas) and EIP-8051 (Dilithium: 4,500 gas). Public key recovery is not available in NIST PQ specifications, so the full public key must be transmitted with every transaction.