How the Engines Are Tested

Every execution engine on this site went through the same gauntlet before any connected wallet could arm it. This page describes that discipline plainly — what is tested, how, and just as importantly, what testing does not promise.

Staged drills, not just unit tests

Each engine ships with a scripted, multi-stage drill — lettered stages covering launch, fills, partial fills, pause, cancel, restart, and shutdown. Drills run against the live production database with a scripted venue layer, so they exercise the real storage, the real state machine, and the real settlement logic rather than a mock of our own assumptions. A drill passes only when every stage passes, and the result is recorded per engine, per change.

Crash recovery is proven, not assumed

Engines are built restart-safe: every order carries a deterministic client order ID, intent is journaled before anything is sent, and on restart the engine reconciles against the venue by those IDs — adopting orders it can prove are its own and refusing to guess about the rest. Drills kill the process mid-flight and verify the engine picks up exactly where it left off. An order whose fate cannot be established is treated as failed and is never blindly re-sent.

Incidents become permanent tests

When something goes wrong in live operation, the exact sequence of events is captured and turned into a standing drill stage. Failure modes discovered in production — a venue batch error that masked a real fill, a rejected sub-minimum order, a mispriced stop comparison — are each replayed as part of the drill suite from then on, so a fixed fault cannot silently return.

Failure paths are drilled deliberately

The drills spend most of their stages on the unhappy paths: kill-switch flips, dead-man cancel sweeps, exhausted rate budgets, venue rejections (distinguishing business refusals from transport failures), thin books where child orders cannot fill, and size-rounding corners where an order would land under the venue minimum. Monitoring logic is drilled with injected prices against real stored state — read-only, with no orders placed — to verify that stops and exits fire at exactly the levels written on the ticket.

Continuous reconciliation

While a position is open, the engine's own signed journal is compared against the venue's reported positions on a short cycle. If the two disagree — for example, a leg closed directly on Hyperliquid outside this interface — the discrepancy is flagged on the position within moments, never papered over. Positions can only be created from actual fills, in a single transaction, so a position without fill evidence cannot exist by construction.

The last gate is a live trade

No engine is opened to users on drill evidence alone. Each one finishes with a small live order on Hyperliquid mainnet, placed with the operator's own funds, before the arm path is enabled for anyone else. The resulting fills — including slippage measured against arrival price — are journaled like any other order.

Verify it yourself

The fill quality page publishes the outcome of every completed parent order — successes and failures alike, with failure reasons shown verbatim. Nothing there is filtered or selected. Past fill quality is evidence of how the engines have behaved, not a prediction of future results.