Building a sub-millisecond ATS in Rust for security token secondary markets
Why we rewrote the order-matching engine in Rust with Tokio and DashMap — and what we learned about GC pauses, memory safety, and the tradeoffs of zero-copy order books at exchange scale.
A regulated security-token ATS has a different performance profile from a public crypto exchange. The matching path still needs low latency, but correctness matters more than raw throughput: price-time priority must be deterministic, partial fills must be reproducible, compliance failures must stop settlement, and every fill must survive process restarts without double-settling on-chain.
Why the matcher is separate
The API service owns authentication, KYC, order validation, and durable database state. The matcher owns the hot order book. Splitting those concerns keeps the latency-sensitive path small: accepted orders are published to Redis, the Rust matcher holds in-memory books by pair, and matched fills are emitted back to the API for persistence, surveillance, and settlement.
Rust is a good fit for that boundary because the data structures are explicit. The registry uses concurrent order-book access, startup rehydration from open orders, and deterministic matching logic rather than relying on garbage-collected runtime behavior in the critical path.
The actual lifecycle
- The investor submits an order through the authenticated API.
- Pre-trade checks verify offering status, KYC, sanctions, lockups, balances, and chain readiness before the order enters the book.
- The matcher applies price-time priority and emits fills when bid and ask constraints cross.
- The API fill worker persists fills, publishes order-book diffs, triggers surveillance signals, and queues settlement.
- The settlement worker runs chain-specific preflight checks before submitting delivery-versus-payment settlement or non-EVM transfer flows.
Order types are product features, not UI labels
Limit and market orders are the base layer. Fill-or-kill and immediate-or-cancel change the matching contract. Stop orders need a watcher that activates only when market data crosses the trigger. TWAP orders introduce time: the first slice can enter immediately, while later slices must survive server restarts and avoid double placement. Token-x routes that durable scheduling through Temporal when configured, with a goroutine fallback for local development.
| Order Type | Implementation Concern |
|---|---|
| Limit | Rest in price-time order until fully matched, cancelled, or expired |
| Market | Convert to executable demand against available opposing liquidity |
| IOC | Execute immediately against available liquidity, cancel remainder |
| FOK | Execute only if the full quantity is available now |
| Stop | Persist dormant trigger and activate on market-data threshold |
| TWAP | Slice quantity over time with durable workflow scheduling when available |
What makes a security-token ATS harder
A crypto spot exchange can often separate matching from eligibility: if the account has funds, the trade clears. Security tokens cannot. A trade that matches economically may still fail legally if the buyer loses KYC status, a seller is frozen, a lockup applies, a jurisdiction is blocked, or the settlement contract lacks allowance. The matcher therefore produces candidate fills; the settlement pipeline proves they are executable before value moves.
This is why Token-x treats ATS performance and compliance as one system. Low latency order books are useful only if the resulting fills are auditable, surveilled, and settled exactly once.