Market-making bot risk controls: what to verify before Start
Ask for evidence of permissions, exposure limits and failure handling, not just a profitable chart. This checklist describes what to evaluate in any bot; it is not a certification that every Vesper mode implements every item.
Separate account access from trading risk
Use only the permissions required by the documented integration. A key that cannot withdraw can still place losing trades, accumulate exposure or incur fees. Keeping funds in your own venue account is not protection against every venue or execution failure.
Review the account or subaccount being connected, the authority being granted and the documented revocation process. Never publish a secret key in a support ticket, screenshot or performance report. Understand whether other bots or manual orders share that same account.
For a venue-specific example of delegated signing, see Hyperliquid's API-wallet documentation. Do not assume those permissions or nonce rules apply unchanged to another venue.
Define exposure limits in units you can inspect
Record the instrument, clip notional, maximum position, leverage and margin mode. A small clip does not establish a small maximum inventory if repeated fills can accumulate. A percentage needs a denominator: equity, available balance and position notional are different quantities.
Ask what happens after partial fills, when the book becomes one-sided, and when an order acknowledgement is delayed. The venue's fills and positions should be reconciled with the application's state rather than inferred only from a submitted request.
Controls should be understood before the first live order, not discovered during an adverse move. The inventory-risk guide explains why position direction and holding time belong next to spread statistics.
Verify exit semantics, including reduce-only
A reduce-only instruction is intended to prevent an exit from increasing exposure; it does not guarantee a fill, acceptance or an execution price. Confirm the venue's semantics, side, size and handling of partial fills. A stale order reference is not proof that a protective order remains live.
Ask how rejected exits, disconnected streams, rate limits and stale market data are surfaced. Does the system stop adding risk? How does it reconcile after connectivity returns? A green process indicator is not a substitute for account-state evidence.
Do not infer a universal safe timeout from this checklist. The correct incident procedure depends on the market, venue and mode. Read the actual guide and understand how to inspect open orders and positions independently.
Stop should have an observable outcome
Distinguish stopping new entries, cancelling outstanding orders and closing inventory. These are different actions. A process that has stopped running can leave both orders and positions behind, depending on the system's design and the last accepted venue actions.
Before running a bot, establish which action the Stop control performs, how progress is shown and how failures are reported. If your intended outcome is flat and orderless, verify both conditions at the venue; a single local status label is not sufficient evidence.
For Vesper, consult the selected mode's instructions. Do not generalise a behaviour from another strategy or assume a product comparison is an operational runbook. Avoid issuing conflicting manual or automated actions while an exit is in progress.
Ask what a restart restores
A useful acceptance test checks whether a running session recovers its intended state, whether fills replay without double-counting, and whether an intentionally stopped session remains stopped. Ask for the documented behaviour of the exact version, not a general statement that restarts are supported.
Session identity, cumulative turnover and fees should be distinguishable from a new run. A reconnect must not turn replayed events into new trading activity. Keep the source of truth clear when the application and venue temporarily disagree.
These are evaluation requirements, not a claim that this page has tested every product or Vesper mode against them. Recovery tests belong in an isolated environment before any authorised live trial.
Use an evidence checklist instead of a safety badge
A good report includes the strategy version, market, time window, fills, net PnL, open inventory, fees and exceptional events. Compare similar conditions. A screenshot with large turnover but no drawdown or endpoint inventory leaves out material information.
The CPM methodology explains cost normalisation; the bot comparison helps separate operating models. Neither establishes that a strategy is suitable for your capital or risk tolerance.
All live trading can lose money, and leveraged losses can be rapid. No combination of checks guarantees that a software, network or venue failure cannot occur.
| Check | Evidence to ask for |
|---|---|
| Permissions | Exact granted authority and revocation procedure |
| Exposure | Configured limits and independently observed positions |
| Exits | Accepted order state, partial-fill handling and failure reporting |
| Stop | Documented action and verified final account state |
| Restart | Session continuity, deduplication and stopped-state behaviour |
| Economics | Complete fills, costs, inventory and observation window |
Questions
Does a trade-only key make a bot safe?
It limits account authority but does not prevent trading losses, unwanted exposure or fees. Verify both permissions and trading behaviour.
Does reduce-only guarantee an exit?
No. It constrains exposure according to venue rules, but an order can still be rejected, cancelled or unfilled.
Is STOPPED proof that the account is flat?
Not on its own. Understand the product's Stop semantics and independently verify positions and open orders when flat and orderless is the intended outcome.
Is this a certification of Vesper's controls?
No. This is a general evaluation checklist. Check the exact strategy guide, implementation version and supporting acceptance evidence.