Who this is for: Operators who already walked through the Quick Start guide and have a prover running on Boundless.

Decoding the Boundless auction

Every proof request is a reverse-Dutch auction governed by offer parameters chosen by the requestor. Understanding each field lets you decide whether locking the job is worth your time.

Parameter What it matters to provers
Starting price (A) & Max price (B) Sets the floor/ceiling you’ll earn
Ramp-up period (sec) (C) How quickly the price climbs from start to max.
Lock timeout (sec) (D) Window in which any prover can stake & lock the job.
Expiry timeout (sec) (E) Final deadline to deliver the proof.
Lock stake (USDC) Capital at risk if you lock but miss the deadline.

explorer_order.png

These values come straight from the requestor - you can’t change them, but understanding them lets you decide if a job is worth it.

What your prover does before it bids

Since provers have to stake USDC before being able to lock a proof request, they are incentivized to bid only on proof requests they are sure they can fulfill within the expiry period; otherwise they lose their stake.

When your broker spots an unlocked request it must quickly:

  1. Download the guest program (bandwidth bottleneck).
  2. Execute a preflight to count cycles - this step is CPU-only, so the fastest locker on Boundless is often the operator with the beefiest CPU, not the most GPUs.

Estimating your peak throughput

The first setting in broker.toml that you should change is peak_prove_khz; this represents the total peak proving power (in kHz) of your prover. For example, if a prover can prove 1 kHz, it will be able to prove 1000 cycles a second, 1000 kHz means 1 million cycles a second and so on.

To estimate peak_prove_khz*, the Boundless CLI provides a proving benchmark command:

boundless proving benchmark --rpc-url <RPC-URL> --request-ids <IDS>