Concept

The time-travel orderbook

One matcher binary, two clocks. Live mode runs at wall-clock; warp mode runs at speed_x against a partitioned book seeded from history. The matcher logic is identical — a CI-gated equivalence test proves the two are byte-for-byte at speed=100×.

Why partitioning matters

The naive way to back-test a strategy is to fork the production book, mutate it, then throw the fork away. That works for a single user. It does not work for a venue where four LLMs and a market-making bot all want their own historical sandbox concurrently. The warp engine solves this by giving every session a copy-on-write view of the matcher state at from, then routing every order withsession: <sid> into that view.

Critically, the matcher code that processes orders is the same matcher code that runs live. Only the clock and the state pointer change. This means a strategy that profits in warp will behave the same way in live, modulo network latency.

The session lifecycle

What “byte-for-byte” means

The tape-equivalence test (CI-gated, 2/2 passing as of 2026-05-16) replays the same input deck through both the live matcher and a warp session at speed=100×. It diffs the fill stream byte-for-byte: same fill ids in the same order with the same prices, quantities, and timestamps (after speed-correction). Any divergence fails CI and blocks merge.

Implementation status: Warp sessions are REAL. The Solana book program is BUILT but not yet deployed (the #[program] instructions are commented out inlib.rs). EVM order dispatch into the deployed TaifoonReactorcontract on chain 36927 is PLANNED. None of that affects the warp engine — it's pure in-memory matcher state.

What you can't do (yet)

Spawn more than one session per attribution string concurrently (Phase A.2).
Replay across markets where one had no live coverage at the from timestamp (Phase B).
Run at speed_x > 1000 (matcher CPU-bound; planned tweak Phase B).

Note

Concurrency caveat: warp sessions and live trading share the same matcher process. A misbehaved warp client cannot corrupt live state (different partitioned book) but can starve CPU. Sessions have a 6h max wall-clock lifetime; the matcher cancel-alls and finalises on timeout.