Succint is a Decentralized Prover Network for SP1 Proof Requests

A mode or strategy mismatch stops submission

A proof mode or fulfillment strategy that conflicts with the selected network mode prevents the SP1 request from reaching auction.

The mainnet path accepts Auction and rejects Hosted or Reserved strategy. The reserved-capacity path accepts Hosted or Reserved and rejects Auction. Core proof mode is also rejected at network submission; choose Compressed, Groth16, or PLONK. These compatibility checks happen before a prover receives the job, so extending the timeout or adding PROVE does not repair the selection.

A mismatch matters because every later field inherits the chosen route. Mainnet needs auction pricing, a bidder set, and a PROVE-funded requester. Reserved capacity relies on account authorization and its configured service terms. Mixing those inputs produces a deterministic validation failure rather than a pending request that might clear later.

Correct the pair, then resubmit once. Repeating an incompatible combination only reproduces the same validation failure.

Three prerequisites determine whether confirmation can proceed

Three prerequisites decide whether the Succint confirmation view can create a signed, payable, and verifiable request for one SP1 program.

The requester signer

The requester signer uses a secp256k1 private key, the same 256-bit curve family used by Ethereum accounts. Its serialized secret is 32 bytes, normally written as 0x plus 64 hexadecimal characters, while the derived account address is 20 bytes. Foundry and MetaMask can create a compatible account; AWS KMS can hold the signer without placing the secret in an environment variable. The network reads NETWORK_PRIVATE_KEY when a custom signer is absent, and the signature binds the request body to the requester nonce.

The funded program account

The same address needs enough network PROVE credit for the request ceiling. PROVE follows ERC-20 precision with 18 decimal places, but the relevant amount is the indexed network balance, not merely the wallet balance on Ethereum. A new deposit can take up to 5 minutes to appear. The requester also needs an SP1 program and proving key produced with sp1-sdk v6.1.0 or later. On the first request for a given ELF and proving-key pair, the client registers that program automatically and derives its verification-key hash.

Seven selectable paths carry different verification boundaries

Seven selectable request paths differ in output form, allocation route, and the verification or access boundary applied after confirmation.

The four proof modes answer an artifact question, while the three fulfillment strategies answer an allocation question. Compressed suits off-chain checking or recursive use inside SP1. Groth16 and PLONK target EVM verification, including Ethereum contracts. Auction belongs with mainnet; Hosted and Reserved belong with reserved network mode. The confirmation view should never present those two dimensions as interchangeable.

Groth16 produces an approximately 260-byte proof with on-chain verification around 270,000 gas, while PLONK produces roughly 868 bytes and verifies around 300,000 gas. Groth16 uses circuit keys derived from ceremony contributions. PLONK avoids a circuit-specific trusted setup, although it still uses universal ceremony material. Proof size and verifier assumptions therefore decide the mode; the auction does not transform one artifact type into another.

Local simulation supplies the execution limits

Local SP1 simulation measures the program before submission, supplying cycle count, PGUs, and a public-values digest for the signed request.

With simulation enabled, the SDK executes the ELF and input without generating the final proof. It uses total instructions for the cycle limit and measured prover gas for the gas limit. If simulation is skipped and neither limit is supplied, the mainnet implementation falls back to 1,000,000,000,000 cycles and 1,000,000,000 PGUs. The network rejects any gas limit above 1,000,000,000,000 PGUs, and it rejects a deadline later than 24 hours after submission.

Skipping simulation also removes early execution checking; an unexecutable program reaches the network before its failure becomes visible.

Auction terms turn PGUs into a bounded PROVE cost

Auction settings convert measured PGUs into a payment ceiling and define how long provers have to discover the mainnet request.

The final charge follows one mechanism: base fee plus actual PGUs multiplied by the clearing price per PGU. The base fee reflects proof mode, while bids set the per-PGU component. Before confirmation, compare the network balance with the maximum exposure implied by the gas limit and maximum price, not with a recent fulfilled request. That fulfilled price is historical. A low cap leaves the request without bids; a high gas limit enlarges the possible deduction even when the program later consumes less gas.

The SDK applies a 120% cap buffer - 1.20 times the market signal, or 20% headroom - when no explicit maximum price is supplied. A value below 100% underbids that signal, and an explicit maximum overrides the buffer. The client-side auction timeout defaults to 30 seconds. A deliberate minimum auction period of 10 to 15 seconds gives more eligible provers time to bid, provided the application tolerates that discovery interval.

