Volume & cost
What triggers each proof: a batch, a block range or a schedule? How often does it run, and what compute costs recur?
For teams running recurring SP1 proofs
ProveIt is an API prototype designed to offload SP1 GPU proving. We want to understand the work around your proof jobs: worker setup, failed runs and upgrades.
Compiled program · input · proof mode
Plonk or Groth16 · RunPod
Proof · public values · verification key
The prototype is designed to accept a compiled SP1 program and its input over HTTP, run a GPU proving job and return the result. Async jobs have a status URL for checking progress and retrieving the result. The payment design uses USDC on Base through x402.
{
"system": "sp1",
"program": "<base64-encoded SP1 ELF>",
"stdin": "<base64-encoded input>",
"mode": "plonk",
"async": true
}Already using your own GPUs or the Succinct Prover Network? Tell us what works and about the last job that needed manual attention. Approximate figures are fine.
What triggers each proof: a batch, a block range or a schedule? How often does it run, and what compute costs recur?
Think of the last delayed or failed proof job. What happened, and who had to step in?
Who maintains the worker setup and handles upgrades? What takes the most engineering time?
Early-stage research prototype for SP1 v5, Plonk and Groth16. Not a production service. No SLA or published prices; speed and cost comparisons have not been measured.
The proving backend and its GPU provider receive your program and input (witness). Use only data you are comfortable sharing with them. For this conversation, a workflow description is enough.
The email opens with four prompts: your SP1 version, workload and frequency, current setup, and last operational issue. A few lines are enough.