The Ethereum Foundation Spent Eight Years on a Hash Its Roadmap No Longer Needs

Table of Contents

• What Poseidon was built to solve
• Why the roadmap depended on it
• The confidence they were trying to buy
• Buterin refused a precompile six months earlier
• Hash-friendly SNARKs
• What the announcement does not say
• What the AI cryptanalysis release actually said about Poseidon
• A related pattern in TLS
• What this means if you don’t run a blockchain
• What to watch

August 13, 2026 — Ethereum Foundation researcher Justin Drake posted that the Foundation is abandoning Poseidon for Ethereum’s layer 1 and pivoting to SHA or BLAKE. He called it the end of an eight-year, eight-figure rabbit hole. Twelve days earlier, on August 1, the Foundation had paused its Poseidon1 Collision Prize, a bounty carrying a $992,000 budget that had been scheduled to run until January 2029.

Nobody has published a practical break of a recommended, full-round Poseidon parameter set. Researchers claimed partial collisions and round-reduced preimages against the challenge instances the Foundation set for them, which is exactly what those programs exist to produce. Vitalik Buterin said in February that the program had turned up security issues in Poseidon2 serious enough to consider adding rounds or reverting to Poseidon1. None of that forced this decision. What moved was the other side of the equation, and it moved from a direction nobody was watching: the proof systems Poseidon was designed to fit got fast enough that they no longer need a hash designed to fit them.

The bottom line for anyone who doesn’t run a blockchain is that a primitive chosen because it fits the performance constraint of the moment acquires a liability when that constraint moves, and engineering constraints can move faster than confidence accumulates around a young design. The Foundation spent eight years and a serious budget on a class of hashes built for its proof systems. The emerging answer is a proof system built for the hashes applications already use.

What Poseidon was built to solve

Poseidon is an arithmetization-oriented hash function, published in 2019 by Lorenzo Grassi, Dmitry Khovratovich, Christian Rechberger, Arnab Roy and Markus Schofnegger and presented at USENIX Security in 2021. The paper answers a cost model most of us in security never meet.

In a conventional prime-field SNARK, the circuit designer’s first-order cost is not an instruction count. It is the number and shape of arithmetic constraints, which later become prover time, memory traffic and hardware bills. SHA-256 is built from XOR, AND, 32-bit rotations and 32-bit modular addition, so expressing it over a large prime field means decomposing every word into bits and constraining each one. A SHA-family compression can run to tens of thousands of low-level constraints that way.

Poseidon instead uses a sponge over the same prime field the prover already works in, with a low-degree power S-box and a round structure that spends full rounds at the ends and cheaper partial rounds through the middle. A permutation can often be expressed in hundreds of constraints. Exact ratios depend on the proof system, the circuit model and the gadget design, but one to two orders of magnitude is the range that made the decision.

That gap made arithmetization-oriented hashing the rational choice, and Poseidon became one of the most widely adopted of the family across zk-rollups, STARK systems and zkVM tooling. Poseidon2 followed in 2023 with better native performance. Rescue, Rescue-Prime, MiMC and Anemoi were all available. Poseidon won on a combination of circuit economics and adoption rather than by being the only option.

Why the roadmap depended on it

Drake published lean Ethereum on July 31, 2025, one day after Ethereum’s tenth birthday. The proposal makes the hash function the single cryptographic primitive across all three layer-1 sublayers: hash-based aggregate signatures in place of BLS in consensus, hash-based commitments in place of KZG in the data layer, hash-based real-time zkVMs in place of re-execution. Fort mode and beast mode, in his framing. All three are proposals, none is an adopted upgrade.

Run the consensus arithmetic and the dependency becomes obvious. A leanXMSS signature is roughly 3,000 bytes against 96 for BLS. Ethereum had 898,286 active validators on August 15, 2026, with roughly 41.8 million ETH staked, worth around $80 billion at that day’s price.

They do not all attest every slot. Each active validator attests once per 32-slot epoch, which averages roughly 28,000 attestations per twelve-second slot. At about 160 hash invocations to verify one signature in the multi-signature scheme proposed by Drake, Khovratovich, Mikhail Kudinov and Benedikt Wagner, that is around 4.5 million hashes per slot, or roughly 374,000 per second. Aggregation overhead and everything else the proof has to carry come on top.

Buterin’s own estimate was that 200,000 hashes per second would suffice for a post-quantum Ethereum. The real workload sits in the same order of magnitude, which is why the cost of one hash inside a circuit was the number the entire architecture turned on. The lean consensus plan published in November 2025 specified LeanVM over the KoalaBear prime, chosen partly for efficient Poseidon2 S-boxes. Its integration bus carried POSEIDON_16 and POSEIDON_24 permutation precompiles, with a target of 1,000 signature verifications per second. The prospective post-quantum architecture had made an arithmetization-oriented hash a central dependency across several components at once.

