Tune parameters with an AI in the loop.
The optimizer proposes a parameter set with reasoning, runs a backtest, reads the report, reasons about why it under- or over-performed, and proposes the next set. Repeat. The whole search trajectory is logged.
Synthetic replay only. Not a forecast.
The optimizer searches against the same synthetic CLOB V2 backtest used elsewhere in this guide. It does not see live markets, live order books, real PnL or real fills. Numbers it produces are a measurement of behaviour against synthetic data, not a prediction of real-world performance.
Locked from optimization — hard safety gates
The following parameters are refused by the optimizer. They are not search dimensions. Tuning them would mean tuning the safety floor of the system, which is set by policy, not by a search.
risk.killswitch.*— trip thresholds, cooldown, force-trip flagsrisk.exposureguard.*—maxNotionalPusd, per-market capsrisk.compliancegate.*— jurisdiction allowlists, builder allowlistsrisk.markethaltguard.*— halt sources, halt-on-stale windowsec.signer.*— signer policy, EIP-712 v2 fields
If the optimizer is asked to search any of these, it returns an OPT_REFUSED_HARD_GATE error and the run is rejected before it starts. Change them in config, with a code review and an envelope, not in a search.
Score per iteration
Search trajectory
| # | Score | Params | Reasoning |
|---|
Best parameters found
—
- Random search — N draws from the search space, pick the best. The honest baseline; tells you whether anything else is doing real work.
- Bayesian (TPE) — kernel-density estimate over good-vs-bad regions. No LLM, no key, no cost.
- LLM-driven — the model reads each backtest's ReportEnvelope summary and proposes the next parameter set with a reason. It can also explain why the best run is the best.