Skip to main content

Proof Lifecycle

We describe how a proof moves from request to final settlement within the Succinct Network:

1.Fees and Deposits​

  • A requester deposits enough fees (in USDC) into the network to cover proof costs.
  • Provers deposit collateral (stake) to participate in proof contests.

2. Request Submission​

  • The requester sends a proof request (containing their program, inputs, maximum cycle count, fee, and deadline, and the mode of the proof request) to the auction node via the sp1_sdk::ProverClient.

3. Prover Selection​

  • The auction node announces the new request.
  • There are three modes of proof generation: hosted, reserved, and contest.
  • In hosted mode, the auction node selects a prover from a whitelisted set of provers.
  • In reserved mode, a preselected prover is assigned to the request.
  • In contest mode, provers bid from their collateral to secure the right to generate the proof.
  • The highest bidder (or top bidders, depending on the protocol’s configuration) is selected.

4. Proof Generation​

  • The winning prover runs the requested program with the given inputs to produce a zero-knowledge proof.
  • Proof data is streamed to the DA layer.

5. Proof Submission and Verification​

  • On-chain verifiers checks the proof’s validity.
  • The fee is released to the prover upon successful verification.

6. Settlement​

  • Provers accumulate earned fees.
  • Requesters can monitor and use the proof in their desired application.
  • If a prover fails to generate a valid proof by the deadline, the protocol slashes their collateral according to the network’s slashing conditions.

Through this lifecycle, the Succinct Prover Network provides an end-to-end solution for generating and verifying zero-knowledge proofs. It aligns incentives between requesters (who need proofs) and provers (who generate them), ensuring timely, decentralized, and reliable service.

Note: Further technical specifications, including details on how provers handle requests internally, how the off-chain node architecture is designed, and additional component interactions, will be released in future iterations of this documentation.