Written by TACEO
on April 30, 2025

Introducing TACEO:Proof

TACEO:Proof is live for beta testing. We're inviting interested developers and potential node operators to get in touch to participate in this development stage of our prover network. Right now, the network is producing Groth16 proofs, support for additional proof systems will follow in later phases. This blog post serves as an introduction to the TACEO:Proof network.

A Dedicated Network for Fast & Private ZK Proof Generation

Decentralized exchanges pause for on-chain swaps while a browser spins through proof generation. zkTLS clients stall during private handshake proofs. Social feeds freeze when users submit zero-knowledge attestations. In each case, the core ZK circuit works, but on-device proving turns seconds into minutes, and user sessions time out or crash.

Most teams work around this by offloading proofs to centralized endpoints, exposing secret inputs to a third party and reintroduce trust assumptions. Hardware enclaves shift the risk into proprietary chips. Fully homomorphic schemes remain orders of magnitude slower. What these workarounds share is a hidden cost: they trade away either performance, privacy, or trust.

TACEO:Proof takes a different path. It offloads ZK proof generation into a distributed coSNARK subnet, so your front end submits encrypted inputs and quickly receives a succinct proof—no client-side delays, no single trusted prover.

Shifting Proof Generation Off the Client

From UI “freeze” to one network call. Before, your app shipped a full prover to every browser or phone. It ran millions of field multiplications in WASM or native code.

Now it bundles your circuit description and secret inputs into a compact payload, sends it once to TACEO:Proof, and quickly gets back a valid ZK proof. The client never runs the heavy math.

At its core, TACEO:Proof executes each proof workflow across a committee of three nodes. These nodes collaborate to keep your inputs hidden, run the full SNARK proving algorithm, and assemble a single, succinct proof. No individual server ever sees the complete data; together, they reconstitute exactly the same proof you would have generated locally.

High-Level Overview

On the client side

On the client side, two integration patterns are supported:

Client-side witness extension Your application first compiles the full circuit witness locally then secret-shares that witness into three cryptographic shares. Each share is encrypted under its designated node’s public key and sent to TACEO:Proof. When the network completes the MPC + coSNARK run, you receive back a Groth16 proof.
MPC witness extension To minimize client work, you can skip local witness generation and instead secret-share only the raw inputs. The three-node subnet extends the witness inside MPC, runs the proving circuit, and returns the final proof. From your perspective the integration is identical—just a single prove call, but as the witness extension is done in MPC, the process will be slower.

On the TACEO:Proof side

The Cryptographic Coordination Layer (CCL) receives your encrypted inputs and a voucher authorizing the job. It assigns the job to a specific three-node cluster, publishes the work order, then gathers status updates and the final proof.
Node Provider Service (NPS): Each of the three selected providers runs an NPS instance. It listens for jobs on its queue, selects one of its local coSNARK Engines (CSEs), and oversees local resource management.
coSNARK Engine (CSE): The CSE is where the proof actually happens. Three CSEs connect peer-to-peer over QUIC. They exchange secret shares, cooperatively compute each gate of the circuit, and jointly produce a Groth16 proof without revealing individual inputs.
CSE report the final proof back to the NPS, who signs the result, and this then gets forwarded to the CCL for delivery to the client.

Developers see only a single RPC:

taceo_proof_client::schedule_full_job(
                config,
                voucher,
                circuit_id,
                private_inputs,
                public_inputs,
            )

Early Benchmarks

We ran some tests on circuits of different sizes to see how the coSNARK network performs when generating proofs. The chart below shows the time taken to generate Groth16 proofs across a range of constraint sizes from $2^{14}$ to $2^{22}$. Many circuits used by leading ZK applications fall around the $2^{16}$-constraint range and hence can achieve sub-second proving times.

Groth16 performance on TACEO:Proof

Note, these timings capture proof generation, without the end-to-end client flow.

What's Coming Next

Over the summer, we plan to bring the TACEO:Proof network out of beta and into production. It's a quick timeline, that's why this phase is crucial to get feedback, if you have some please reach out. Beyond that, we plan to launch an open DevNet with invitation codes to ease the flow on onboarding for everyone. Beyond this, we continue working hard on performance optimizations for witness extension, and developer experience improvements. We have no comment right now about additional subnets 👀

Get involved! We'd be thrilled to have ZK App developers and node operators to try out the beta network. If you'd like to use it or to help running it, register your interest via this form. We look forward to hearing from you.

If you’re generally interested ZK and want to explore coSNARKs further, join us on Discord, follow our updates on X, or subscribe to our newsletter.

Top