Cabinet
Back to Technology Insights
2026.08.13

Ethereum drops Poseidon from the L1 roadmap for SHA or BLAKE — eight years of ZK-friendly hash research ends, and the assumptions underneath change

Ethereum drops Poseidon from the L1 roadmap for SHA or BLAKE — eight years of ZK-friendly hash research ends, and the assumptions underneath change

What happened

On 13 August 2026, Justin Drake posted "Goodbye, Poseidon!" on X, stating that the Ethereum Foundation is abandoning Poseidon for L1 and pivoting to SHA or BLAKE. He framed it as an epic eight-year, eight-figure rabbit hole in post-quantum cryptography reaching its dream conclusion — a destination rather than a retraction, which says something about how the decision is being understood internally.

Some context. Poseidon appeared in 2019, designed so that evaluating it inside a SNARK (Succinct Non-interactive Argument of Knowledge) circuit costs far less than a conventional hash built from bitwise AND and XOR operations. Because proving cost in ZK rollups and state trees depends heavily on the circuit cost of hashing, "pick a ZK-friendly hash" became close to an unexamined premise over the past decade. The EF backed Poseidon's security analysis with prizes, including a $1 million Poseidon Prize.

The EF's post-quantum work itself was consolidated publicly as pq.ethereum.org on 2026-03-24. It sets out what post-quantum migration means at the execution, consensus and data layers and maps a phased migration across named forks. On the consensus layer, the BLS signatures used to aggregate validator votes are to be replaced with leanXMSS, a hash-based scheme. On the execution layer, post-quantum signature verification through a vector-math precompile is intended to let users migrate via account abstraction rather than through a flag day where everyone upgrades simultaneously.

Why conventional hashes become viable again

What made the pivot possible is, most likely, a change on the proving side. The EF's post-quantum team has been building binary-field infrastructure inside leanVM, a minimal zero-knowledge virtual machine for verifying and aggregating proofs. Build a proof system over a field whose primitive operations are bitwise, and the circuit cost of a hash constructed from bitwise operations — SHA, BLAKE — falls relative to alternatives. Put the other way round: Poseidon's advantage was conditional on a proof system over a prime field. Change the premise and the optimum moves.

To be precise about terminology: the "field" here is the arithmetic world the proof system computes in. Over a prime field, addition and multiplication are the primitives, which favours an algebraically constructed hash like Poseidon. Over a binary field, XOR and AND are the primitives, which favours conventional constructions. This is not a ranking of hash functions; the ordering flips depending on which operations the layer beneath is good at.

There is also a conservatism argument. Strongly algebraic hashes like Poseidon have a comparatively short history of cryptanalysis against algebraic attacks. SHA-2, SHA-3 and BLAKE have been through standardisation, years of analysis and widely hardened implementations. For a post-quantum roadmap whose stated ambition is infrastructure that lasts centuries, putting a newer construction — chosen only for performance — at the deepest layer becomes harder to justify once leanVM removes the performance penalty. That reading is mine; it is not the order in which the EF presents the decision.

The prizes are worth noting in this light. The $1 million Poseidon Prize was set up to harden STARK-friendly hash functions, and a $1 million Proximity Prize to advance more efficient post-quantum signatures. The EF was actively soliciting external cryptanalysis on the assumption that Poseidon would be used. The pivot came after that process, which reads less like retreating from insufficient scrutiny and more like scrutiny concluding that a different answer wins.

The timeline is long. Per Drake, a production-grade leanVM is expected in 2027, with deployment touching Ethereum's consensus, data and execution layers in 2028. These are expectations recorded in Strawmap, a technical coordination document, not a confirmed activation calendar; each protocol change still requires implementation, testing and agreement among independent client teams. Strawmap itself sketches seven forks through 2029 on a roughly six-month cadence, with post-quantum L1 as one of five "north stars" alongside fast L1, gigagas L1, teragas L2 and private L1. The EF's FAQ notes that most engineering roadmaps place cryptographic relevance in the early-to-mid 2030s, and that upgrading decentralised global infrastructure takes years, which is why early preparation matters.

Pitfalls to watch

This is a decision about L1. The EF states explicitly that it is not Ethereum and not a central authority over protocol direction. L2s and applications may still have good reasons to use Poseidon, and nothing here requires replacing a proof system already running in production.

The impact lands on future design decisions, not current costs. Hash choice propagates into state tree shape, commitment compatibility and the set of audited libraries available, and it is hard to swap once in production. For proof systems being designed over the next two to three years, do not fix Poseidon as the premise.

Do not treat Strawmap years as dates. 2027 and 2028 are expectations conditional on implementation going well, not fork activation days. Rewriting a roadmap year as "scheduled" in internal material creates a problem you cannot explain later.

Post-quantum migration involves changing signature schemes, which means long-lead work on key management and signers — remote signers, HSMs, multisig. Hash-based schemes like leanXMSS can carry operational requirements that differ from ECDSA or BLS, including signature-count management in stateful variants. This is not an area where you can start once the spec is final.

[Technical Insights & Actions]

  1. The premise "choose a ZK-friendly hash" was itself conditional on another premise — a proof system over a prime field. Foundational technology choices can invert when the layer beneath them changes. For components you adopted because they were the industry default, writing down the premises that made them the default is what lets you follow a shift like this. [Architects / cryptography engineers] This quarter, document the hash and field choices in your proof system and commitment design along with the reasoning and the premises each depends on, and state the blast radius if a premise fails.
  2. Years in a roadmap document are not dates. Coordination documents like Strawmap communicate direction and ordering; activation days are decided separately through client team agreement. Confusing the two leaves you preparing either far too early or far too late. [Everyone] Label Strawmap years as expectations in internal material, and track confirmed dates separately through All Core Devs minutes and individual client release notes.
  3. The heaviest work in a post-quantum migration is not swapping algorithms but changing key and signer operations. Hash-based signatures can impose requirements that differ from ECDSA or BLS, and HSM or remote-signer vendor support is likely to be the constraint. [Node operators / key management leads] Within this fiscal year, ask your signer and HSM vendors for their position and timeline on post-quantum signature schemes including hash-based signatures, and fold the answers into procurement requirements.

[Sources]

This article is a technical commentary based on publicly available information and is not investment advice.

Previous ArticleGlamsterdam's gas repricing breaks the flat 21,000 assumption — EIP-8037's state gas dimension and what it does to wallets, indexers and estimatorsNext Article Solana sets 2026-09-28 for the start of Alpenglow feature activation — Firedancer will not cover the migration window, so operators must fall back to Agave