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 prover nodes.

The following flowchart illustrates the bidding process of a prover node:

Detailed Bidding Process​

1. Checking for Assigned Requests​

Before a prover looks for new work, it first checks if it already has assigned requests. This prevents the prover from overcommitting resources:

  • The NodeBidder component of the prover node queries its internal state to see if any proof requests have already been assigned to it.
  • If there are assigned requests, the bidder stops the bidding process to focus on fulfilling its existing commitments.
  • Provers must maintain adequate computational resources to complete all assigned proofs by their respective deadlines.

2. Fetching Unassigned Requests​

If the prover has no assigned requests or has available capacity, it then looks for new proof opportunities:

  • The prover calls the GetFilteredProofRequests method to retrieve a list of unassigned proof requests from the auction node.
  • These are requests that have been submitted to the network but haven't yet been assigned to any prover.
  • The auction node returns relevant details about each request, including the program to be proven, deadline, and maximum fee.

3. Filtering Requests​

Not all proof requests are suitable for every prover. The prover filters the available requests based on several criteria:

  • Version Compatibility: The prover checks if it supports the circuit version required by the request.
  • Deadline Feasibility: Requests with deadlines that are too close or already passed are filtered out.
  • Stake Requirements: The prover verifies if it has sufficient stake (collateral) to be eligible for the request.
  • Hardware Requirements: Some proofs may require specific hardware capabilities that the prover must confirm it possesses.

4. Calculating Required Proving Time​

For each potentially viable request, the prover calculates how long it would take to generate the proof:

  • It estimates the computational resources needed based on the program's complexity (proving gas).
  • The prover considers its available hardware resources and current load.
  • It factors in potential overhead for data transfer, setup, and other operations.
  • This calculation is critical for determining whether the prover can meet the deadline.

5. Deadline Evaluation​

With the estimated proving time in hand, the prover evaluates whether it can realistically meet the deadline:

  • It compares the estimated proving time against the time remaining until the deadline.
  • A safety buffer is typically added to account for unexpected delays or complications.
  • If the prover determines it cannot reliably meet the deadline, it will not bid on the request.
  • This evaluation helps prevent slashing events that would occur if a prover fails to deliver on time.

6. Bid Submission​

If all conditions are met, the prover submits a bid to the auction node:

  • The bid includes the prover's identity, the proof request ID, and the proposed fee.
  • The prover's bidding strategy may consider factors like current network conditions, historical data on similar requests, and its cost structure.
  • Bids are cryptographically signed to ensure authenticity.
  • Once submitted, the prover waits for the auction node to determine the winner.