Skip to content
→ All work

Case study 19 / 37

Titan-HFT

A small, deterministic order-matching engine in Rust: a lock-free SPSC queue, a preallocated price-time-priority book, and a journal that replays byte for byte.

Status
Research
Period
2026
Domain
Tools · Experiments
Language
Rust
Last push
26 OCT 2026
License
MIT OR Apache-2.0
Source of claims
README.md, docs/ARCHITECTURE.md, docs/MEMORY_ORDERING.md, docs/BENCHMARKS.md, docs/LIMITATIONS.md, CHANGELOG.md, tests/alloc.rs, tests/properties.rs, tests/loom.rs, .github/workflows/ci.yml; release-gate verification 2026-10

An educational engine for low-latency systems work. Limit, market (IOC), cancel and replace commands flow from a producer thread through a wait-free ring buffer into a matching engine whose memory is all allocated up front. Every Acquire/Release is justified in writing and checked by loom and Miri, and a counting allocator tests the zero-allocation claim.

01/The problem

Most matching-engine examples are either toy code with no tests or production systems too big to learn from. Titan-HFT sits in between: readable in an afternoon, with measurements you can reproduce.

02/The system

An educational engine for low-latency systems work. Limit, market (IOC), cancel and replace commands flow from a producer thread through a wait-free ring buffer into a matching engine whose memory is all allocated up front. Every Acquire/Release is justified in writing and checked by loom and Miri, and a counting allocator tests the zero-allocation claim.

Pipeline (README)4 components
  • Producer thread to SPSC ring
  • SPSC ring to MatchingEngine
  • MatchingEngine to EventSink

03/Implementation

  1. 01A bounded, wait-free SPSC ring buffer with cache-padded indices and cached remote indices; it is the crate's only unsafe code.
  2. 02A per-tick price ladder with a non-empty-level bitset, intrusive FIFO levels, a node slab and an id index, all allocated in OrderBook::new; O(1) add and cancel.
  3. 03Price-time priority, maker-price execution, IOC market orders, and replaces that keep priority only for a same-price reduction; explicit reject reasons before any state change.
  4. 04A text journal of commands, events and a final book hash; replay reports the first divergence and exits 1.
  5. 05Seeded synthetic order flow (SplitMix64) that is identical on every platform.

04/Engineering

Test the claims, don't assert them

A counting global allocator shows zero allocations while matching 500,000 commands; loom was confirmed to fail when the producer's tail store is weakened to Relaxed.

A naive model as the oracle

512 random command sequences per run are compared event for event against a deliberately simple reference model, with crossed-book, quantity-conservation and FIFO checks after every command.

Platform-independent results

Book and event-stream hashes of three 100,000-command workloads are pinned, so any platform-dependent result fails CI on Linux, macOS or Windows.

05/Interface

No product screenshots are published for this project. The visual above is a code-driven representation of how it behaves, built from the repository source — not a screenshot.

06/Tech stack

  • Rust (edition 2024)
  • loom
  • Miri
  • proptest
  • Criterion
  • HDR percentiles

07/Result

Verified outcomes

  • CI on Linux, macOS and Windows; dual-licensed MIT OR Apache-2.0.
  • Reported in the README (one run, Apple M5 under background load): per-command latency p50 42 ns, p99 292 ns; 17.1–18.2 M commands/s through the producer → SPSC → engine pipeline.

Known limitations

  • Educational and research software, not a trading system: no networking, risk checks or persistence.
  • Single instrument, fixed price band, no self-trade prevention; benchmarks come from one machine.

08/Links

GitHub repository ↗

Related work

Next case study

KernelTrace MCP →