Reproducibility

Replays are evidence.

A completed replay contains enough information to reconstruct the market under the engine version that produced it. The viewer is useful, but the verifier is the stronger claim.

What determines a match

For FAST and STANDARD, outcomes are determined by the engine build, parameter manifest, match seed, seat configuration, and ordered bot-message log. Wall-clock scheduling, thread timing, and machine speed do not decide fills after the measured bot responses have been recorded.

The engine uses named random substreams for world initialization, news, signals, same-tick message ordering, and house-bot decisions. Matching, cash, fees, positions, and scoring use integer arithmetic. Outcome-affecting iteration has a total deterministic order.

Replay structure

A replay uses the .cer extension—short for Continual Exchange Replay—and contains three broad parts:

1. Header: format version, engine fingerprint, league, seed, parameter manifest, and per-match seat table.
2. Event stream: messages, fills, book changes, bulletins, accounting changes, and the other state needed to rebuild each tick.
3. Footer: settlement values, scores, placements, per-seat statistics, and an integrity hash.

Periodic snapshots make seeking fast in the visualizer. They are an index over the event history, not a second source of truth.

Terms used on this page

• Parameter manifest: the complete versioned JSON file of public match settings.
• Engine fingerprint: a compact string joining the engine version, protocol version, and manifest hash.
• Seat configuration: the per-match table connecting seat numbers and match-only pseudonyms to competitor or house roles; it does not reveal a competitor's durable identity.
• .cer: the filename extension for a Continual Exchange Replay.

Public and private copies

The public replay preserves the market information participants were allowed to observe, plus post-match values and statistics needed to understand the result. It uses match-only pseudonyms and does not publish private signal streams or submission code.

The seed is disclosed only after completion. Knowing it then makes verification possible without making the match predictable beforehand.

Verify locally after the source release

The verifier ships with the engine source release. When that repository opens, build the engine version named by the replay and run:

ce verify path/to/match.cer

The verifier re-executes the replay and checks that the books, trades, accounting, settlement, and footer match bit for bit. ce inspect prints metadata and event counts when you need a quicker look. At source release, the published replay-compatibility checks will cover Linux x86-64 and macOS arm64; exact replay outside published build and architecture combinations is not promised.

Use replays as tests

A bot author can turn a bad match into a regression case. Re-run the same seed, inspect the tick where inventory moved, and compare the messages emitted by a revised policy. Across different engine or manifest versions, keep the version named by the replay rather than assuming current defaults.

What the viewer adds

The replay room can show depth through time, the position and P&L race, the attributed tape, and hidden values revealed after settlement. Choose a local .cer file there to explore it. Those views help explain a match; independent re-execution is what verifies it.