gallery unit · execution core · bottleneck class H
Pre-trade risk gate
Every order in electronic trading passes through a risk gate before it can reach the exchange. The gate gets nanoseconds to say no: too slow and the order misses the market, too lax and one fat-fingered keystroke buys a company.
scenario sandbox
You are the risk desk. Every order below streams through the actual risk-gate crate, compiled to 3.3KB of wasm and running in your browser right now: not a simulation of the Rust, the Rust. Each session is 600 deterministic orders.
pick a session
loading the gate
Fetching the 3.3KB wasm build of the risk-gate crate.
Streams are seeded and deterministic: the same session always produces the same decisions. Wall-clock numbers are measured in your browser at click time and will differ by machine.
what you are looking at
01 · order in
A seeded session of 600 synthetic orders streams in: prices around a reference, sizes inside limits, until the session you picked injects its failure.
02 · seven checks
Each order runs the crate's full check chain, cheapest first: sanity, size caps, price collar, credit exposure, duplicate detection. First failure short-circuits.
03 · decision out
Accept or a named rejection rule. The banner totals the session; the table breaks rejections down by rule.
Go deeper
The measured result: 37ns per evaluation
The full seven-check evaluation runs in 37 nanoseconds with zero heap allocation.
| claim | evidence |
|---|---|
| 37ns full 7-check evaluation | cargo bench -p risk-gate (Criterion) |
| 23M evals/sec sustained | hot_swap_demo, native, repo hardware |
| P99 42ns, no delta during config swap | hot-swap demo, swap at window 3 |
| zero heap allocation | #![no_std]: no Vec, HashMap, or String in the crate |
| no input bypasses any rule | 8 proptest property-test invariants |
| 1.5M events/sec streaming replay | 780K-event day replayed in 0.52s |
Native numbers come from the repo’s committed benchmark harness on its own machine; the regime travels with each claim in the repo README. What runs on this page is the same crate through a wasm boundary, so use the measure button above for the number your hardware actually produces.
The seven checks, in evaluation order
| # | rule | catches |
|---|---|---|
| 1 | quantity nonzero | empty orders |
| 2 | price valid | NaN / negative / infinite prices |
| 3 | max quantity | fat-finger size errors |
| 4 | max notional | value-based size errors |
| 5 | price collar | orders far through the reference price |
| 6 | credit limit | cumulative per-trader exposure |
| 7 | duplicate id | gateway replays inside the window |
Ordering is a performance decision: checks are sorted by expected failure frequency so the common rejection exits earliest. Credit and duplicate state live in fixed-size arrays chosen at compile time, which is why the crate needs no allocator and why the whole thing fits in 3.3KB of wasm.
Why the browser demo is the real thing
The demo does not reimplement the gate in JavaScript. The no_std crate compiles to wasm with a flat C ABI (no wasm-bindgen, no glue, no allocator), and this page instantiates that 3.3KB module directly. Same source, same checks, same decisions as the native build: the property tests hold on both sides of the boundary.
risk-gate (no_std Rust crate)
├── native: cargo bench → 37ns/eval, 23M evals/sec
└── wasm32-unknown-unknown → 3.3KB cdylib
└── this page: WebAssembly.instantiate → rg_evaluate per orderEvidence + how to reproduce
Everything on this page traces to a command in the public repo. The bench, the property tests, the replay, and the wasm build are all reproducible on a laptop:
cargo bench -p risk-gate # the 37ns claim cargo test -p risk-gate # 8 proptest invariants cargo run --release -p risk_core -- replay \ --input data/generated/day_01.jsonl # 1.5M events/sec replay cargo build --release -p risk-gate-wasm \ --target wasm32-unknown-unknown # this page's module
What it doesn't do
- Not an exchange simulator: the sessions here are synthetic order streams shaped like the repo generator’s output, not market data.
- The 37ns / 23M figures are native numbers from the repo’s machine; browser throughput is lower and varies by device, which is why the page measures it live instead of quoting it.
- The repo’s observability stack (Prometheus, Grafana, the replay warehouse) does not run in the browser; the demo covers the hot path only.
- Single-gate, single-thread: real deployments shard gates per session and pin cores; none of that is modeled here.