The confidence they were trying to buy

That is why the Ethereum Foundation launched the Poseidon Cryptanalysis Initiative in November 2024, run by George Kadianakis, Khovratovich and Antonio Sanso. The advisory board includes Jean-Philippe Aumasson, Eli Ben-Sasson, Daira-Emma Hopwood, Daniel Lubarov and Ron Rothblum. It was an attempt to buy, in two years, the scrutiny SHA-2 has accumulated since 2001.

Announced ceilings ran to $130,000 for the 2025 bounty program, $150,000 for 2026, a $90,000 award fund for published attack papers, research grants of $20,000 to $40,000 each, and the $992,000 collision prize, plus six academic workshops from January 2025 through May 2026. Those ceilings total roughly $1.36 million, which is not the same as money disbursed. The Foundation has not published a consolidated expenditure figure.

Results arrived progressively, as designed. Solutions to CICO challenges, which ask for a partial preimage of zero through the inner permutation, were verified in April, May and July 2026. Zero-test records climbed from six full rounds and seven partial rounds in early June to twelve partial rounds by July 27. The first tier of the collision prize, a three-element partial collision against the full-round Poseidon1 compression function, was claimed on April 6 for $32,000. Antoine Bak, Augustin Bariant, Aurélien Boeuf and colleagues published the resultant-based techniques behind several earlier bounty claims.

None of that is a break of a deployed parameter set. The problem was never a break. It was that the estimates wouldn’t settle. The Foundation’s own grant page asks researchers to derive a formula for Gröbner basis preimage attacks on the stated grounds that existing papers carry very imprecise complexity estimates. Grassi, Katharina Koschatko and Rechberger confirmed the overall security of Poseidon and Poseidon2 against the algebraic attacks they analyzed. A Simula-affiliated project reported the same shape of finding: the parameter sets that matter for real deployments show no sign of weakness, while other regimes turn out weaker than earlier analysis predicted.

Two years and more than a million dollars in, the honest summary was no break on the parameters anyone cared about, and no confident way to extrapolate the cost of an attack on the full function. That is not a failure of the initiative. It is what buying confidence in a young design actually costs, and the next vendor who says their novel primitive “has been reviewed” is implicitly claiming to have done something like this.

Buterin refused a precompile six months earlier

The most useful document in this whole episode predates the announcement by half a year, and none of the first-day coverage I read cited it.

In February 2026, answering a complaint that Solana, Starknet and Stellar all ship a Poseidon precompile while Ethereum does not, Buterin explained why he had resisted one at the execution layer. He wrote that the Foundation had been running a cryptanalysis program against Poseidon2 for nearly two years. It had already identified issues that would need either extra rounds or a reversion to Poseidon1, which had held.

Enshrining one version in a precompile would have meant migrating off it when that happened and leaving behind a precompile nobody uses that every new client implementation still has to carry.

Two things follow. The first is that the argument this article is making was made in advance, in public, by the person best placed to make it, about the exact primitive that then got dropped. It lost the popularity contest at the time.

The second is a correction to the tidy story: the security picture was never uniformly clean. Poseidon1 held. Poseidon2, the faster successor most implementations reach for, did not hold as cleanly, and the initiative’s second phase moved its focus onto Poseidon1 over the KoalaBear field.

Hash-friendly SNARKs

Drake’s summary of what changed is the useful one. In hindsight, he wrote, the key was not SNARK-friendly hashes but hash-friendly SNARKs, and the secret is arithmetic over the smallest prime, two. More precisely, binary extension fields of characteristic two, built over the field with two elements.

Bit operations stop being expensive when the prover’s native field is already bits. Benjamin Diamond and Jim Posen demonstrated the practical value with Binius at EUROCRYPT 2025, followed by the Binius64 implementation. In June 2026, Benedikt Bünz, Rothblum and William Wang posted Flock, a binary-field SNARK built for proving batches of standard hashes.

On one core of an Apple M4 Max, the prototype reports 82,100 BLAKE3 compressions per second, 42,100 SHA-256 compressions and 30,700 Keccak permutations, at less than 250 times native overhead. On ten cores, BLAKE3 passes 660,000 compressions per second.

