ZK/SEC Research notes from zkSecurity
All posts
announcement · zk · security

On ZK Security, ZK Summit, and a Decade of Progress

zkSummit

This Thursday, May 7th, we're sponsoring zkSummit14 in Rome.

zkSummit is one of the very few events where the people actually building zero-knowledge systems all end up in the same room, and it's the reason we keep showing up year after year. Honestly, ZK as a field, and zkSecurity as a company, wouldn't be where it is today without zkSummit and the team behind it. The conversations there have a way of outlasting the day by a few months, so this time around we wanted to back it more directly. We're sponsoring, a good chunk of the team will be there, and if you're going to be in Rome on Thursday please come find us. It's by far the easiest way to talk to us about ZK security in person, and we'd much rather meet you there than over a contact form.

It also feels like the right moment for it. Ten years ago, ZK was mostly papers and toy implementations (this year is, fittingly, the 10th anniversary of Groth16, the proof system that quietly powers a huge chunk of what's deployed today). Today, hundreds of millions of dollars in value already move through zero-knowledge protocols every day. Mainnets settle with it, browsers verify it, zkVMs compile real programs into it. The libraries are reusable, the protocols are deployed, and the bugs cost real money. And that maturity is now starting to spill outside of crypto too: Google has been publishing on zero-knowledge and is shipping ZK into product for things like age verification, which means ZK is now protecting personal data in flows that touch ordinary users, not just value between wallets.

From where we sit, after 100+ ZK audits across circuits, zkVMs, and full protocols, the clearest signal that this is no longer theoretical happened just a few months ago. In February, a privacy pool called Veil became the first known blackhat exploit against a live ZK protocol: it got drained for around \$5K (small as far as crypto exploits go, and notably we are still waiting to see the first million-dollar blackhat exploit against a live ZK protocol) because its Groth16 verifier had skipped the second phase of its trusted setup ceremony, leaving γ and δ equal and turning the verifier into a rubber stamp (see the post for more detail). Anyone who noticed could forge proofs without a witness. A few days later the exact same bug surfaced in Foom, a much larger lottery dApp on Base and Ethereum, and this time one of our team members, @duha_real, spotted it first and led the whitehat rescue, recovering around \$500K on the Base side before a malicious actor could touch it (an anonymous whitehat independently drained the Ethereum side).

First real-world blackhat exploit, first whitehat rescue, same week.

What's striking is that neither of those bugs was a subtle underconstrained circuit or a deep cryptographic flaw. Both were a single missing step in a deployment script, and that keeps being the pattern for the bugs that surface publicly. Classics like Fiat-Shamir misuse, despite being well understood in theory, simply refuse to die. Everyone "knows" the rule. Almost nobody implements it correctly the first time. The bugs we find inside paid audits are a different story. They're deeper, harder to spot, and almost never the kind of thing a careful skim of the repo would catch. The catastrophic things hiding in production ZK code rarely look like the ones that end up on Twitter.

The encouraging part is that this is finally a domain where automation is starting to pull its weight. Our continuous auditing system zkao has already caught real bugs in production code that got fixed before they cost anyone money, the kind of findings that, left alone, would have been very expensive. The million-dollar bugs so far still come out of human audits, which is exactly why we keep doing them. The way we think about zkao is less "a scanner you run once" and more "a tireless researcher embedded in your codebase": you connect it once, and as our agents and the underlying models keep getting better, they keep coming back to your circuits months later. A bug that wasn't detectable in January might surface in June, without you re-engaging anyone.

So if you're working on a new proof system, a zkVM, or a protocol that handles real money, come say hi at zkSummit14 in Rome this Thursday. And if you'd rather keep talking afterwards, hello@zksecurity.xyz is still the easiest way to reach us.

Keep reading
More to explore

AI meets Cryptography 1: What AI Found in Cloudflare's CIRCL

We pointed our AI audit pipeline at Cloudflare's CIRCL experimental cryptography library and confirmed seven real bugs, from a critical float64 precision loss in threshold RSA to a complete access-control break in attribute-based encryption. All seven are now fixed upstream. This is the first post in a series on bugs our agents found across open source cryptography.

Stefanos Chaliasos, Hao Pham · July 07, 2026

Faster Sumchecks: Part I

In this blog post, we explore how to optimize the sumcheck protocol, particularly when working with values in a small field and randomness from a large field, as often needed in zkVMs. We introduce various algorithms aimed at reducing expensive operations, focusing on minimizing large multiplications. Starting from using simple evaluation tables to more sophisticated techniques like precomputing accumulators and leveraging Lagrange interpolation, we demonstrate how to efficiently organize computations to speed up proving times. Readers will gain insights into handling arithmetic operations within the sumcheck protocol and learn about optimizing specific cases in zero-knowledge proofs.

Jason Park · November 21, 2025

SoK: What don’t we know? Understanding Security Vulnerabilities in SNARKs

We've teamed up with some of the top minds in academia and industry to dive deep into the world of zero-knowledge proofs (ZKPs) and their vulnerabilities. Our new paper catalogues hundreds of ZK vulnerabilities, breaking down their root causes and offering strategies to sidestep these pitfalls. By digging into real-life SNARK implementations, we aim to bolster the security of these cutting-edge systems with actionable insights and recommendations. Curious about what makes ZKPs tick and how to keep them secure? You might find this study just what you need!

ZK/SEC · February 26, 2024