Raising machine-checked security benchmarks to advance hash-based SNARKs through agentic collaboration
better.codes, an open autoresearch challenge built by the Ethereum Foundation Formal Verification team in collaboration with Yukon and zkSecurity, is now live. better.codes takes a self-contained problem from the Proximity Prize research, formalized in Lean, and puts its soundness bound on a public leaderboard that anyone can push forward....
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
better.codes is an open challenge where the security of a cryptographic proof system is settled by a machine rather than argued by reviewers. The Ethereum Foundation’s Formal Verification team, working with Yukon and zkSecurity, has taken a self-contained problem out of the Proximity Prize research, formalized it in the Lean theorem prover, and put the resulting soundness bound on a public leaderboard that anyone can attempt to push further. The framing worth noticing is the last phrase: agentic collaboration. The artifact under test is not a token or a product but a mathematical claim, and the proposed path to improving it is machine-assisted work on formal proofs rather than another round of human peer review.
What “machine-checked” buys, and what it does not
A formal proof is not a stronger opinion about a system. It is a derivation in a proof assistant’s logic, and the assistant’s kernel checks every step. If the derivation type-checks, the conclusion holds within the assumptions the formalization makes. That is a genuinely different guarantee from “reviewed by experts” or “audited by a firm” — and it is narrower in an important way.
The guarantee is conditional on the model. If the Lean formalization omits an assumption the real system relies on, a fully checked proof can still describe a system that does not behave as claimed. Formal verification moves the question from “is this argument sound?” to “is this model the right one?”, and the second question is not answered by the proof. Nobody has claimed otherwise, but the gap between a checked proof and a verified system is exactly where misunderstanding lives.
Why hash-based SNARKs specifically
Hash-based SNARKs build their security on collision resistance of a hash function rather than on elliptic-curve assumptions. That choice matters for two reasons.
First, it removes reliance on the cryptographic assumptions underpinning pairing-based SNARKs — assumptions that quantum computers are expected to break, and that introduced serious practical constraints on recursive proving systems. Hash-based constructions target post-quantum resistance by design.
Second, a hash function is a far simpler object to reason about formally than an elliptic curve. Verifying a hash-based proof system involves algebraic reasoning about a compression function, not geometry over a finite field. Simpler objects are tractable objects in a proof assistant, which is why this family is a plausible target for machine-checked guarantees first.
The cost is real and well known: hash-based signatures and proofs carry larger sizes and slower verification than pairing-based alternatives. The research question is whether that overhead can be reduced without giving up the assumption advantage, and a public leaderboard with an explicit soundness bound is a reasonable way to invite attempts.
What a leaderboard measures
A public leaderboard makes two things comparable at once: how strong a soundness bound a construction achieves, and at what cost. A bound alone is not a win — a bound achieved only at impractical sizes or verification times is not useful in production. Any meaningful score therefore has to carry its parameters alongside the number.
This also means the leaderboard is a statement about constructions, not about deployments. Nothing here is a live protocol, an investment, or a recommendation. A hash-based SNARK system achieving a particular bound today tells you nothing about whether it will be deployed, or when, or by whom.
Why the agentic framing matters
Formalizing a research problem into a proof assistant’s logic is expensive, repetitive work: restating definitions, bridging library lemmas, resolving intermediate goals. It is the kind of work that resists human throughput and is well suited to an assistant that can iterate on many small proof states at once. Proposing that agents can push forward a soundness bound is a bet about that mismatch.
It is also a bet that needs care. Machine-generated proof attempts must still be checked by the same kernel — that is the entire point of the setup, since an unverified “proof” an agent claims to have produced is worthless. The soundness of the leaderboard depends entirely on the checking being independent of the proposing.
What this does and does not resolve
For a reader tracking zero-knowledge research, the useful takeaway is that proof quality in this family is becoming something that can be measured publicly and improved competitively, rather than something asserted in a paper’s conclusion section.
For a reader tracking DeFi, there is no actionable consequence today. No user-facing product changes, no token is affected, and no risk is reduced in any deployed system by a better bound on a construction. Progress in applied cryptography reaches users through audited implementations and shipped protocols, and this challenge is upstream of that by a wide margin.
This article describes a research challenge as announced. It is not financial, legal or security advice, and it makes no claim about any deployed system.