The Boundless Prover Playbook
Sasha Aldrick
.png%3Ftable%3Dblock%26cache%3Dv2%26id%3D239051eb-c1b5-807c-9f20-f53c5086b8b8&w=1920&q=85)
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. |
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:
- Download the guest program (bandwidth bottleneck).
- 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>You can find a recent request ID by heading over to the Boundless Explorer and copying this value:
.png?table=block&id=239051eb-c1b5-80ea-b7a7-fbb032a16445&cache=v2)
Once you run the command, you should see something like:
.png?table=block&id=239051eb-c1b5-80eb-aae1-f6f01be90070&cache=v2)
Please note: This is just an estimate. As the CLI suggests, when starting out, it is recommended to set a lower value than the benchmark result, and slowly increase the value over time to increase proving capacity.
Pricing a proof: mcycle_price
mcycle_price represents the price of proving 1 million cycles. The Explorer Stats Page shows the historical trendline for the average ETH per megacycle - keep your value close to that trendline to win a healthy share of orders without under-pricing your work.
.png?table=block&id=239051eb-c1b5-8011-b119-e52035864a17&cache=v2)
Parameters you should tune
Field (broker.toml) | Details | How to tune |
lockin_priority_gas | Extra gas appended to the lock transaction. A higher value pushes your tx toward the front of the mempool, letting you beat slower provers to latency-sensitive requests. Caution: burning through gas at every lock drains your native-token balance quickly. | Raise to win latency-sensitive auctions; lower to conserve your token balance. |
min_deadline | Minimum number of blocks before expiry at which the broker will still lock a request. Setting it lower lets you capture jobs that other provers deem too close to the deadline, but the slash risk spikes if your proof overruns. | Start conservatively. Gradually decrease as you gain confidence in your end-to-end prove time. |
max_stake | Hard cap on the USDC you are willing to stake for any single request. | Align with your available balance and risk tolerance. |
max_file_size | Upper limit (bytes) for guest programs the broker will download before pre-flight. Larger binaries demand more bandwidth and usually translate to more cycles. | You can calculate a rough estimate of your download speed using a CLI speedtest and divide the total by 8 to get “MB/s” (megabytes per second). This will give you a rough idea of your peak download speed, at which point, you decide what is best when it comes to max_file_size and your desired latency before locking. |
These knobs don’t have universal “best” values. Optimal settings depend on your CPU/GPU horsepower, internet speed, and real-time market dynamics. To see all the values you can change, please see the broker.toml template file. Trial and error will be required to optimize your proving setup.
For any questions, please join the Discord and claim the “Prover” role from Guild.xyz.
