Ethereum Shifts to Quantum-Resistant Hashing: Why Poseidon Is Being Retired
The Cryptonomist reports that Ethereum Foundation researcher Justin Drake has confirmed a significant architectural pivot: the Layer 1 roadmap is walking away from the Poseidon hash function in favor…
Lucas Meade·updated August 15, 2026

The Cryptonomist reports that Ethereum Foundation researcher Justin Drake has confirmed a significant architectural pivot: the Layer 1 roadmap is walking away from the Poseidon hash function in favor of SHA-2 and BLAKE2s, a shift framed around post-quantum resilience rather than SNARK-friendliness. For L2 engineers who spent years tuning circuits around Poseidon's algebraic structure, the announcement reframes a decade of design assumptions — and puts pressure on every zk-rollup whose proving pipeline was optimized for a specialized hash.
The math changed underneath
The traditional argument for Poseidon was straightforward: arithmetic-friendly hashes let SNARK provers absorb constraint-heavy operations far more efficiently than binary hashes built on bitwise operations. For years, that performance gap justified the Ethereum Foundation's long investment in the construction, with Drake characterizing the now-abandoned path as an "8-year, 8-figure rabbit hole" in post-quantum research.
What flipped the calculation isn't a new hash — it's a new proving stack. Projects like Binius and Flock demonstrated that binary-field SNARKs can now handle the Boolean logic of conventional hashes without the overhead that originally made them unattractive. According to the report, SHA-2 and BLAKE2s can match Poseidon's SNARK performance, proving roughly one million traditional hash calls per second on ordinary hardware. Drake's framing is precise: "the key was not SNARK-friendly hashes, but hash-friendly SNARKs."
In practice, this inverts the optimization trade-off matrix. L2 teams had been forced to choose between cryptographic maturity and prover efficiency; the upgrade suggests both are recoverable, at the cost of retraining prover pipelines around different constraint systems.
What this means for existing rollups
The immediate question for anyone running a zk-rollup or zkVM is scope of impact. Existing Poseidon-based systems are not required to change — the decision affects only Ethereum's own Layer 1 roadmap going forward. Billions in TVL sitting on top of Poseidon-optimized circuits continue to operate as designed, and the specialized approach that spread across zk-rollups and zkVMs since 2019 remains valid where it's deployed.
Conversely, the strategic signal matters. If L1 settlement moves to SHA-2 or BLAKE2s, recursive proof aggregation between L2 circuits and L1 verification shifts its cost model. Teams planning multi-year roadmaps — particularly those contemplating native rollups or L1-anchored proof compression — now have to model two different cryptographic regimes in their prover economics. Binary hashes bring bulkier witness data; SNARK-friendly arithmetic brings higher per-gate cost. The bottleneck simply moves from prover CPU to witness serialization.
What to watch
The broader Strawmap coordination document, which stretches through 2029, calls for a production-grade leanVM in 2027, with deployments across the consensus, data, and execution layers following in 2028. Each step still requires implementation, testing, and agreement among independent client teams before it becomes final — meaning the timeline is direction, not commitment.
For protocol engineers, three signals will tell us whether the shift actually lands. First, leanVM specifications: when concrete, they'll reveal whether SHA-2, BLAKE2s, or a hybrid becomes the canonical choice, and what that means for witness size budgets. Second, independent prover benchmarks from Binius and Flock: the one-million-hashes-per-second figure deserves reproduction under realistic constraint counts, not microbenchmarks. Third, L2 governance responses — whether major zk-rollups align with L1's new hash regime or treat Poseidon as a long-term divergence.
My recommendation, having watched enough L1 transitions from the prover side, is to wait for a public leanVM reference implementation before retooling any production prover pipeline around the new regime. Optimizing for a cryptographic choice that hasn't shipped is the kind of trade-off that burns engineering quarters.