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
Latest

Optimizing Cryptography with AI

Many of us are using AI to generate code. Vibe coding cryptography is especially sensitive - you have to uphold strict mathematical correctness. This can lead to wrong security guarantees and soundness bugs. We will discuss what are some patterns to do it well.

Kobi Gurkan · August 11, 2026

Introducing zkvmBlast: Differential Fuzzing for Ethereum's zkVMs

zkVMs are moving to the center of Ethereum's roadmap, which means a bug in a zkVM is turning into a bug in Ethereum itself. We built zkvmBlast, a zkVM-agnostic differential fuzzer that runs the same program across SP1, RISC0, OpenVM, Pico, Zisk, and Airbender against a reference simulator and flags any disagreement. It hunts for both soundness and completeness bugs, with a deliberate focus on completeness, an under-explored class that can turn a single valid block into a liveness failure. We share the first batch of findings.

Stefanos Chaliasos, Martín Ochoa, Varun Thakore · August 10, 2026

Circom-Auditor: Open-Source Skills for Finding Vulnerabilities in Circom Code

We are releasing zk-skills, a set of open-source security skills for AI coding agents, starting with circom-auditor: a first line of defense against vulnerabilities in Circom circuits, compatible with both Claude Code and Codex. On the zkbugs benchmark it detects up to 66 of 70 known bugs when pointed at the vulnerable circuits, and up to 40 of 56 when let loose on the full original codebases, far ahead of existing Circom security tools.

Stefanos Chaliasos, Hao Pham, False Witness Team · August 05, 2026
More to explore

ZPrize Came To An End! Who And How Did They Win $500,000?

In an exciting collaboration with ZPrize, we embarked on a journey to discover the fastest proofs for ECDSA signatures, ultimately crowning two standout approaches as winners. The blog post delves into the innovative solutions that captured the $500,000 prize by pushing the boundaries of zero-knowledge proofs. The story offers a fascinating glimpse into how these cutting-edge techniques might pave the way for privacy-focused applications. Curious to know which teams came out on top and how they did it? Dive in to explore the thrilling results and what's next in the ZK space!

ZK/SEC · May 06, 2024

A Technical Dive into Jolt: The RISC-V zkVM

In our latest post, we take you inside the workings of Jolt, a zero-knowledge virtual machine for the RISC-V architecture. This post breaks down the three main components that prove execution correctness: instruction lookup, offline memory checking, and the Rank-1 Constraint System (R1CS). By exploring these elements, you'll get a grasp on how Jolt ensures VM execution is accurate and reliable, using innovative methods like Lasso lookup arguments and the Spartan protocol. Join us as we unravel this cutting-edge zkVM, which not only promises simplicity but also the potential for exciting advancements.

Imam Al-Fath · December 09, 2024

Common Circom Pitfalls and How to Dodge Them, Part 1

Programming in Circom comes with its fair share of challenges. After reviewing numerous Circom codebases, we’ve identified certain anti-patterns that occur frequently. In this series, we’ll provide a comprehensive overview of these issues to help you avoid the most common pitfalls. Of course, this won’t be a complete list of every mistake possible (Circom has plenty of ways to trip you up). But the footguns we’ll cover are the ones that tend to catch developers off guard the most.

Marco Besier · June 24, 2025