“Algorithmic trading” can mean anything from a spreadsheet that checks a rule to software that routes orders and reconciles fills. The label does not tell you which one is running. Before evaluating a bot or building a prototype, trace what happens between a market observation and a confirmed position.
Separate research from order execution
Start with the research specification: market and instrument, data source, timeframe, inputs available at each decision, entry and exit conditions, position-sizing rule, cost assumptions, benchmark and a condition that would make the test inconclusive. Version the specification and dataset. A backtest should leave a ledger that another person can inspect, including signals that did not become fills under the model.
Then keep three operating states distinct:
| State | What it can establish | What it does not establish |
|---|---|---|
| Historical simulation | How stated rules behave on the chosen historical data and fill assumptions | That the data are complete or future results will resemble the sample |
| Paper observation | How a process records hypothetical decisions over the observation period | That orders can reach a venue or receive the modeled fill |
| Live order pathway | What authenticated venue acknowledgments, fills, fees and account records show | That a strategy has a durable edge or is suitable for a particular person |
A successful software test covers only the behavior it exercised. It does not verify an exchange account, an API permission, a production secret store or an actual order.
Design the control boundary before the strategy
If a system can submit real orders, treat its operating path as a separate engineering problem. Check data freshness and instrument identity before using a signal. Apply maximum order, exposure and loss limits before sending a request. Persist a unique decision and client-order reference before transmission where the venue supports one. That reference helps query and reconcile an uncertain request; it does not make duplicate submissions safe across every venue. After a response, reconcile the order and position state with venue records; a successful HTTP request is not the same as a fill.
Define what the system does when any part is uncertain. A stale price, malformed quantity, rejected order, partial fill, connection loss or unknown position should stop new risk-taking until state is rechecked. A kill switch should have a clearly tested effect, an owner and a recovery procedure. A stop order itself does not guarantee an execution price or prevent liquidation under a venue’s rules.
The SEC’s Rule 15c3-5 guide describes market-access risk controls for covered broker-dealers in U.S. securities markets, including pre-order thresholds and regular review. That rule is not a general checklist imposed on every retail crypto script, and it is not a statement of crypto law in every jurisdiction. Its limited scope is a useful example of how market-access controls can be assigned and documented; anyone building or operating a system must separately identify the rules that actually apply to them.
Walk through a failure, not just the happy path
Imagine a strategy process submits an order and the network times out before the response arrives. The request may have reached the matching engine even when the client sees no answer. Binance’s Spot REST documentation explicitly labels one timeout and some server errors as execution-status unknown and advises checking the user stream or querying order status. Hyperliquid documents client order IDs and an order-status query by order ID or client ID. These are venue-specific tools, not a universal exactly-once guarantee; use the venue’s current contract and do not send a second order simply because the first response was lost. See the Binance Spot REST API guidance, Hyperliquid exchange endpoint and Hyperliquid order-status query.
Use a small reconciliation protocol and record the evidence behind every state change:
| Situation | Check against venue evidence | Operating decision |
|---|---|---|
| Request times out or returns an ambiguous server error | Query using the original client ID where supported; inspect order status and fills | Keep the decision unresolved; do not retry as a new order while exposure is unknown |
| Order is partially filled or a cancel is pending | Sum individual fills, fees and remaining open quantity; then recheck after cancellation | Size any next action from reconciled exposure, not the requested quantity |
| Process or private stream reconnects | Refresh open orders, positions and recent fills; resume event processing only after state agrees | Pause new risk if a gap cannot be reconciled |
| Venue returns a rate-limit response | Follow that venue’s backoff instruction and inspect current order/account state | Stop rapid retries; repeated requests can extend the outage |
For example, Binance’s Spot REST guide says its 429 response means a rate limit was exceeded, requires the client to back off, and warns continued violations can lead to an IP ban. This is Binance Spot behavior, not a promise that another API uses the same codes. Hyperliquid’s exchange documentation defines its own time-in-force choices: ALO cancels rather than immediately taking liquidity, while IOC cancels the unfilled remainder. Those rules affect order outcomes, so the same strategy intent can leave different inventory under different venue instructions. Document the exact venue, product, API version and order flags used in a rehearsal.
Before treating an execution controller as ready for any deployment, exercise those failure cases deliberately in a non-production environment. Inject a stale quote, a lost response after acceptance, a partial execution during cancel, a private-stream disconnect and a rate-limit response. For each case, verify that the system neither increases exposure from an unknown state nor loses track of its remaining quantity, and that an operator can stop, inspect and resume it from recorded evidence. A happy-path paper session alone does not test recovery.
For a futures or leveraged instrument, the control boundary also meets account risk: the CFTC’s virtual-currency futures advisory notes that leverage can amplify losses and trigger additional margin or position closure in the futures context it discusses.
SuperQuant’s actual boundary
SuperQuant provides a local historical research engine and a manual paper-practice workflow using synthetic bundled histories. It does not submit exchange orders or connect to a user’s trading account. Do not describe it as an auto-trading bot. To study the research side, start with the trend-following example, follow the backtest workflow, and compare discretionary and systematic trading. This is an architecture guide, not live-execution advice or a strategy recommendation.