Open exposure
Randomized demo positions and optional resting / conditional orders are created on a dedicated account.
How long from breach to actually flat?
On 16 September 2026, Prop Rails forced 50 breaches on a dedicated OKX demo account and timed the complete enforcement path to the exchange’s own flat-state confirmation.
426.9 msMedian breach detected → account flat, confirmed by OKX position push.
452.1p90, milliseconds
509.2p99, milliseconds
542.9worst, milliseconds
50 / 50flat on first attempt
These are OKX demo results from one Windows 11 host in Johannesburg. Demo infrastructure is not production, and network distance dominates the end-to-end result.
Benchmark bn_01a0abad34a30916f5 · 50 runs · OKX global demo · BTC / ETH / SOL perpetual positions.
Methodology
The headline is flat confirmation, not order acknowledgement.
Each run opens controlled exposure, arms a breach through the production rule engine, executes the same cut path used by watch mode, then verifies the account over REST after the exchange push shows no positions.
Trigger rule
A synthetic or market-driven floor breach is armed through the normal risk engine.
Cut
WebSocket close orders and cancellations are dispatched, with REST fallback and retry logic available.
Confirm
The cut clock stops when OKX’s own position push first shows the account flat.
Latency anatomy
The engine is a small share of the measured end-to-end cut.
The benchmark separates local dispatch time, WebSocket round trip, gateway processing, fills and final exchange state.
| Metric | p50 | p90 | p99 | What it means |
|---|---|---|---|---|
| Breach → first cut request | 0.3 ms | 1.2 ms | 7.6 ms | Local rule decision and dispatch. |
| Close order WS RTT | 419.2 ms | 425.7 ms | 508.4 ms | Round trip from Johannesburg host to OKX demo and back. |
| Inside OKX gateway | 2.02 ms | 2.13 ms | 2.26 ms | Exchange gateway inTime → outTime. |
| Ack → filled push | 3.5 ms | 19.4 ms | 47.1 ms | Accepted close order to exchange-reported filled state. |
| Breach → flat push | 426.9 ms | 452.1 ms | 509.2 ms | Headline end-to-end risk result. |
Every figure in this table is derived from the published data/bench.db for benchmark bn_01a0abad34a30916f5, using the same linear-interpolation percentile function as reproduce.py in the repository. Check them yourself →
Caveats
The benchmark is useful because its limits are explicit.
Latency evidence becomes misleading when demo, network location, acknowledgement semantics or sample size are hidden.
Demo ≠ live
OKX demo uses separate infrastructure and may not match production matching or push behaviour.
One network location
The benchmark host was in Johannesburg; placing the same engine closer to OKX should change RTT.
Ack ≠ fill
The report does not treat an accepted order as equivalent to the account being flat.
50-run tails
p99 from 50 runs is indicative. Larger samples are needed for precise tail characterization.
Recompute every published number.
The public repository includes the SQLite data, schema, reports and a standard-library reproduction script.