How the Engines Are Tested
Every engine on this site is a mechanical executor. It forwards the orders you arm, on the parameters you set, and it cannot choose to do anything else. This page describes how that claim is tested — what is drilled, what is proven, and what testing does not promise.
Every execution engine went through the same gauntlet before any connected wallet could arm it.
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.
The drill that proves the engine won't improvise
Every engine is tested against scenarios where it could — in principle — deviate from the parameters you set: a market that gaps 20% away mid-order, a rejected child, a venue transport failure. A standing deviation drill runs the engine through each temptation and checks every single order the scripted venue ever saw against the parent's own terms: same market, same direction, size never beyond what you committed, price never beyond your cap, and every order id derived deterministically from your parent — an order the drill cannot trace back to your parameters fails the suite. In every scenario the drilled and required behaviour is the same: the engine does not substitute its own judgment. It works what you armed inside your caps, retries what the venue refused, and when it cannot proceed it pauses and goes silent — a paused parent producing any further venue action is itself a failure. This is the test that makes “it never decides” a description rather than a claim.
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 agent cannot move funds — and that's checked too
The order-only agent your wallet approves can submit orders for your account. It cannot withdraw, transfer, or alter your positions except by placing orders. That limit is Hyperliquid's own permission model — structural, not a policy of ours — and the engine never asks for anything beyond it. On every restart, the engine re-verifies each active agent against the venue's own agent registry: an agent the venue no longer lists is marked revoked on the spot, the engine refuses to sign for that account, and an alert is raised. The agent is never used to collect fees.
What the engine never has
The engine never holds your seed phrase, your wallet's signing key, or any credential that can move funds. It holds the limited agent credential, encrypted at rest, with a decryption key that lives only in the worker's deploy environment — decrypted just-in-time into the signing client, never logged, and dead the moment you revoke it or it expires. This is an architectural fact, not a policy. If the encrypted store were compromised on its own, the attacker would hold ciphertext, not a key — and even the live credential can only place orders, never withdraw.
Fee journaling and rebates are drilled like any engine
Every construction fee is journaled the moment the order's size is known, whether or not it fills. Every unfilled terminal parent — cancelled, expired, or failed — is rebated to the tab automatically; partial fills rebate the unfilled fraction. Both paths are covered by the same drill discipline as order forwarding: the fee drill proves accrual, full rebate, pro-rata rebate, and idempotency against the production database, and the reconciliation between accrued and collected is checked on a standing cycle with an alarm on any cent of drift. A separate venue-truth pass then verifies collection against Hyperliquid's own fill record — the builder fee the venue itself reports, matched fill by fill back to the parent's orders — and journals the venue's number beside the estimate; a mismatch raises an alarm rather than a silent re-bill, and the estimate errs in the user's favour by design. A fee that survived only on fill would be a transaction-based fee. This machinery exists to prove this one is not.
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.
What testing does not promise
A drill passing means the engine behaves as specified on the scenarios drilled. It does not mean the engine cannot fail in a scenario not drilled, or that a live market will match the scripted venue layer's behaviour. It does not mean your position is safe, your stop will fire at the price you set, or your fill will match the arrival benchmark. Those are market facts, not engineering facts. The drills prove the engine is mechanical. They do not prove the market is kind.