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:

  • Queries for assigned requests to the current prover with Assigned fulfillment status
  • Counts these as active_proofs to track current capacity usage
  • This count is used to determine if the prover can take on additional work

4. Proof Mode and Capacity Validation​

For each biddable request, the bidder performs several checks:

  • Proof Mode Support: Verifies the request's proof mode (Groth16 or Plonk) is enabled
  • Capacity Check: Ensures active_proofs < max_concurrent_proofs
  • Time Calculation:
    • Calculates effective throughput per proof: throughput_mgas / max_concurrent_proofs
    • Estimates completion time: gas_limit / (1M * effective_throughput)
    • Adds safety buffers: base buffer + mode-specific buffer (Groth16/Plonk)
  • Deadline Feasibility: Compares total estimated time against request deadline

5. Parallel Bid Processing​

For requests that pass all checks:

  • Increments the local active_proofs counter to reserve capacity
  • Spawns an async task for each bid to process them in parallel
  • Each task handles the complete bid submission process independently
  • All bid tasks are awaited together using join_all before the next loop iteration

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.