We didn't need a hard fork to make post-quantum signatures economically viable on Ethereum. We needed someone to stop treating the EVM like a textbook computer and start treating it like a constrained machine with specific bottlenecks worth attacking. Fireblocks just did that, and the numbers matter more than the headline suggests.
The headline is simple: a fully FIPS 204-compliant ML-DSA-44 signature verifier now runs at 1.23 million gas per verification on today's EVM — a 6.6x reduction from the previous state of the art of 8.09 million gas, set by ZKNox's ETHDILITHIUM project [[51]]. But the details of how they got there tell you more about the state of Ethereum's post-quantum readiness than the 6.6x figure ever will.
Here's what actually happened, what it means for the migration timeline, and why the remaining gap between 1.23 million gas and the roughly 20-30 thousand gas ECDSA verification costs today is still the single biggest obstacle between us and quantum-safe accounts.
The Baseline Problem
Let me set the context properly, because the numbers only make sense if you understand what we were dealing with before.
ML-DSA-44 — formerly CRYSTALS-Dilithium — is NIST's primary recommendation for general-purpose post-quantum digital signatures under FIPS 204 [[52]]. It's a lattice-based scheme, which means its security rests on the hardness of certain lattice problems that quantum computers cannot trivially solve with Shor's algorithm, unlike the elliptic curve discrete logarithm problem that underpins every ECDSA signature on Ethereum today.
Here's the catch: ML-DSA is not designed for the EVM. It's designed for TLS certificates, firmware signing, and government-grade document authentication. The EVM is a 256-bit word machine with no native opcode for Keccak-f[1600] — the permutation at the heart of SHAKE-256, which ML-DSA uses as its core hash function [[32]]. Every SHAKE call has to be run in ordinary opcodes, which is brutally expensive on gas [[17]].
The previous best effort, ZKNox's ETHDILITHIUM, reached 8.09 million gas per verification [[51]]. That's roughly 250-400x more expensive than ECDSA verification. At that cost, post-quantum signatures on Ethereum were a theoretical curiosity. You could write a paper about them. You couldn't build a product.
EIP-7885, a pending proposal to add a dedicated NTT precompile to Ethereum, was projected to bring ETHDILITHIUM's cost down to around 5.73 million gas [[52]]. Even with protocol-level changes, the math didn't work.
Fireblocks achieved 1.23 million gas with zero precompile support — entirely within the existing EVM instruction set [[31]]. That's not just an optimization. That's a statement about where the bottleneck actually lives.
The Optimization Stack
Let me break down what Fireblocks actually did, because the technical details reveal something important about how to approach EVM performance work in general.
SHAKE-256: From 3 Million to 400,000 Gas. The largest single gain came from optimizing SHAKE-256 hashing, which is the core component of ML-DSA's hashing scheme [[31]]. The textbook implementation was burning roughly 3 million gas on hashing alone. Fireblocks cut that to approximately 400,000 [[31]].
This matters for two reasons. First, because the EVM's KECCAK256 opcode cannot compute SHAKE-256 — they're different constructions from the same Keccak family, and the opcode is hardcoded to the specific parameters used by Ethereum's native hashing [[17]]. So every SHAKE call requires manually implementing Keccak-f[1600] in ordinary opcodes, which is like building a car engine out of spare parts every time you need to drive somewhere.
Second, because this optimization is not specific to ML-DSA. Any lattice-based post-quantum scheme that relies on SHAKE-256 — which is most of the NIST-standardized ones — benefits from this work [[31]].
NTT: Stack-Based Layer Processing. The next major win came from the Number Theoretic Transform (NTT), the FFT-equivalent for the polynomial arithmetic that ML-DSA uses. Each verification requires nine 256-point transforms, with eight layers each [[32]].
The textbook approach loads and stores values at every layer. That's a massive amount of memory I/O in the EVM, and every memory expansion costs gas quadratically. Fireblocks changed the approach: load a group of words once, run two or three layers on the stack, and store once [[32]].
The key trick: additions stay unreduced across layers. The values grow, but as long as they stay inside 64 bits, you don't need to reduce modulo the 23-bit prime after every operation. Reduction happens only at multiplies [[32]]. This is a classic batching optimization, but it requires deep understanding of both the math and the EVM's gas model to pull off safely.
The result: one 256-point forward NTT dropped from 182K gas to 45.7K gas [[32]]. That's a 4x improvement on one of the most computationally intensive components of the entire verification process.
Coefficient Packing. All ML-DSA arithmetic operates on 256-coefficient polynomials modulo a 23-bit prime [[32]]. An EVM multiply costs the same whether you use 23 bits of a word or all 256 bits. So Fireblocks packs four coefficients per 256-bit word — one multiply of that word by the same constant produces four products simultaneously, as long as each product stays in its own 64-bit lane and doesn't spill into the next coefficient [[32]].
This is the kind of optimization that seems obvious in retrospect but requires deep familiarity with both the arithmetic structure and the EVM's gas pricing model. It's not glamorous. It's the difference between a demo and a product.
The Meta-Detail: Nine Days and $7,500. Here's the number that should make you pause. Fireblocks achieved this with an AI-driven research team that took nine days and cost roughly $7,500 [[41]].
That's not a typo. Nine days. Seven and a half thousand dollars.
The implication is uncomfortable for anyone who has spent years optimizing EVM code the traditional way: the cost curve for this kind of work has fundamentally shifted. When AI-assisted search can explore the optimization space this quickly, the bottleneck is no longer engineering effort. It's knowing what to look for.
Why This Matters Now: The Threat Timeline Just Moved
The urgency behind this work isn't theoretical. In March 2026, Google Quantum AI published a whitepaper — co-authored with researchers from the Ethereum Foundation and Stanford University — showing that breaking the 256-bit elliptic curve discrete logarithm problem could require fewer than 500,000 physical qubits, a roughly 20-fold reduction from previous estimates [[22]][[28]]. The paper presents two optimized circuits for running Shor's algorithm against secp256k1: one using at most 1,200 logical qubits and 90 million Toffoli gates, another using at most 1,450 logical qubits and 70 million Toffoli gates [[21]][[23]].
Previous estimates from Litinski in 2023 put the requirement at roughly 9 million physical qubits on a photonic architecture [[28]]. The new work compresses that to under 500,000 physical qubits, with attack times measured in minutes on sufficiently advanced systems [[27]].
Does that mean Q-Day is imminent? No. Current quantum processors still operate in the hundreds to low thousands of physical qubits, with error rates far too high for the sustained, fault-tolerant computation the paper describes [[25]]. The path from today's hardware to a cryptographically relevant quantum computer still requires sustained engineering breakthroughs across qubit quality, error correction, thermal management, and scale [[25]].
But here's the structural problem: blockchains are uniquely exposed because they use elliptic curve keys that are almost an order of magnitude smaller than RSA keys at comparable security levels — meaning a smaller quantum computer can crack them [[30]]. And the "harvest now, decrypt later" attack — where adversaries collect encrypted data today to decrypt it once quantum computers mature — is a real concern for data confidentiality, though it's worth noting that this primarily affects encrypted communications, not blockchain signatures, which are verified and discarded [[18]].
The Ethereum Foundation's position has been clear: rather than a single protocol-wide migration, Ethereum plans to use account abstraction — specifically EIP-8141, being considered for the Hegotá upgrade in the second half of 2026 — to give users signature agility [[1]][[2]]. This allows individual accounts to choose their own signature verification, meaning users could switch to quantum-safe signatures without waiting for a single protocol-wide migration [[1]].
This is the "de-enshrining" strategy: remove signature verification from the protocol layer and push it to the application layer, where it can evolve organically. The tradeoff is that application-layer implementations must be efficient enough to be practical. That's precisely where Fireblocks' work comes in.
The Contrarian Angle: What the 6.6x Headline Doesn't Tell You
Here's where I'm going to push back on the celebratory tone of the coverage.
1.23 million gas is still 40-60x more expensive than ECDSA.
Let me repeat that. ECDSA verification on Ethereum costs roughly 20,000 to 30,000 gas. ML-DSA-44 verification, even after this 6.6x optimization, costs 1.23 million gas [[51]]. That's not a rounding error. That's a fundamental cost structure difference.
If every Ethereum transaction switched to ML-DSA-44 signatures tomorrow, the gas costs would be catastrophic. A simple ETH transfer that costs a few dollars today would cost tens of dollars. The block gas limit would constrain throughput severely. The economics simply don't work yet.
The signature size problem is also unresolved. ML-DSA-44 signatures are approximately 2,420 bytes, compared to ECDSA's 65 bytes. That's a 37x increase in per-transaction data size [[16]]. This raises on-chain and archival storage demands, slows network propagation, and accelerates ledger growth [[16]]. The Gas cost problem is only half the equation — bandwidth and storage are the other half.
The research community has explored SPHINCS+-derived schemes that achieve lower verify costs — around 127,000 gas — but those come with significantly larger signatures (3,704 bytes in the C13 variant) and statefulness requirements that make them awkward for general wallet use [[31]]. Hash-based schemes stack WOTS+ one-time signatures, FORS few-time signatures, and a hypertree structure to create a scheme whose security depends solely on hash function assumptions — but the tradeoffs in size and state management are real [[36]].
The verifier reads a 20,545-byte expanded public key. That key is deployed once as contract code, at roughly 4.1 million gas in code deposit [[11]]. That's a per-key setup cost, not a per-verification one, but it matters for deployment economics. For a wallet contract that needs to verify post-quantum signatures, you're looking at 4.1 million gas just to get the key on-chain.
There's no independent audit mentioned. Fireblocks is an institutional-grade security company — they've secured over $10 trillion in digital asset transactions, serve 2,400+ organizations, and hold over $100 billion in daily assets under custody [[40]]. They're not a random DeFi protocol. But the ML-DSA-44 verifier implementation itself hasn't been mentioned as having gone through independent third-party audit in the coverage I've seen. For a piece of code that will eventually secure institutional wallets, that's a gap that needs closing.
The "no precompile" claim cuts both ways. Fireblocks reached 1.23 million gas without any precompile support, working entirely within the existing EVM instruction set [[31]]. That's impressive engineering. But it also means the implementation is fighting the EVM's design constraints rather than working with them. EIP-7885, which would add a dedicated NTT precompile, was projected to bring ETHDILITHIUM's cost down to around 5.73 million gas [[31]]. Fireblocks beat that by 4.6x without the precompile. Imagine what the combination of their optimization techniques and a precompile could achieve.
But here's the uncomfortable question: does Ethereum even want an NTT precompile? The protocol's design philosophy leans toward minimalism, avoiding the addition of native post-quantum signature support [[13]]. Adding precompiles for specific cryptographic schemes enshrines those schemes at the protocol level — exactly what the "de-enshrining" strategy is trying to avoid. The "cryptographic agility" approach means Ethereum should not lock itself into a single post-quantum scheme too early [[9]]. Precompiles are a form of locking in.
What This Actually Means for the Ecosystem
Let me map out the realistic implications.
For Ethereum's migration timeline. The core post-quantum infrastructure milestones target completion by approximately 2029 [[1]]. EIP-8141 is being considered for the Hegotá upgrade, targeted for 2027 [[1]]. The cryptographic transition itself is expected to take years [[9]].
Fireblocks' optimization doesn't change that timeline, but it removes a critical blocker. The path from "theoretically possible" to "economically viable" just got dramatically shorter. When EIP-8141 ships and users can choose their own signature verification, the cost of choosing quantum-safe signatures just dropped by 6.6x. That's the difference between a feature that exists on paper and a feature that people can actually use.
For Fireblocks' institutional play. This is not academic research. Fireblocks is the world's most trusted digital asset infrastructure company, providing custody, payments, tokenization, and treasury management across 150+ blockchains to 2,400+ organizations [[34]]. They're not optimizing ML-DSA verification for fun. They're preparing for the moment when institutional clients ask for quantum-safe wallets.
Their research team is proactively mapping candidate PQC signature schemes — not just the NIST-finalized standards (ML-DSA, SLH-DSA, FN-DSA) but also additional candidates in Round 2 of NIST's Additional Digital Signature Schemes evaluation [[44]]. Some of these, particularly code-based and multivariate constructions, may be more naturally suited to multi-party computation, which is the architecture that underpins Fireblocks' co-signer model [[44]].
This is a signal. When the largest institutional custody platform in the world starts investing in post-quantum signature verification, it's not a research exercise. It's product development.
For Ethereum's competitive position. Solana has native verifier support for post-quantum signatures, which means lower costs in wall-clock time but no gas constraint in the same way. XRP Ledger is preparing for Q-Day [[23]]. Monad has proposed quantum-safe wallet solutions [[30]].
But Ethereum's approach — account abstraction with signature agility — is fundamentally different. It doesn't force a single migration. It creates a market for signature schemes, where users and wallets can choose based on their threat model and cost tolerance. This is the "cryptographic agility" strategy, and it's the right one for a protocol that needs to serve both a $50 wallet and a $500 million institutional custody account on the same chain [[2]].
The problem with agility is that it requires the application layer to do the heavy lifting. And the application layer has historically been terrible at cryptographic optimization on the EVM. Fireblocks just demonstrated that the bottleneck is addressable.
The Path Forward
Here's what I'm tracking over the next 6-12 months.
Will Fireblocks open-source the implementation? The coverage doesn't mention whether this is open source. If it is, the entire ecosystem benefits. If it isn't, we have a walled garden — an optimized implementation locked behind Fireblocks' commercial offerings. From a security perspective, open-sourcing cryptographic implementations is generally better because it enables broader scrutiny. From a business perspective, Fireblocks has every incentive to keep this as a competitive advantage.
Will there be an independent audit? For production deployment, this needs third-party verification. The ML-DSA standard itself has NIST backing, but the specific EVM implementation — with its coefficient packing and stack-based NTT tricks — needs independent validation.
What happens when EIP-8141 ships? The Hegotá upgrade is targeted for 2027, with EIP-8141 being considered for inclusion [[1]]. When it ships, the demand for efficient post-quantum signature verification explodes. Every smart contract wallet that wants to offer quantum-safe signatures will need an implementation that's economically viable. Fireblocks just set the benchmark.
Will the AI-assisted optimization approach become standard? The nine-day, $7,500 figure is the most disruptive number in this entire story [[41]]. If AI-assisted search can compress what would traditionally be months of optimization work into nine days, then the entire EVM optimization landscape changes. Every gas-heavy operation becomes a target. Every cryptographic scheme becomes a candidate for this treatment.
Here's the thing about the migration to post-quantum signatures on Ethereum: it was never a question of if. It was always a question of when the economics would work. The threat timeline from Google's March 2026 paper — under 500,000 physical qubits to break secp256k1 — made the timeline concrete [[22]]. Fireblocks just made the economics tractable.
We didn't need a hard fork. We needed someone to do the unglamorous work of optimizing SHAKE-256 in the EVM and figuring out how to keep NTT values on the stack. That work just got done.
The remaining gap — 1.23 million gas versus 20,000 gas for ECDSA — is still real. But it's no longer disqualifying. For institutional wallets where the security benefit justifies the cost, post-quantum signatures are now viable. For everyday consumer transactions, we need another order of magnitude of improvement.
That next order of magnitude might come from AI-assisted optimization hunting down the next set of inefficiencies. Or it might come from SNARK aggregation schemes that amortize the cost of post-quantum verification across many transactions — the leanVM approach that the Ethereum Foundation has been exploring to restore scalability with larger signatures [[9]].
Either way, the migration clock just started ticking in earnest.
The Takeaway
The question I keep coming back to is not whether Fireblocks' optimization is real — it clearly is, and it's impressive. The question is how quickly the rest of the ecosystem can build on it.
One company just demonstrated that a 6.6x improvement in post-quantum signature verification on Ethereum is achievable in nine days with AI assistance. The cost of cryptographic migration just dropped from "a multi-year protocol overhaul" to "an engineering sprint."
But the distance between 1.23 million gas and ECDSA parity is still vast. And the signature size problem — 2,420 bytes versus 65 bytes — remains untouched. Those two constraints will define the pace of adoption, not the gas optimization.
When the first institutional wallet ships with quantum-safe signatures enabled by default, we'll look back at this moment as the inflection point. Until then, the gap between what's possible and what's practical is still the story.
We didn't solve the migration problem today. We made it solvable. And in a world where Google just cut the quantum threat timeline by 20-fold, that might be enough.