Nearly every major zkVM and zkEVM in production today - including Ziren - runs on Poseidon2. So this decision reaches far beyond Ethereum L1, and it did not come out of nowhere: the pivot has been under open discussion for at least four months. It is genuinely significant.
The cost of a SNARK/STARK proof is set by the size of the computation after arithmetization - the number of rows once the computation is expressed as a polynomial constraint system over a finite field. Traditional hashes like SHA-256 were designed for CPUs: internally they are AND, XOR, modular addition, and rotation on 32-bit words. Over a large prime field those bit operations are brutally expensive - each bit occupies its own field element, every carry needs constraints, and a single SHA-256 compression costs tens of thousands of R1CS constraints.
Poseidon inverted the philosophy: make the hash out of field operations. Its round function has only three components - round-constant addition, an S-box (x^a, a = 3/5/7), and a linear mixing layer - all native additions and multiplications over F_p, so one permutation costs a few hundred constraints. In the Plonky2 era, Poseidon hashing was roughly half of total proving time and the dominant bottleneck. That is the origin of the "SNARK-friendly hash".
In the lean Ethereum post-quantum roadmap, Poseidon's role went far beyond "a hash": the post-quantum signatures are hash-based, the state commitments are Merkle trees, the STARK polynomial commitments (the FRI/WHIR line) are Merkle trees too, and the Fiat-Shamir transform is again a hash. The entire post-quantum security reduction of the stack rested on this single primitive - a young one. Which raises the question: would you stake the security of a whole chain on a 2019 design?
Five months before this decision, Ethproofs held a dedicated Poseidon security review (Call #8, March 20), with attackers and defenders presenting side by side. The picture in one sentence: no break, but the margin is shrinking and the threat model is highly concentrated.
The attack progress is real. Merz and Rodriguez Garcia (ETH Zurich, "Skipping Class," ePrint 2026/306) exploited the tensor structure of Poseidon2's external linear layer - (0, 1, -1, 0) is an eigenvector of its left factor matrix, so a +/-X difference pattern passes through the linear layer round after round without diffusing - and built round-skipping algebraic attacks that cut the degree of the equation system from a^R to a^r. They broke the largest instance in the Ethereum Poseidon bounty program (t = 16, p = 2^31 - 1, x^5, 3 full + 4 partial + 3 full rounds), a ~2^18.5 speedup over prior methods, solved in 5.5 hours on a 64-core EPYC.
The margin loss comes with numbers. Poseidon co-author Schofnegger reported at the call: Poseidon1 (MDS matrices throughout) is unaffected, but for Poseidon2 the Grobner-basis preimage estimate drops from 2^164 to 2^126 for the 31-bit, t = 16, a = 3 instance, and from 2^174 to 2^123 for t = 24 - both now under the 2^128 mark. Koschatko (TU Graz) re-derived round numbers from the true bottleneck of the Grobner solving pipeline (the FGLM step) and concluded current parameters should gain rounds: t = 16, d = 7 from 8 full / 14 partial to 10 full / 17 partial. In 2026, "are the parameters sufficient" is still an open question under active revision.
The concentration is the deeper issue. Perrin (Inria, independent of the design team) made the point at the call: statistical, linear, and differential attacks pose essentially no threat to Poseidon - its entire security rests on a single line of algebraic attacks (polynomial system solving), and the complexity scaling of exactly that line is what the field has not pinned down. His verbatim conclusion: "at this stage, one of the safest AO permutations... which isn't saying much. Still a lot of unknowns!" Contrast SHA-2: twenty-five years of cryptanalysis across the full spectrum - differential, linear, algebraic, structural - and the best pseudo-preimage attack still stops at 52 of 64 rounds of SHA-256. Poseidon2 has had three years of exposure. Poseidon1, seven. The SHA family, decades.
The defenders were not without options. The repair paths presented at the call were complete: switch back to MDS matrices (Khovratovich showed the four-round skips cannot exist under an MDS linear layer), circulant MDS layers built from Reed-Solomon codes with manageable performance loss once accelerated by NTT and Karatsuba (Schofnegger), add full rounds at roughly 15% overhead, or a hybrid of Poseidon1 full rounds with Poseidon2 partial rounds. The bounty fund was raised to roughly .
Note the posture: the March consensus was "repairable." But a primitive that requires a million-dollar bounty program and its own designers on stage explaining how to restore the margin still carries - even once patched - the risk of insufficient analysis maturity. No patch removes that.
Poseidon's entire value rested on one premise: traditional hashes are too expensive in-circuit. The binary-field proof system line opened by Diamond and Posen's Binius (2023) had, by 2026, removed that premise.
The finite field a proof system arithmetizes over should match the native operations of the computation being proven. Over a binary field, XOR is field addition, AND is a single field multiplication, and shifts are linear maps - the three building blocks of SHA-2 and BLAKE circuits are all native operations, with no bit decomposition and no carry constraints. Instead of reshaping the hash to fit the proof system (the Poseidon route), reshape the proof system to fit the hash (the Binius route).
Combined with small-field commitments, sumcheck-based backbones, and serious engineering - joint work between the EF, Eigen Labs, and Succinct produced roughly 2.5x proving speedups; Succinct's Flock proves large batches of Boolean computation covering SHA-256, Keccak, and BLAKE3; the SNARK.fast challenge has crossed 1.8 million BLAKE3 compressions proven per second on a single machine - the figure in Drake's post is the proof: about 1 million traditional hash calls proven per second on a laptop, at roughly 100x overhead versus native CPU execution.
Once standard hashes are no longer slow in-circuit, the decision structure changes. It used to be: "if you want performance, you must accept the analysis risk of a young hash." Now it is: "performance is equal - on one side a NIST standard with decades of accumulated analysis plus global hardware acceleration, on the other a seven-year-old design that needs ongoing review calls and bounty programs." That is no longer a trade-off. It is a dominant strategy.
Binary-field SNARKs (2023 onward) are even younger than Poseidon (2019); on the surface this looks like risk relocation. But the failure structures are asymmetric.
A weakened hash is a primitive-layer failure: it burns through the entire stack - hash-based signatures become forgeable, state commitments can be opened to two different states, Fiat-Shamir becomes attackable - and historical commitments already on chain cannot be retroactively repaired.
Proof system defects are mostly mechanism-layer failures: soundness bugs, implementation flaws, parameter errors - typically fixable by upgrading the verifier or swapping the proving backend, leaving the underlying hash assumption and existing commitments untouched. And the security reduction of a binary-field SNARK still bottoms out at "the hash function is a random oracle / collision-resistant" - exactly the more mature assumption, SHA-2 or BLAKE.
This migration moves the young component from the assumption layer to the mechanism layer, and mechanism-layer errors are repairable by engineering. This is the most important - and least reported - step of reasoning in the entire decision.
Ziren runs Poseidon2 over KoalaBear today - the same neighborhood as the instances above. Two honest observations. First, nothing published breaks deployed parameters, and the updated round counts from the Graz analysis are a cheap patch for any deployment that wants restored margin. Second - the asymmetry argument again - a zkVM's internal hashing is a mechanism-layer component: swappable by engineering, with no permanent on-chain commitments depending on it. That is exactly why Ethereum L1, where the hash would have been the single assumption underwriting signatures and state forever, had to decide now - and why zkVMs can migrate deliberately.
Deliberately does not mean passively. Pivoting to BLAKE is one of our objectives too: Ziren recently migrated its public-input digest from Poseidon2 to BLAKE3, the first component to move. The rest follows as binary-field backends mature.
Lean Ethereum's timeline is a production-grade leanVM in 2027 and deployments in 2028. Post-quantum signatures (hash-based) plus STARKs (post-quantum proof systems relying only on hashes) mean the hash function is the single cryptographic assumption of the entire stack - a single signature in the proposed multi-signature scheme costs about 160 hash invocations, so hashing is the dominant cost of the whole design. Compressing the assumption set to a minimum is precisely the design principle of a post-quantum architecture. But then that single assumption must be the most battle-tested one available.
Ethereum abandoned Poseidon not because it was broken - the March review's consensus was explicitly "unbroken, repairable." The real reason is that three things became true simultaneously in 2026: (1) round-skipping attacks showed the security margin is smaller than the design assumed, with the threat model resting on a single line of algebraic attacks whose scaling the field has not pinned down; (2) binary-field SNARKs brought SHA-2 and BLAKE's in-circuit performance level with Poseidon's, removing its sole reason to exist; (3) in a post-quantum architecture where the hash function is the stack's only assumption, "most mature" beats "most optimized."
The deeper lesson is the one Justin names: the industry spent the better part of a decade making hashes friendly to SNARKs, and the answer was to make SNARKs friendly to hashes. Binary fields speak the native language of bits. Meet the hash where it lives and you get SHA-2-class assumptions at Poseidon-class speed - plus decades of free cryptanalysis.
Nearly every major zkVM and zkEVM in production today - including Ziren - runs on Poseidon2. So this decision reaches far beyond Ethereum L1, and it did not come out of nowhere: the pivot has been under open discussion for at least four months. It is genuinely significant.
The cost of a SNARK/STARK proof is set by the size of the computation after arithmetization - the number of rows once the computation is expressed as a polynomial constraint system over a finite field. Traditional hashes like SHA-256 were designed for CPUs: internally they are AND, XOR, modular addition, and rotation on 32-bit words. Over a large prime field those bit operations are brutally expensive - each bit occupies its own field element, every carry needs constraints, and a single SHA-256 compression costs tens of thousands of R1CS constraints.
Poseidon inverted the philosophy: make the hash out of field operations. Its round function has only three components - round-constant addition, an S-box (x^a, a = 3/5/7), and a linear mixing layer - all native additions and multiplications over F_p, so one permutation costs a few hundred constraints. In the Plonky2 era, Poseidon hashing was roughly half of total proving time and the dominant bottleneck. That is the origin of the "SNARK-friendly hash".
In the lean Ethereum post-quantum roadmap, Poseidon's role went far beyond "a hash": the post-quantum signatures are hash-based, the state commitments are Merkle trees, the STARK polynomial commitments (the FRI/WHIR line) are Merkle trees too, and the Fiat-Shamir transform is again a hash. The entire post-quantum security reduction of the stack rested on this single primitive - a young one. Which raises the question: would you stake the security of a whole chain on a 2019 design?
Five months before this decision, Ethproofs held a dedicated Poseidon security review (Call #8, March 20), with attackers and defenders presenting side by side. The picture in one sentence: no break, but the margin is shrinking and the threat model is highly concentrated.
The attack progress is real. Merz and Rodriguez Garcia (ETH Zurich, "Skipping Class," ePrint 2026/306) exploited the tensor structure of Poseidon2's external linear layer - (0, 1, -1, 0) is an eigenvector of its left factor matrix, so a +/-X difference pattern passes through the linear layer round after round without diffusing - and built round-skipping algebraic attacks that cut the degree of the equation system from a^R to a^r. They broke the largest instance in the Ethereum Poseidon bounty program (t = 16, p = 2^31 - 1, x^5, 3 full + 4 partial + 3 full rounds), a ~2^18.5 speedup over prior methods, solved in 5.5 hours on a 64-core EPYC.
The margin loss comes with numbers. Poseidon co-author Schofnegger reported at the call: Poseidon1 (MDS matrices throughout) is unaffected, but for Poseidon2 the Grobner-basis preimage estimate drops from 2^164 to 2^126 for the 31-bit, t = 16, a = 3 instance, and from 2^174 to 2^123 for t = 24 - both now under the 2^128 mark. Koschatko (TU Graz) re-derived round numbers from the true bottleneck of the Grobner solving pipeline (the FGLM step) and concluded current parameters should gain rounds: t = 16, d = 7 from 8 full / 14 partial to 10 full / 17 partial. In 2026, "are the parameters sufficient" is still an open question under active revision.
The concentration is the deeper issue. Perrin (Inria, independent of the design team) made the point at the call: statistical, linear, and differential attacks pose essentially no threat to Poseidon - its entire security rests on a single line of algebraic attacks (polynomial system solving), and the complexity scaling of exactly that line is what the field has not pinned down. His verbatim conclusion: "at this stage, one of the safest AO permutations... which isn't saying much. Still a lot of unknowns!" Contrast SHA-2: twenty-five years of cryptanalysis across the full spectrum - differential, linear, algebraic, structural - and the best pseudo-preimage attack still stops at 52 of 64 rounds of SHA-256. Poseidon2 has had three years of exposure. Poseidon1, seven. The SHA family, decades.
The defenders were not without options. The repair paths presented at the call were complete: switch back to MDS matrices (Khovratovich showed the four-round skips cannot exist under an MDS linear layer), circulant MDS layers built from Reed-Solomon codes with manageable performance loss once accelerated by NTT and Karatsuba (Schofnegger), add full rounds at roughly 15% overhead, or a hybrid of Poseidon1 full rounds with Poseidon2 partial rounds. The bounty fund was raised to roughly .
Note the posture: the March consensus was "repairable." But a primitive that requires a million-dollar bounty program and its own designers on stage explaining how to restore the margin still carries - even once patched - the risk of insufficient analysis maturity. No patch removes that.
Poseidon's entire value rested on one premise: traditional hashes are too expensive in-circuit. The binary-field proof system line opened by Diamond and Posen's Binius (2023) had, by 2026, removed that premise.
The finite field a proof system arithmetizes over should match the native operations of the computation being proven. Over a binary field, XOR is field addition, AND is a single field multiplication, and shifts are linear maps - the three building blocks of SHA-2 and BLAKE circuits are all native operations, with no bit decomposition and no carry constraints. Instead of reshaping the hash to fit the proof system (the Poseidon route), reshape the proof system to fit the hash (the Binius route).
Combined with small-field commitments, sumcheck-based backbones, and serious engineering - joint work between the EF, Eigen Labs, and Succinct produced roughly 2.5x proving speedups; Succinct's Flock proves large batches of Boolean computation covering SHA-256, Keccak, and BLAKE3; the SNARK.fast challenge has crossed 1.8 million BLAKE3 compressions proven per second on a single machine - the figure in Drake's post is the proof: about 1 million traditional hash calls proven per second on a laptop, at roughly 100x overhead versus native CPU execution.
Once standard hashes are no longer slow in-circuit, the decision structure changes. It used to be: "if you want performance, you must accept the analysis risk of a young hash." Now it is: "performance is equal - on one side a NIST standard with decades of accumulated analysis plus global hardware acceleration, on the other a seven-year-old design that needs ongoing review calls and bounty programs." That is no longer a trade-off. It is a dominant strategy.
Binary-field SNARKs (2023 onward) are even younger than Poseidon (2019); on the surface this looks like risk relocation. But the failure structures are asymmetric.
A weakened hash is a primitive-layer failure: it burns through the entire stack - hash-based signatures become forgeable, state commitments can be opened to two different states, Fiat-Shamir becomes attackable - and historical commitments already on chain cannot be retroactively repaired.
Proof system defects are mostly mechanism-layer failures: soundness bugs, implementation flaws, parameter errors - typically fixable by upgrading the verifier or swapping the proving backend, leaving the underlying hash assumption and existing commitments untouched. And the security reduction of a binary-field SNARK still bottoms out at "the hash function is a random oracle / collision-resistant" - exactly the more mature assumption, SHA-2 or BLAKE.
This migration moves the young component from the assumption layer to the mechanism layer, and mechanism-layer errors are repairable by engineering. This is the most important - and least reported - step of reasoning in the entire decision.
Ziren runs Poseidon2 over KoalaBear today - the same neighborhood as the instances above. Two honest observations. First, nothing published breaks deployed parameters, and the updated round counts from the Graz analysis are a cheap patch for any deployment that wants restored margin. Second - the asymmetry argument again - a zkVM's internal hashing is a mechanism-layer component: swappable by engineering, with no permanent on-chain commitments depending on it. That is exactly why Ethereum L1, where the hash would have been the single assumption underwriting signatures and state forever, had to decide now - and why zkVMs can migrate deliberately.
Deliberately does not mean passively. Pivoting to BLAKE is one of our objectives too: Ziren recently migrated its public-input digest from Poseidon2 to BLAKE3, the first component to move. The rest follows as binary-field backends mature.
Lean Ethereum's timeline is a production-grade leanVM in 2027 and deployments in 2028. Post-quantum signatures (hash-based) plus STARKs (post-quantum proof systems relying only on hashes) mean the hash function is the single cryptographic assumption of the entire stack - a single signature in the proposed multi-signature scheme costs about 160 hash invocations, so hashing is the dominant cost of the whole design. Compressing the assumption set to a minimum is precisely the design principle of a post-quantum architecture. But then that single assumption must be the most battle-tested one available.
Ethereum abandoned Poseidon not because it was broken - the March review's consensus was explicitly "unbroken, repairable." The real reason is that three things became true simultaneously in 2026: (1) round-skipping attacks showed the security margin is smaller than the design assumed, with the threat model resting on a single line of algebraic attacks whose scaling the field has not pinned down; (2) binary-field SNARKs brought SHA-2 and BLAKE's in-circuit performance level with Poseidon's, removing its sole reason to exist; (3) in a post-quantum architecture where the hash function is the stack's only assumption, "most mature" beats "most optimized."
The deeper lesson is the one Justin names: the industry spent the better part of a decade making hashes friendly to SNARKs, and the answer was to make SNARKs friendly to hashes. Binary fields speak the native language of bits. Meet the hash where it lives and you get SHA-2-class assumptions at Poseidon-class speed - plus decades of free cryptanalysis.
.png)
