Zero-Knowledge Proofs in 2026: What Is Actually Production-Ready

In 2024, proving an Ethereum block took minutes and a datacenter. By late 2025, it took seconds on hardware you could fit under a desk. That roughly 45x collapse in proving cost is why zero-knowledge proofs quietly moved from cryptography conferences into Google Wallet and EU identity regulation. This post is the state of the field for architects: which zkVMs are safe to build on, what proving really costs, what works on a phone, and where the security bodies are buried. It pairs with our pragmatic guide to building with ZK and FHE, which covers when to use any of this at all.

Engineering perspective, not a vendor pitch. Vendor benchmarks are labeled as such, and numbers we could not independently confirm are hedged. Reference points come from Wavect's zero-knowledge and web3 work.

What changed between 2024 and 2026?

Three shifts, each of which changes what you should build:

• zkVMs replaced hand-written circuits. You now write ordinary Rust, compile it to a RISC-V target, and the zkVM produces a proof that the program ran correctly. The circuit-DSL era, with its months of specialist work per feature, is ending for general-purpose use cases.
• Proving got roughly 45x cheaper in one year. The Ethereum Foundation set concrete real-time proving targets in July 2025: under 10 seconds for 99 percent of mainnet blocks, on a rig costing at most 100,000 dollars, drawing at most 10 kilowatts, with proofs under 300 KiB and no trusted setup (Ethereum Foundation, July 2025). By the end of 2025, multiple teams were hitting those targets, and the average cost to prove a block on the public ethproofs tracker fell from 1.69 dollars in January to under 4 cents in December (ethproofs.org).
• Big tech shipped ZK identity. Google Wallet verifies "over 18" with a zero-knowledge proof and open-sourced the underlying Longfellow library in July 2025 (google/longfellow-zk). This is the clearest signal yet that ZK left the blockchain niche.

Which zkVM should you build on?

The zkVM is the pragmatic entry point for most teams: normal Rust in, proof out. The field in mid-2026:

Our conservative shortlist is SP1, RISC Zero, and OpenVM, but the choice is workload-specific. A comparative eight-zkVM benchmark published by Fenbushi Capital in August 2025 found those systems among the most robust overall performers, with their GPU provers showing near-constant memory use while several younger zkVMs' proving time and memory grew sharply with input size (Fenbushi Capital). Treat that as one published benchmark, not a neutral certification. Pin an audited release and benchmark your own program before choosing.

How fast and cheap is proving, really?

The numbers that matter for a build decision:

• Latency: real-time proving of Ethereum blocks (10 to 12 seconds for blocks with hundreds of transactions) is demonstrated on rigs of 16 consumer GPUs. Smaller programs prove in seconds on a single GPU.
• Cost: the ethproofs leaderboard reported roughly 4 cents per Ethereum block proof by late 2025, down about 45x from its January snapshot. That is a workload- and pricing-model-specific benchmark, not a universal application-proof price. Verification is usually much cheaper than proving, which enables the prove once, verify everywhere pattern, but actual latency and infrastructure cost still depend on the circuit, wrapper, and verifier.
• Proof size: modern STARK-based systems wrap their proofs in a final Groth16 or PLONK proof for cheap on-chain or on-device verification, landing in the tens-of-KB to sub-KB range. One caveat: that final wrap reintroduces pairing-based cryptography, so if post-quantum resistance is a requirement, stay with the raw hash-based STARK and accept the larger proof.

What this means outside crypto: server-side proving is now practical for more batch workloads whose correctness a third party must trust, such as settlement runs, compliance calculations, or selected ML inference. It does not mean every application proof costs cents. Benchmark the exact program, proof system, hardware, recursion strategy, and required security level before making the business case.

"The 45x cost collapse in one year means the question changed from 'can we afford to prove this' to 'what is worth proving'."

Can you prove things on a phone or in a browser?

Yes, within limits, and this is where the most interesting non-crypto products live:

