July–August 2026

Audit of Zcash: Orchard

Tachyon Foundation

A focused one-week review of Zcash’s Orchard crate and the Halo2 gadgets, proofs, and Poseidon crates it builds on, aimed at reducing tail risk in that code.

Audit of onlyswaps and dcipher (BLS signatures)

Randa-mu

Review of Randa-mu’s OnlySwaps cross-chain protocol and the BLS threshold signature implementation behind it, covering the Solidity contracts, hash-to-curve on BLS12-381, and Shamir secret sharing.

Generalized Bulletproofs

MAGIC Grants

Review of the generalized-bulletproofs crate in monero-oxide, a soundness- and privacy-critical component of Monero’s upcoming full-chain membership proofs (FCMP++).

Audit of HumanityLink's Aid Distribution System

HumanityLink

An engagement that added Leo and Aleo support to zkao, with HumanityLink’s Aleo-based aid distribution system as the test target. The report covers the integration and the findings from zkao scans and manual review of the Leo programs, backend, and frontend.

Variants of KZG: Part V, Multilinear Commitments with Mercury

In this final post of the series, we extend univariate KZG commitments to multilinear polynomials through Mercury. Building on Gemini, we fold half of the variables at once, use polynomial division to bind this large fold to the original commitment and reduce the remaining multilinear evaluations to a batched inner product check. We then walk through the end-to-end opening protocol. We conclude by examining its proof size, prover cost and verifier cost.

Variants of KZG: Part IV, Multilinear Commitments with Gemini

In this blog post, we extend univariate KZG commitments to multilinear polynomials through Gemini. We introduce recursive partial evaluations, derive the split-and-fold identity and express each fold as a univariate identity that can be checked using KZG openings. We then walk through the end-to-end opening protocol. We conclude by examining its proof size, prover cost, and verifier cost.

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.

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.

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.

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.

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.

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.

zkao 2.0 is here

zkao 2.0 is out: a complete redesign of our continuous security scanning tool, a new pay-as-you-go model that replaces subscriptions, and a long list of improvements across scanning, triaging, and reporting.

Archetype x zkSecurity - Proof is in the Pudding: Groth16

In Session 10 of “Proof is in the Pudding,” we work backward from Groth16’s famously compact verifier equation to explain why the protocol is shaped the way it is. We cover how R1CS constraints become polynomial identities, why pairings are needed to multiply hidden commitments, how random linear combinations and the Schwartz-Zippel lemma enforce witness consistency, and how the separating factors gamma and delta restrict which pieces of the CRS a prover can use.

AI meets Cryptography 3: What AI Found in Bron Labs's bron-crypto

We pointed our AI audit pipeline at bron-crypto, Bron Labs’s Go library for MPC and threshold signatures, and confirmed four bugs. All of them are now fixed upstream. This is the third post in our series on bugs our agents found across open source cryptography.

Nine Years to Halve a Hash Function: RFC 9861 Is Out

After nearly a decade in the making, RFC 9861: KangarooTwelve and TurboSHAKE was officially published in October 2025, with zkSecurity among its editors. This post explains why these hash functions deserve to be far more widely used than they are today. Built on the same Keccak permutation as SHA-3 and SHAKE but with the round count halved, they do the same job at the same security level roughly twice as fast. We cover why halving the rounds is safe, what the RFC actually defines, the caveats around FIPS compliance and workload-dependent speedups, and why a standard like this took nine years to land.

Bringing Aleo and Leo into zkao

We recently brought Leo and Aleo support to zkao, our AI-powered bug-detection tool, and put it to work on a real engagement with HumanityLink. Getting an LLM to audit a young ecosystem like Aleo turned out to be less about the model and more about what we fed it - custom prompts or skills so it actually recognizes Aleo bug patterns, a harness called cheatVM that turns findings into real end-to-end proofs of concept instead of code that just looks right, and a clear threat model that significantly cut down our false positives.

AI meets Cryptography 2: What AI Found in OpenVM's zkVM

We turned zkao (our AI auditor) on OpenVM, a state-of-the-art zkVM, and it found a critical soundness bug: the pairing check accepted a prover-supplied witness without proper subfield checking, which lets a malicious prover forge any pairing equality. It is fixed in OpenVM 1.6.0 and tracked as CVE-2026-46669. This is the second post in our series on bugs our agents found across open source cryptography.

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.

zk.golf: Fearless and Collaborative Optimization of Circuits

zk.golf is a platform where people can compete on creating the most efficient zk circuits for specific problems. It is enabled by what we call “fearless optimization”, which is achieved by combining formal verification and frontier AI models. By the end, you will be convinced that nobody should look at constraints ever again in their life.

zkao 2.0

zkao 2.0 moved billing to pay-as-you-go, with prepaid credits that never expire, and brought a dark theme and redesigned home, repository, and scan pages. Before it, 1.3.0 added an API, a TypeScript SDK, and a command-line tool, and 1.4.0 added scheduled scans. After it, 2.1.0 added the Lacuna and Many Eyes flows and faster triage, and 2.2.0 added audit areas, the Sniper flow, and coverage for Solana and Go.

zk.golf

zk.golf launched with nine challenges: a hello-world byte check, SHA-256, the Keccak-f[1600] permutation, RSA signature verification, secp256k1 scalar multiplication in variable- and fixed-base versions, and SHA-256, BLAKE3, and KangarooTwelve compression over GF(2).

clean

The Verified-zkEVM Lean4 library added a witness-generation IR that compiles witness generation to serializable data, the format zk.golf’s challenges are written against, and moved to Lean 4.32.