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

Variants of KZG: Part III, Multilinear Commitments with Zeromorph

In this blog post, we extend univariate KZG commitments to multilinear polynomials through Zeromorph. We introduce the univariatization map, encode the multilinear quotient identity as a univariate identity, and explain why the quotient encodings require degree checks. We then show how Zeromorph batches these checks into a single degree-bounded KZG opening and walk through its end-to-end opening protocol. We conclude by examining its proof size, prover cost, and verifier cost.

Varun Thakore · August 04, 2026

Variants of KZG: Part II, Multilinear Commitments with PST

In this blog post, we extend the ideas behind univariate KZG commitments to multilinear polynomials through the PST commitment scheme. We derive the multilinear quotient identity, explain how PST commits to and opens multilinear polynomials using a specialized multilinear setup and walk through its opening protocol. We conclude by examining the proof size, prover and verifier costs, and the limitations that motivate other multilinear polynomial commitment schemes.

Varun Thakore · July 28, 2026

Threshold ECDSA: Building CGGMP from scratch

A step-by-step build of CGGMP, an n-of-n threshold ECDSA scheme where parties jointly produce a signature without ever reconstructing the private key. We start from the multiplicative-to-additive (MtA) protocol and a semi-honest version of the signing protocol, then harden it into a maliciously secure one by layering in zero-knowledge proofs at each step. Along the way we cover the auxiliary Ring-Pedersen and Paillier parameters and the proofs that make them safe to use.

Samuel Tang · July 27, 2026
More to explore

Soundness Failures in LaBRADOR Implementations from NTT -Friendly Rings

Post-quantum cryptography is making its way into production libraries, and correct implementation is far from trivial. We reviewed several LaBRADOR implementations on GitHub and found three of them broken, with soundness collapsing as far as a single bit, because of parameter choices that look perfectly reasonable in many lattice-based protocols; a power-of-2 modulus, a composite modulus, or NTT-friendly rings for efficient ring multiplication. The post goes through how each of those choices undermines the protocol's soundness argument, and why NTT-friendliness, of all things, turns out to be the wrong instinct if not handled carefully.

Georgios Raikos · April 30, 2026

Why does FRI work?

This blog post explains the security intuition behind the FRI protocol, which proves that a function is close to a valid Reed-Solomon codeword. It introduces the "prover message graph," a layered structure that visualizes how correct and incorrect folds affect verification. We conclude that if too many folds are inconsistent, the verifier will likely reject, but if most are correct, the initial function must be close to a proper codeword.

Nicolas Mohnblatt · October 30, 2025

A challenge on the Jolt zkVM

Last weekend, we had a blast crafting challenges for a CTF event at the MOCA Italian hacker camp. One cryptography challenge, "2+2=5," involved the Jolt zkVM and a RISC-V program. In this post, we share the ins and outs of the challenge, the clever use of a modified Jolt library, and how we managed to prove an invalid execution without triggering verification alarms. Get ready to dive into the world of Jolt and pick up some nifty insights on exploiting cryptographic systems like a true hacker.

Giorgio Dell'Immagine · September 24, 2024