• Mobile proving. The Mopro toolkit wraps Circom, Halo2, and Noir provers for iOS and Android. Its published benchmarks show large, circuit-dependent gains over browser proving, but also multi-second proofs, verification above 100 milliseconds, and memory failures for some circuits (Mopro benchmarks). Benchmark the exact identity, email, or credential circuit on the target device.
• zkEmail. Prove facts about a DKIM-signed email ("this address received a termination letter from employer X") without revealing the email. Powerful, but note the security section below: its regex component had eleven confirmed constraint bugs found by fuzzing in 2025.
• zkTLS for AI agents. Prove facts about an HTTPS session without the website integrating a new attestation API. The design space is no longer a clean split between MPC projects and proxy projects: TLSNotary itself now offers MPC-TLS as its default and a faster proxy mode with an additional network-path assumption (TLSNotary documentation). Pick the protocol mode from the threat model, bandwidth, server-privacy, and verifier-control requirements.
• ZK passports and personhood. Self, Rarimo, and Anon Aadhaar prove age, nationality, or uniqueness from government documents via NFC chips or signed QR codes. World ID has millions of verified users on Semaphore-based proofs. This category went from demo to deployed apps in about 18 months.

Where is ZK winning outside crypto?

Identity, and the timing is regulatory. Every EU member state must offer a European Digital Identity Wallet by the end of 2026 under eIDAS 2.0, and the framework explicitly favors selective disclosure. Google aimed its open-sourced Longfellow ZK library squarely at this, with age assurance as the first use case (Google, July 2025).

One pragmatic gotcha that most coverage misses: the currently deployed EUDI formats, including ISO mdoc and SD-JWT VC, provide selective disclosure but limited unlinkability. Current official technical work also evaluates BBS-family multi-message signatures and hybrid constructions for higher-assurance credentials. Hardware support, standardization, certification, and national rollout are still moving targets, so a blanket claim that BBS or ZK credentials are either approved or barred across the public sector is not accurate. If you are building EUDI-adjacent products, isolate the credential-format adapter and verify the current national and assurance-level requirements before launch. For the broader landscape of non-crypto applications, see our earlier post on ZK use cases outside crypto.

Is zkML real yet?

Half of it is. Split the term:

• Proof of inference ("this exact model produced this output") is moving beyond small models. Lagrange open-sourced DeepProve in June 2026 and now reports proofs for GPT-2, Gemma 3, and Llama 3 models, including 8B and 70B variants (Lagrange, vendor-reported results). The code and dashboard are meaningful progress, but independent reproduction of latency, cost, model coverage, and security is still limited.
• Private inference via ZK (hiding the input while proving the computation) remains niche and expensive. If input privacy is the goal, FHE or a confidential GPU is usually the better tool; we cover that trade-off in the FHE post and the decision framework.

Llama-class proof generation is no longer only a research roadmap, but it is not yet a commodity production primitive either. Treat current large-model results as vendor-reported until your team reproduces them on the exact model, quantization, hardware, privacy mode, and proof statement you need.

Which language and toolchain should you pick?

The honest default for a product team in 2026: a Rust zkVM for anything general, Noir when proof size or client-side proving forces a custom circuit. The proving overhead of a zkVM versus a hand-tuned circuit is real, but proving costs fell far enough that engineering time now dominates the equation for most applications.

What breaks? The security failure modes.

• Under-constrained circuits are the dominant bug class. A missing constraint means the verifier accepts proofs of false statements, silently. The zkFuzz research tool found 85 bugs, including 59 zero-days with 39 confirmed by developers, across 452 public circuits (arXiv 2504.11961). Budget for both an audit and fuzzing; they catch different bugs.
• Audits are necessary, not sufficient. RISC Zero paid a 50,000 dollar bounty for a soundness bug found after prior audits. In May 2026, reviewers found and fixed a critical verifier soundness bug in alpha-stage Jolt. The same month, a four-year-old soundness flaw in Zcash Orchard required an emergency mitigation and the NU6.2 network upgrade. The takeaway is not that these teams are careless. It is that ZK soundness bugs are unusually hard to see and potentially catastrophic, so version pinning, audits, fuzzing, formal verification, bounties, and incident response all matter.
• Avoid per-application trusted setups. The first documented in-the-wild ZK exploits targeted circuits with mishandled Groth16 trusted setups, not the proof math (zkSecurity, 2025). STARK-family transparent systems make the whole ceremony unnecessary, which is one reason the Ethereum Foundation's real-time proving spec simply bans trusted setups.

Sources and verification

1. OpenVM (2026). OpenVM 2.0 production release, audit status, and benchmarks. openvm.dev
2. ZKsync (2026). ZKsync OS developer-preview status, Airbender integration, and audits. docs.zksync.io
3. European Digital Identity Wallet (2026). Technical specification for ZK proofs from multi-message signatures. github.com/eu-digital-identity-wallet
4. QED (2026). Jolt verifier soundness and tracer completeness disclosures. qedaudit.io
5. Zcash Improvement Proposals (2026). Orchard soundness mitigation and NU6.2 deployment. zips.z.cash