Fourth article in a series on the post-quantum transition. The first three covered Bitcoin: what breaks in the infrastructure around it, a one-way shelter architecture, and why a protected spend requires a pre-positioned deposit. This one moves to Ethereum, and the through-line holds: post-quantum security is a property of the path, not of the key.
EIP-8288 was merged into the EIP repository on 9 September 2026. It adds a frame type that lets a transaction declare a post-quantum signature or a STARK proof as a dependency, in 96 bytes, instead of carrying the witness through execution. Mempool nodes aggregate those dependencies recursively; the block carries one proof of a few hundred kilobytes covering all of them.
The part that drew most of the attention is the gas arithmetic. The part worth more attention is a design decision underneath it: two routes are specified, leanSPHINCS and leanSTARK, and the second one is generic. An application that wants ML-DSA, or any other scheme, can verify it inside a client-side STARK and declare the result. No new precompile, no hard fork per algorithm.
That reads like the end of cryptographic monoculture. Pick your scheme, prove your verifier ran, the chain checks a compact proof. The question nobody has put plainly is whether two applications that pick differently end up in the same system at all — and if they do, whether the choice costs them the same.
It does not. And the mechanism that makes it unequal has nothing to do with format compatibility.
What does EIP-8288 actually verify?
It verifies that a claimed verification happened, not that an authorization is valid.
A dependency is a triple: a scheme identifier, a hash of the message or of the public inputs, and a hash of the public key or verification key. Ninety-six bytes per declaration. The recursive verifier does not touch a lattice, a hash tree or an elliptic curve. It checks a proof that some program — the verifier for the declared scheme — executed correctly on those inputs.
This distinction is the load-bearing one for everything below. The proof says "a verifier for scheme S accepted message M under key K". It says nothing about whether K is the current owner of the account, whether M is this transaction, or whether the authority covers this contract. Those bindings live in application logic, exactly where they lived before.
A fully correct proof system over a broken application is reachable: a contract that scans the frames for any valid signature and approves, without checking the key against the current owner. Cryptography intact, authorization gone. That is an integration failure mode, not a flaw in the EIP — but it is the reason "the signature is verified" and "the operation is authorized" have to stay separate sentences.
Are two post-quantum schemes interoperable under one aggregate?
At the level of declaration, yes. At the level of the proof system, only if they were produced for the same one.
Compatibility here holds in three places, and they have very different maturity.
The statement format is fixed and shared. Every dependency reduces to the same triple regardless of the scheme behind it. A SPHINCS declaration and an ML-DSA declaration are the same shape of object to the aggregator. This part works by construction.
The proof backend is not fixed. Two proofs built under different proving systems cannot simply be folded into one recursion. Combining them requires running one system's verifier inside the other — possible in principle, expensive in practice, and an additional trust surface. This is not hypothetical instability: the leanVM implementation moved from KoalaBear with Poseidon to binary fields with BLAKE2s. Backend choice is an active engineering question, and interoperability depends on its answer.
Program identity is still open. Even under one backend, the system needs to bind a proof to the specific verifier program it claims to have executed, or a proof of running some other program could be presented instead. AGGREGATED_VK is marked TBD in the specification. Discussion participants reported local progress on binding arbitrary program identity in September; that is a reported experiment, not a closed mechanism.
So the honest summary of interoperability today: the envelope is standard, the machine that reads it is being rebuilt, and the rule that says which program the envelope refers to is unfinished. None of this is a defect of the design — it is what Draft status means. It does matter for anyone planning to rely on scheme diversity as a property of the system.
Why is a lattice verifier expensive inside a hash-based proof?
Because the cost of proving a program depends on how well its arithmetic matches the algebra the proof system is built on, and lattice arithmetic matches a hash-based system badly.
Verifying a lattice signature means high-dimensional polynomial arithmetic: number-theoretic transforms and modular reductions that are non-native to the proving field. Expressed as constraints, the published comparison below puts such circuits on the order of millions of constraints.
A hash-based verifier in a hash-based proof system is a different object entirely. Recent work that deliberately avoids lattice verification inside the circuit reports its own hash-only construction at 2,155 R1CS constraints in a Groth16 backend and 341 active rows with 361 AIR constraint expressions in a Circle STARK backend, and puts in-circuit post-quantum signature verification at roughly 500 to 2,300 times that size.
Roughly three orders of magnitude, for the same job — establishing that someone holds a key — differing only in which mathematics the verifier speaks.
That gap is the whole argument. It is not a statement that lattice schemes are weak, slow or unsuitable. ML-DSA signs faster than SPHINCS+ by a wide margin and produces far smaller signatures, which is exactly why it is standardised and widely deployed. The gap is about one specific operation: proving, inside a hash-based STARK, that a lattice verifier ran correctly.
And the asymmetry reverses when the backend does. In September 2026, a16z published a version of Jolt that moves its cryptography onto lattices, reporting a prover and verifier two to three times faster with proofs under 100 KB. On a lattice-based backend, lattice arithmetic is native and hash-heavy verification becomes the awkward guest.
Which yields the mechanism plainly: the cost of a scheme inside an aggregation system is a function of its algebraic affinity with the backend. Not of its security level, not of its signature size, not of its standardisation status.
So who actually chooses the signature?
Whoever chooses the backend.
Under the old model, adding a scheme meant adding a precompile, which meant a hard fork, which meant the choice was a protocol governance question with all the friction that implies. Slow, expensive, and — the part that gets forgotten — it produced N independent failure domains. A flaw in one precompile did not reach the others.
Under EIP-8288 the application-level choice becomes genuinely free. Any scheme whose verifier can be expressed as a program is admissible without asking anyone. But every admissible route now runs through one proof system, one hash function, one canonical program identity mechanism and one recursive verifier. The failure domain that used to be partitioned is now shared.
And the economic filter sits on top of that. A scheme that costs millions of constraints to prove is not banned; it is priced out of routine use, while remaining perfectly legal in the specification. Over time the set of schemes that anyone actually deploys converges on those the backend finds cheap.
The result is that cryptographic diversity across Ethereum becomes downstream of an infrastructure decision. The backend gets picked for prover performance, proof size, memory footprint, implementation maturity — reasonable engineering criteria, argued in repositories and benchmarks. Nobody in that conversation is deciding cryptographic policy. But the outcome of that conversation determines which families of post-quantum assumptions applications can afford to rely on.
This is the second-order effect worth naming. Crypto agility as specified moves the decision from governance to the application layer. Crypto agility as it will be experienced moves it to whoever sets the proving stack.
Does wrapping a signature in a STARK make it quantum-safe?
No, and this is where the generic route becomes actively dangerous rather than merely uneven.
The proof establishes that a verifier executed correctly. If the verifier is for ECDSA, and an adversary can produce ECDSA signatures — which is the entire premise of the quantum threat — then that adversary can honestly prove that the verifier accepted a forged authorization. The STARK is not broken. It faithfully attests to the correct execution of a check that no longer means anything.
Compatibility, here, is the hazard. The system will cheerfully accept a mathematically valid proof of the correct verification of a compromised scheme, and nothing in the aggregate distinguishes that from the real thing.
The same reasoning applies to wrapping an older SNARK verifier whose own assumptions are curve-based. Proving that a vulnerable verifier ran correctly does not repair its mathematics. Whatever is being proved inside the proof has to be evaluated on its own terms, and "it's a STARK" says nothing about it.
There is a related trap in the word itself. The foundational STARK paper is titled around post-quantum secure computational integrity, and that title gets treated as a certificate for any implementation carrying the name. It is not. Security parameters, Fiat–Shamir in the quantum random-oracle model, proof of knowledge, recursive composition and the absence of implementation bugs are all separate questions. The theoretical work on Fiat–Shamir in the QROM establishes preservation of specific properties under stated assumptions — it is not a blanket audit of an arbitrary zkVM. Nor is the SNARK-versus-STARK split as clean as usually presented: hash-based SNARK constructions exist, and what matters practically is the commitments, hashes and assumptions actually used.
What breaks if the backend changes?
Two kinds of agility separate here, and only one of them got cheaper.
Application-level agility improved genuinely. An application can change its scheme, its parameters, its verification key, without coordinating with anyone. This is a real gain and the main thing the EIP delivers.
Protocol-level agility did not. Changing the shared proof backend, its parameters, or the aggregated verification key remains consensus-critical. The area governed by shared decisions got smaller, and the importance of what remains inside it went up.
There is a consequence for history that is easy to miss. Once individual witnesses are no longer retained — the aggregate makes them unnecessary for validation — a later change of backend leaves no path to re-prove old aggregates from original data. Current verification stays valid; re-verification under a new scheme does not follow. For anything with custody or audit obligations, that means the retention policy for witnesses is a decision to make deliberately, not a consequence of whatever the node software happens to prune.
What can you check yourself?
Four things, none requiring privileged access.
Read the constraint counts, not the signature sizes. For any scheme you are considering, the question is not how many bytes the signature occupies but how many constraints its verifier requires in the specific proving system you will use. Those two numbers are uncorrelated. A compact signature with expensive verification arithmetic costs more to aggregate than a large signature with cheap arithmetic.
Ask which backend, in writing. Not "does it use STARKs" but which field, which hash, which ISA profile, which version of the verification key. A quote for proving cost is meaningless without them, and — as the leanVM field change shows — the answer has a shelf life.
Check whether program identity is bound. If a proof says a verifier ran, ask what stops a proof of a different program from being accepted in its place. As long as the mechanism is TBD in the spec, the answer for any given deployment is an implementation claim rather than a protocol guarantee.
Separate the four costs. User gas, client-side proving, node aggregation and verification, and time to inclusion are four different quantities. A design that lowers the first can raise the others. When someone reports that a post-quantum transaction costs tens of thousands of gas, ask which of the four that number covers.
The prediction, and how to falsify it
Stating this as a claim rather than a caution, so it can be checked against reality:
If Ethereum's aggregation backend remains hash-based, the share of dependency declarations using lattice-family schemes will stay marginal after activation — not because lattices are disallowed, but because their verification arithmetic is non-native to the proving field.
Method: once the frame type is live, the scheme identifier is part of every dependency and is therefore observable on chain. Count declarations by scheme over a fixed window. If lattice-family schemes hold a small single-digit share while remaining fully permitted, the cost filter is operating. If they reach a substantial share under a hash-based backend, the prediction is wrong and the affinity effect is weaker than the constraint counts suggest.
Two things would legitimately break the prediction, and both are worth watching rather than dismissing. A lattice-based backend becoming canonical reverses the affinity entirely. And a sufficiently efficient wrapper for lattice verification — the constraint gap narrowing by orders of magnitude through better circuit design rather than a backend change — would make the filter economically irrelevant.
I have not found published measurements of lattice verification cost inside the specific backends EIP-8288 contemplates. The constraint figures above come from adjacent work and establish the shape of the gap, not its exact magnitude in this system. If someone has run that benchmark, it is the single most useful number in this discussion, and it would settle the question faster than any argument.
What this means for the series
The Bitcoin articles arrived at a boundary: a protected spend requires a deposit that was positioned for it in advance, and the missing engineering component is rollover rather than cryptography.
Ethereum's answer to the same problem is structurally different and lands on a comparable boundary one layer up. Bitcoin's QSB adapts to consensus as it exists and pays for it with a non-standard path to a miner. EIP-8288 changes consensus and pays for it with a shared proving dependency. In both cases the key is not the hard part. In both cases what determines whether an asset is operationally defended is the availability and economics of the path by which its owner's authority becomes an included transaction.
Which sets up the question I would take next: not whether the signature is strong, but whether the route from a correct signature to a block is something the owner can actually afford and reach when it matters.
Disclosure and scope
This is independent technical commentary reflecting my own views. No entity discussed commissioned, sponsored, paid for, reviewed, or approved it, and I hold no financial interest in the protocols, implementations or organizations mentioned. It is not investment, legal or tax advice.
EIP-8288 and EIP-8141 are Draft at the time of writing; merging into the EIP repository is not activation, and inclusion in any specific upgrade is not decided. Specification parameters cited are design values from the current revision and may change. Constraint counts and performance figures are from the linked third-party sources as published; I have not reproduced them. Where I describe a mechanism as open or unfinished, that reflects the state of the public materials on 12 September 2026, not an assertion that the work is not being done.