Skip to main content

Bidding Process

The bidding process is a critical component of the Succinct Prover Network, enabling provers to compete for proof generation opportunities in a permissionless and economically efficient manner. This page explains the complete bidding workflow implemented in the Bidder binary.

The following flowchart illustrates the bidding process of the Bidder:

Detailed Bidding Process​

1. Continuous Bidding Loop​

The bidder runs in a continuous loop with a 3-second refresh interval (REFRESH_INTERVAL_SEC):

  • The main loop continuously monitors for new proof opportunities
  • Between each iteration, the bidder waits 3 seconds to balance responsiveness with network load
  • Errors in the bidding process are logged and metrics are updated, but don't stop the loop

2. Fetching Biddable Requests​

The bidder first queries for requests it can potentially bid on:

  • Calls GetFilteredProofRequests with filters for:
    • Version compatibility (version)
    • Fulfillment status of Requested (not yet assigned)
    • Minimum deadline of current time (not expired)
    • not_bid_by the current prover (hasn't already bid)
    • Limited to 100 requests per query (REQUEST_LIMIT)
  • If no biddable requests are found, the loop continues to the next iteration

3. Calculating Current Capacity​

After finding biddable requests, the bidder determines its current load:

  • Fetches requests already assigned to the prover
  • Reconciles bids submitted by this process that are still waiting for assignment
  • Resolves each request's expected gas (see the bidder guide for the estimate and fallback rules)
  • Tracks committed expected gas, active wrap requests, and CPU-worker capacity

4. Proof Mode and Capacity Validation​

For each biddable request, the bidder performs several checks:

  • Proof Mode Support: Skips Groth16 or Plonk requests when that mode is disabled; other proof modes remain eligible
  • Completion Time: Estimates completion time from the request's expected gas, committed work, and the cluster's measured sustained throughput
  • CPU Capacity: Checks capacity for the controller task and, for Groth16 or Plonk, the final wrap task
  • Safety Margins: Adds the base safety buffer and the applicable wrap-time estimate
  • Deadline Feasibility: Compares total estimated time against request deadline

5. Parallel Bid Processing​

For requests that pass all checks:

  • Starts an asynchronous bid-submission task for each admitted request
  • Each task handles the complete bid submission process independently and records the result in metrics
  • Waits for all bid tasks before starting the next loop

6. Bid Submission Process​

Each bid task performs these steps:

  • Nonce Retrieval: Gets the current nonce for the prover's address
  • Bid Creation: Creates a BidRequestBody with:
    • Nonce, request ID, bid amount, domain, and prover address
    • Transaction variant set to BidVariant
  • Signing: Cryptographically signs the bid using the prover's private key
  • Network Submission: Sends the signed bid to the network via the bid RPC
  • Metrics Update: Records success or failure metrics for monitoring

7. Error Handling and Metrics​

The bidder maintains comprehensive metrics:

  • biddable_requests: Number of requests available for bidding
  • requests_bid: Successfully submitted bids
  • request_bid_failures: Failed bid attempts
  • total_requests_processed: Overall processing count
  • main_loop_errors: Errors in the main bidding loop

Errors are logged but don't stop the bidding process, ensuring continuous operation.