Nine days ago, a document appeared in the Ethereum Improvement Proposal repository that most market desks scrolled past. No token. No airdrop. No testnet. Just a design sketch explaining how a recursive STARK mempool could collapse the on-chain cost of verifying a quantum-resistant signature from roughly ten million gas into the tens of thousands. I read it once, then again with a calculator open, because a 99% reduction in verification cost is not a headline about efficiency. It is a statement about who can afford privacy and who cannot.
The percentage is the easy part. The harder number is the one almost nobody is quoting: 100 to 300 kilobytes of STARK proof data landing in every block under this design. That is the actual bill, and it lands on bandwidth, state growth, and node operators — not on the user's gas receipt.
Crypto's memory is short, so let me anchor this properly. Ethereum has verified signatures on the execution path since genesis. Every transfer carries a secp256k1 ECDSA signature, and the EVM checks it before the transfer settles. That design assumed elliptic curve cryptography would remain hard to break. It will not remain hard forever — not against a sufficiently large quantum computer — and in 2024 NIST finalized exactly the kind of replacements the industry needs: ML-DSA and Falcon, lattice-based schemes with security proofs that do not depend on the discrete logarithm problem.
The problem is arithmetic. Falcon signatures are large. ML-DSA signatures are larger. Verifying them inside the EVM, transaction by transaction, multiplies gas costs by orders of magnitude at precisely the moment Ethereum has spent three years trying to make transactions cheap. Moving to quantum-safe signatures without redesigning the path they travel is not a security upgrade. It is a new tax on every user.
That is the context. Now the mechanism.
The proposal does something structurally elegant: it removes signature verification from the execution path entirely. Instead of the EVM checking each signature as it processes a transaction, nodes aggregate transactions in the mempool by dependency, and block builders produce a single recursive STARK proving that every signature in the batch is valid. Recursion is the key — a STARK that verifies other STARKs is what makes the cost sublinear. One proof, many signatures.
Worth placing this against the two architectures people already know. zk-Rollups compress transactions by moving execution off-chain and proving the result; the signature still gets checked, just somewhere else, and the EVM has to be reimplemented inside a proving system, which is why zkEVM work has consumed years and enormous capital. Optimistic Rollups skip proofs entirely and lean on fraud windows, which means finality is measured in days and honest watchers must exist. This proposal does neither. It leaves execution exactly where it is and moves only verification, which is why the EVM-modification-free claim is credible rather than aspirational.
Two design choices deserve attention, because they are where the real engineering risk sits. First, nothing in the EVM changes. No new opcodes. No zkEVM fork. No cost to application developers. The proof system plugs in at the mempool and block-building layer, which means the upgrade path is far shorter than the account abstraction route that would otherwise require every wallet, relayer, and contract to cooperate on new signature formats. Second, it is signature-agnostic by construction. Falcon and ML-DSA integrate because the proof does not care about the algorithm — it cares about the statement "these signatures are valid." That also delivers something the ecosystem has wanted for years without quite naming it: private account abstraction that arrives natively rather than as a bolt-on.
I have spent enough time on the community side of this industry to say plainly that the second point matters more than the first. In 2017 I was translating wallet mechanics for five thousand Discord users who had never read a whitepaper, and the lesson was blunt: cryptography does not reach people until the cost of using it drops below the cost of avoiding it. Quantum safety has always been technically achievable. It has never been affordable.
Here is where the honest accounting begins. The proposal mints no token. ETH keeps its hard cap, and governance continues through the EIP process rather than through a new instrument. The economic transmission is indirect and runs through EIP-1559. Cheaper per-transaction gas reduces the burn per transaction, but lower cost also increases the number of transactions that are economically viable — including, notably, privacy-preserving ones that currently price themselves out of existence. Whether ETH's burn rate rises or falls depends entirely on which effect dominates, and anyone telling you they know the answer today is guessing.
Running my Ethical Impact metric across this proposal, three questions decide whether it deserves the enthusiasm it is starting to attract. Does it lower the barrier to private transactions for ordinary users, or only for institutions that can afford proofs? Is the aggregation layer permissionless, or does it quietly become a licensed role? And what metadata about transaction relationships does the aggregator observe before inclusion?
That third question is the one I keep returning to. Building bridges in a fragmented digital frontier is only worthwhile when we are honest about what travels across them.
Developer sentiment sits in cautious optimism, which is healthier than euphoria. Social heat to fundamental substance is running somewhere past five to one, and that gap is the number I would watch more closely than the gas estimate. There is no testnet, no benchmark repository, no reference implementation — the entire conversation currently rests on one document and the credibility of its author. My confidence in the technical direction is high. My confidence in a timeline is low.
One inference I would flag, with medium confidence: if recursive STARK aggregation becomes a core Ethereum primitive, pressure to standardize the underlying proving instruction set grows considerably, and RISC-V is the obvious candidate. That is a much larger story than a gas reduction. Standardizing the instruction set beneath proof generation decides which proving teams carry a decade-long head start.
Mechanically, aggregating by dependency is harder than it sounds. Transactions interact through nonce ordering, shared state, and — worst of all — through each other's outcomes. Two transactions touching the same liquidity pool are not independent, and a recursive proof over a dependency graph that is still shifting while the block is being built requires the aggregator to freeze a snapshot and defend it. That is a consensus problem wearing a cryptography costume.
There is a compliance dimension worth naming too. Private account abstraction sounds like an AML problem, and in some jurisdictions it will be treated as one. But this design does not create a shielded pool; it removes the signature from the execution path while leaving transaction relationships visible to validators and aggregators. That asymmetry — hidden signatures, visible graph — is the opposite of what privacy advocates want and the opposite of what regulators fear, which may be exactly why it can pass.
Now the part that is not in the announcement threads.
Signature verification has not disappeared. It has moved. Every check removed from the execution path reappears as a trust assumption at the aggregation layer. If two or three operators produce most of the recursive proofs, we will have rebuilt MEV-Boost's builder centralization behind a cryptographic curtain — and cryptographic curtains are excellent at making centralization look like mathematics.
In 2021, I led a forensic review of metadata storage failures in the Bored Ape collection while every other reporter chased floor prices. The mechanism worked. The pinning was fragile. I learned then that the useful question is never "does the mechanism work" but "who holds the pin, and what happens when they let go." The same question applies here, one layer up. The mempool aggregator sees the dependency graph of who pays whom before the block is built. That is a surveillance surface dressed as an optimization, and I have not seen a single thread pricing it.
There is a cost problem too, and it is the one that keeps me skeptical. Recursive STARK proving is not free. Anyone who has watched Layer2 operators publish proving bills knows the pattern: verification gets cheap, generation gets expensive, and the operator eats the difference until gas returns to levels that justify it. In a sideways market, that model bleeds. A design that reduces user cost by relocating expense to operators is a subsidy, not an efficiency — until someone publishes the aggregate proving bill.
The 100 to 300 kilobytes per block deserve the same scrutiny. That is permanent block space consumed by proof data rather than transactions. Node operators already run on thin margins; asking them to absorb proof bandwidth in exchange for cheaper signatures is a trade they have not been consulted on.
None of this makes the proposal wrong. It makes the proposal unfinished. The ethical pulse of the decentralized economy is measured at the points where convenience meets concentration.
Three signals will tell us whether this becomes infrastructure or narrative. First, whether the proposal receives an EIP number and a slot in the post-Hegota roadmap — the upgrade naming around a possible I-star release remains community shorthand, not a schedule. Second, whether a testnet implementation publishes real proving costs rather than estimates. Third, and most important, whether aggregator diversity emerges before mainnet rather than after.
If the only affordable route to quantum safety runs through a handful of proving operators, have we made Ethereum safer, or merely smaller?
