IPTF
testnet hybrid I2I + I2U

Delegated Proving (co-SNARKs)

Offload zero-knowledge proof generation to a distributed prover network without revealing the witness. The user secret-shares their witness across several proving nodes; the nodes jointly run an MPC protocol to compute a single SNARK proof; no individual node ever reconstructs the full witness. The resulting proof is identical to one produced client-side and is verified on-chain or off-chain with no changes on the verifier side.

CR
Medium
Censorship Resistance
O
Yes
Open Source
P
Full
Privacy
S
Medium
Security
CROPS context
Censorship Resistance
Reaches high when the prover network is permissionless and bond-backed with slashing for Byzantine behaviour. Drops to low when a single proving service controls the pipeline.
Open Source
Proving-framework implementations are published under permissive licenses; production deployments may bundle proprietary orchestration.
Privacy
The witness stays hidden from each individual prover and from the verifier. Metadata about who requested a proof, when, and against which circuit can still leak.
Security
Rides on the soundness of the underlying SNARK and the honest-majority assumption of the MPC protocol. Trusted-setup requirements inherit from the SNARK (Groth16 needs per-circuit setup; PLONK/KZG uses universal setup).
I2I
Between institutions, delegated proving is typically contracted between known parties with SLAs and legal recourse. The prover set can be small and stable. Honest-majority risk is mitigated by bilateral agreements and audit logs.
I2U
For users, the prover set must be permissionless or at least operator-diverse so that no coalition can recover the witness. Economic bonding with slashing and publicly auditable proving logs protect against collusion. A user has no recourse if the prover set silently leaks their witness.
Works best when
A user or institution lacks the compute, memory, or battery to generate a zero-knowledge proof client-side and wants to offload the work without disclosing the witness.
The delegatee set can be run by independent operators so no single party sees the full witness.
Avoid when
Client-side proving is feasible and low-latency is critical.
Only one proving node is available (no honest-majority distribution possible); use a TEE-based prover instead.
Intent

Offload zero-knowledge proof generation to a distributed prover network without revealing the witness. The user secret-shares their witness across several proving nodes; the nodes jointly run an MPC protocol to compute a single SNARK proof; no individual node ever reconstructs the full witness. The resulting proof is identical to one produced client-side and is verified on-chain or off-chain with no changes on the verifier side.

This pattern covers delegated proving for a single prover's witness. For multi-party joint computation over shared secret inputs (e.g. a consortium ledger), see pattern-private-shared-state-cosnark.

Components
  • User or application holds the witness and wants a proof generated without exposing the witness.
  • Share-distribution layer splits the witness using secret-sharing (additive or Shamir) and routes shares to proving nodes.
  • Distributed prover network runs the MPC protocol to jointly compute the SNARK. Each node sees only its share.
  • Coordinator sequences MPC rounds and assembles the final proof. Can be one of the proving nodes or a separate role.
  • Verifier checks the final proof exactly as it would check a client-side SNARK. No changes on the verification side.
Protocol
1
[user] Secret-share the witness across N proving nodes.
2
[prover] Proving nodes jointly execute the co-SNARK MPC protocol, exchanging shares across multiple rounds to compute witness polynomials and commitments.
3
[prover] The coordinator assembles the final proof from the MPC output.
4
[user] Receive the assembled proof from the coordinator.
5
[contract] A verifier contract (or off-chain verifier) checks the proof against the public statement.
Guarantees & threat model

Guarantees:

  • The witness stays hidden from every individual prover and from the verifier.
  • Verification cost is identical to a client-side SNARK for the same circuit.
  • Preserves trade secrets, user balances, or model weights under honest-majority assumptions.

Threat model:

  • Soundness of the underlying SNARK, including any trusted-setup ceremony.
  • Honest-majority assumption across proving nodes. A colluding majority can recover the witness and, in some constructions, forge proofs.
  • Non-censoring coordinator. A malicious coordinator can refuse to finalize or selectively drop requests.
  • Authenticated and confidential channels between nodes. Metadata about participation and timing is out of scope.
Trade-offs
  • Heavy communication overhead. Round count and bandwidth scale with both the number of provers and circuit size.
  • New infrastructure requirements: MPC nodes, share routing, key management.
  • Liveness depends on all designated nodes remaining online through the proving session. Dropouts typically force a restart.
  • Latency is higher than client-side proving because of MPC round trips; not suitable for sub-second proving budgets.
Post-quantum
high risk
Vector: Pairing-based SNARKs (Groth16, PLONK/KZG) broken by CRQC. MPC communication inherits the underlying key-exchange assumptions.
Mitigation: co-STARK alternatives with hash-based commitments. See Post-Quantum Threats.
Example
  • A user holds a shielded balance and wants to prove a spend on a mobile device. The wallet secret-shares the spending witness across three independent proving operators. The operators jointly produce a Groth16 proof. None of them sees the balance or the spend amount. The user submits the proof to the shielded pool contract.
Open-source implementations
co-SNARK proving framework supporting Groth16 and PLONK (research/testnet)
Rust