The paper puts Flock at more than nine times faster than Binius64 on SHA-256 and about fourteen times faster than Binius64 and Plonky3 on BLAKE3. The authors extrapolate the ten-core figure to the hashing inside signature verification for roughly 4,000 transactions per second. That number covers only the hashing, with transaction execution and state access extra. The native baseline in these comparisons does not use Apple’s dedicated SHA instructions and runs the hashes serially, which the authors state.

Rothblum makes the case against SNARK-friendly hashes in two parts in Succinct’s announcement. The security half is familiar. These designs have far less adversarial attention than SHA-256 or Keccak, and their algebraic structure has repeatedly opened attack surface.

The lock-in half is the one that travels outside crypto. A SNARK-friendly hash is cheap only inside a proof system built over the one field it was designed for, so choosing it enshrines that field. The gains disappear if you swap provers or compose across fields. Target a standard hash and the choice dissolves, because the hash is fixed by the application and runs identically whether or not a proof is ever produced. It is Buterin’s precompile argument in a different register.

Rothblum sits on the Poseidon initiative’s advisory board and co-wrote the proof system that made Poseidon unnecessary, which I note for disclosure rather than as an objection. The technical argument stands on its own either way.

What the announcement does not say

Most of the first-day coverage omitted four things.

The headline number runs ahead of the published one. Drake cites roughly one million traditional hash calls per second on a laptop at about 100 times native overhead. That is a roadmap-level summary rather than any single published Flock benchmark. The extra factor comes from SNARK.fast, an automated project using AI to optimize proving code, whose best result is quoted at 1.8 million BLAKE3 compressions per second and a 255% improvement over its starting benchmark. There’s no paper and no published methodology. Separately, Sreeram Kannan of Eigen Labs said joint work with the Foundation and Succinct had raised proving speeds about 2.5 times. Use the peer-visible figures until the rest appear in papers with a stated methodology.

Flock is a prototype. Its authors say they do not recommend it for production, note that the implementation was co-designed with coding agents, and restrict it to batches of a fixed Boolean circuit rather than general computation. It proves hash chains and Merkle openings today. Full signature aggregation is described as an extension in principle and would need additional work. The caution is earned across the whole binary-field lineage. Binius64, the prior state of the art Flock benchmarks against, was one of six zkVMs OtterSec caught shipping the same Fiat-Shamir transcript-binding failure in March.

“SHA or BLAKE” is still a shortlist. Coverage of the same announcement variously reports SHA-2, SHA-256, BLAKE2s and BLAKE3, and no parameter set has been named. Those functions are not interchangeable on institutional maturity either. SHA-2 has a quarter-century of public analysis behind it; BLAKE3 dates to 2020.

Nothing arising from this pivot is deployed on mainnet. A production-grade leanVM is targeted for 2027 and consensus, data and execution deployments for 2028, inside a Strawmap that runs to 2029 and describes itself as a coordination document rather than an activation calendar. Drake flags the dates as preliminary, and every change still needs client implementation and agreement among Ethereum’s independent development teams. Rollups and zkVMs already running Poseidon are under no obligation to change anything. This is a research pivot announced by one Foundation researcher. Ethereum’s governance has decided nothing.

What the AI cryptanalysis release actually said about Poseidon

Drake’s announcement arrived sixteen days after one of the year’s largest cryptanalysis disclosures, and he named it.

On July 28, Anthropic disclosed that Claude Mythos Preview had recovered signing-equivalent keys from two HAWK-256 challenge public keys, in a few hours on one server. The research campaign cost roughly $100,000 in API spend. The mechanism is a Galois involution in HAWK’s power-of-two cyclotomic ring that reduces key recovery to exact-SVP calls in dimension n/2 + 1. That drops HAWK-512 from 2^150 to at most 2^108 in the specification’s own gate-count model.

I covered the release and the gap between Anthropic’s blog summary and the citable paper when it landed, and the secondary coverage since has mostly copied the blog.

Drake also cited SQIsign. The relevant result there is Benjamin Wesolowski’s, solving the supersingular isogeny problem in time and memory p^(1/3+o(1)) under a heuristic smoothness assumption, against a previous best near p^(1/2). It is not the same category of event as HAWK. The paper states directly that the impact on concrete parameter sets remains to be clarified, because a superpolynomial overhead hides in the o(1) exponent and the memory requirement is severe.

The same Anthropic release contains a detail directly relevant here, and I have not seen anyone connect it. They pointed Mythos at Poseidon too. The improvement was less than ten times, alongside similar sub-10x results on Salsa20 and SHA-1, and no paper has been released. Set against a genuine break of a NIST candidate produced in the same run, that’s a mildly reassuring data point for Poseidon.

