The easiest way to explain our replay requirement is with a bug report.
A bot author sees an unexpected fill at tick 6,412. The order looks one tick late. Was the bot slow? Did two messages race? Did a cancel lose priority? A video can show the fill again, but it cannot answer the question. Re-execution can.
What gets recorded
An official replay names the engine build and parameter manifest, then carries the seed and ordered bot-message history needed to reconstruct the match. It also contains the events and periodic snapshots used by the viewer, followed by settlement, scores, placements, and an integrity hash.
The snapshots make scrubbing quick. They are not authoritative checkpoints that can disagree with the engine. The verifier starts from the recorded inputs and derives the result again.
A fair same-tick race
Bots respond to a tick packet, and on-budget messages become eligible on the next tick. The engine seed-permutes competitor seats once per tick, then processes each seat's ready messages in FIFO order before the resulting orders enter price-time priority.
That means seat order and process scheduling do not quietly decide every close race. The ordering is unknown before the match, fair across seats, and recoverable afterward from the same seed.
Money stays out of floating point
Prices, quantities, cash, fees, positions, and scoring use integers. Cash is stored in centi-units. The hidden world and noisy estimates use floating point where the model calls for it, with a fixed expression order and a pinned Rust toolchain.
The exact-replay promise is tied to published engine builds and supported platforms, not to every possible compiler and processor. When engine source opens, published replay-compatibility checks will cover Linux x86-64 and macOS arm64. A replay names the build that judged it, and exactness outside published build and architecture combinations is not promised.
Random draws come from named substreams. News timing, signal noise, same-tick ordering, and house-bot decisions do not share one fragile sequence. Adding a random draw to one subsystem should not reshuffle everything that follows in another.
The local workflow is the point
The engine source release includes a verify command. Once that repository opens, an entrant can download a replay, run the matching engine again, and inspect the exact tick in question. A strategy change can be tested against the same seed instead of a vaguely similar scenario.
For research, the same property makes an experiment easier to cite. An engine version, parameter-manifest hash, and seed are much more useful than “we used the environment as it existed last month.”
Versions do not move underneath old results
A balance change produces a new parameter manifest. A rule or engine change produces a new version. The replay keeps the versions that originally judged the match, and older replay formats remain readable.
This is less convenient than silently updating defaults, but it prevents an old leaderboard result from changing meaning when the current season moves on.
Deterministic is not predictable
The public parameter manifest describes the distributions now; the corresponding engine code will join it at source release. The realized match seed is not public until completion. During play, a bot cannot derive the hidden end tick, future news, another seat's signal, or the next same-tick ordering from a timestamp or match ID.
Once the match is over, revealing the seed changes its purpose. It becomes part of the proof.
Where the promise stops
The exact-replay contract applies to FAST and STANDARD. A future wall-clock league would be a different game because true arrival time would affect outcomes. Recording such a match would still be useful, but bit-for-bit re-execution would not be an honest promise.
A leaderboard normally asks you to accept the final number. Here the better outcome is a result you can inspect, rerun, and disagree with using the same evidence.