Confirmation creates a signed request and two identifiers

Confirmation changes local configuration into a signed network record with a transaction hash and a 32-byte request ID for later polling.

The client first ensures that the program exists, then serializes and uploads the SP1 input. It fetches the requester nonce and assembles the circuit version, verification-key hash, proof mode, strategy, input location, deadline, cycle limit, gas limit, whitelist, auction roles, fee fields, and public-values hash. The secp256k1 signer authenticates that body, and the RPC response returns both identifiers. This state change places an Auction request into the network queue; it does not mean that a prover has accepted the work.

Store both identifiers immediately. Each is 32 bytes, commonly displayed as 0x plus 64 hexadecimal characters, but the request ID is the stable key for status, cancellation, details, and proof retrieval. The transaction hash connects submission to the network record.

Three fulfillment states expose the proof lifecycle

Three fulfillment states show whether the auction is waiting, proving has started, or a downloadable proof has reached the requester.

Requested

Requested means the signed job exists but no prover owns it yet. Auction timing applies here, and the SDK starts its client-side cancellation clock when polling first observes this state. Unfulfillable and Unexecutable are terminal failure exits rather than progress.

Assigned

Assigned means the auction selected a fulfiller and the proving deadline now governs completion. The SDK records that transition once and continues polling every 2 seconds. Raising the auction timeout after assignment has no effect because bidder discovery has ended.

Fulfilled

Fulfilled means the status response includes a proof location. The client downloads the artifact, deserializes the SP1 proof with its public values and version, and returns it to the requester. A late poll still returns an already fulfilled proof before checking the deadline, which preserves a valid completion even when the observer resumes after the cutoff.

Verification binds fulfillment to the intended execution

Verification accepts fulfillment only when the proof, SP1 verification key, public values, version, and expected execution status agree with the request.

SDK verification

For Core, Compressed, Groth16, and PLONK objects produced locally, the SP1 SDK exposes the matching verifier path. Network retrieval adds the public values and SP1 version to the proof bundle. Use the verification key from the same program setup that produced the request hash; substituting another key changes the statement being checked. A successful Fulfilled status confirms delivery, while cryptographic verification confirms the artifact.

EVM verification

Groth16 and PLONK proofs target on-chain verification through the corresponding SP1 verifier contract. The calling contract supplies the correct program verification-key commitment, public values, and proof bytes. Groth16 and PLONK use different encodings and verifier assumptions, so the proof mode selected before confirmation must match the deployed verifier path. Ethereum transaction success then proves that the contract accepted that exact statement.

Cancellation recovers an auction without an assignment

Cancellation recovers a mainnet auction that remains Requested beyond its auction timeout and clears the workflow for a fresh attempt.

The synchronous wait path uses a 30-second auction timeout unless the requester overrides it. If Requested persists beyond that interval, the client sends a cancellation and returns an auction-timeout error. An asynchronous worker can also cancel explicitly with the stored request ID. Cancellation belongs to Mainnet Auction mode; reserved-capacity requests follow their configured service path.

After cancellation, review the maximum price, bidder whitelist, minimum auction period, gas limit, and proof deadline before resubmitting. A second request receives a new nonce and request ID. Once a job reaches Assigned, the proof deadline controls recovery instead of the auction timer.

A malformed requester key has a narrow repair path

A malformed requester key fails before payment, and repair consists of restoring the exact Ethereum-compatible encoding expected by the SP1 client.

The environment value should begin with 0x and contain 64 hexadecimal characters after that prefix, representing 32 bytes. Do not trim leading zeroes. Remove surrounding quotation marks or whitespace introduced by a shell profile, then derive the address and compare it with the funded requester account. A valid key for a different address passes format parsing but exposes that other account’s network balance.

If the value remains invalid, export it again from MetaMask, generate a fresh key with Foundry, or configure a NetworkSigner backed by AWS KMS. Update NETWORK_PRIVATE_KEY only for the process that submits requests, restart that process, and recheck the derived 20-byte address before sending the same SP1 configuration.

The request record makes later verification reproducible

The final request record gives operators enough evidence to reproduce a submission without rebuilding it from memory. Keep the request ID, transaction hash, verification-key hash, circuit version, proof mode, fulfillment strategy, creation time, deadline, cycle limit, gas limit, gas used, fulfiller, fulfillment state, deduction, and refund fields together. Within Succint, that record separates configuration from execution: the signed values explain what was requested, status transitions explain what happened, and the downloaded proof supplies the object that SP1 or an EVM verifier checks.