So I will not argue that AI-assisted cryptanalysis is inherently deadlier against algebraic hashes. The one public data point runs the other way, and Keccak is itself a highly structured design. The narrower claim is the one that holds, and it’s the one a planner should act on. Young designs with heavy structure and unsettled concrete attack estimates are harder to price than primitives with long public review behind them. That pricing problem exists whether or not anyone ever finds a break.

Drake wrote that there is no longer a need to wait years for Poseidon cryptanalysis to bake. A publishable cryptanalytic result now costs on the order of $100,000 and a week of model time, so the bake times of every young design are about to be tested at once.

A related pattern in TLS

Security engineering has run a version of this before, and the previous round is instructive about timing rather than about mechanism.

Through the 2000s, AES in software was expensive enough that RC4 stayed in wide TLS deployment partly on performance grounds. Intel shipped AES-NI with the Westmere generation in 2010 and that advantage eroded. RC4 persisted anyway, through legacy compatibility and through its temporary use as a workaround for the CBC-mode weaknesses of the BEAST era, and it only became untenable as AES-GCM deployment improved and practical RC4 attacks accumulated. The IETF prohibited it in TLS in RFC 7465 in February 2015, five years after the hardware had begun removing its rationale.

Ethereum’s advantage is not that it can migrate faster than TLS did. It is that this particular dependency still sits in a research roadmap rather than in billions of deployed endpoints. The rest of us have the harder version of the problem, where the primitive is already in production.

What this means if you don’t run a blockchain

The novel primitive is a deferred bill, not a discount. A design chosen because it fits today’s performance envelope carries an unpriced liability. It has less review than the standard, and the envelope it was chosen for will move. The Foundation got the good version of that outcome, where the envelope moved before deployment and the bill came due as a roadmap edit. Nobody should count on that timing.

Agility is architectural, and Buterin’s precompile refusal is the cleanest demonstration I have seen. Crypto-agility is not a library swap. What made the pivot possible is that the hash choice sat at a boundary rather than welded into consensus rules, client implementations and a decade of on-chain state. It sat there because someone argued for keeping it there while the argument was unpopular. Solana, Starknet and Stellar made the other choice. My working rule is that adaptability determines survivability, and this is a better worked example than anything I could construct. On the morning of the day Drake posted, I published the commitment-layer version of this argument. A deployed verifier survives a quantum break only if its commitment scheme sits behind a swappable interface rather than fused into the verification semantics.

Conservative selection has option value nobody prices. The same reasoning shows up in national guidance. ANSSI exempts hash-based signatures from its general hybridization requirement, and BSI treats the approved stateful XMSS and LMS families differently in its own. Reading SLH-DSA as the diversification hedge against ML-DSA is my inference from that pattern rather than a joint agency position, but the logic is the same. If you can meet the performance bar with a primitive carrying decades of cryptanalysis, the exotic option was never the cheaper choice.

Don’t over-read it in the other direction. Hash-based cryptography is not free. Signature sizes are why Ethereum needs a whole zkVM to make consensus work. Grover’s algorithm cuts an n-bit hash’s preimage security to about 2^(n/2). Generic quantum collision finding under Brassard-Høyer-Tapp runs near 2^(n/3) rather than the classical 2^(n/2), with heavy quantum-memory assumptions attached. The popular “Grover halves everything” line is wrong in both directions.

Stateful schemes in the XMSS family carry state-reuse hazards severe enough that RFC 8391 warns the security guarantees fail outright if state repeats, which is why approved profiles restrict key generation and export. The lesson is about primitive selection under uncertainty, not about hashes being magic.

And this changes nothing about the threat model. It does not move Q-Day, it does not change CRQC resource estimates, and it does not alter the exposure profile of Ethereum’s deployed cryptography, which still runs on secp256k1 for accounts and BLS12-381 for validators. What it changes is one dependency inside one prospective architecture, and the migration is still governed by deadlines rather than predictions.

What to watch

Three things will tell you whether this holds. Whether the SNARK.fast throughput figures survive into a paper with a protocol and a stated benchmark methodology. Which specific function and parameter set the Foundation names, since SHA-2 and BLAKE3 differ in both hardware acceleration and review history. And whether the Poseidon initiative’s December 2026 award papers still arrive now that the Foundation has stopped needing the answer.

That last one is the test of whether this was engineering or exit. The Foundation kept a $992,000 collision prize open until the question stopped mattering to its roadmap, and then paused it. That is the correct call on its own terms. It is also a measure of how much had been riding on a question that never got a settled answer.

The post The Ethereum Foundation Spent Eight Years on a Hash Its Roadmap No Longer Needs appeared first on PostQuantum - Quantum Computing, Quantum Security, PQC.