“Seeded” is one of those words that can make a simulation sound auditable without making it auditable. A seed is only one input to a replay. If the engine version, data pack, iteration order, arithmetic, or settlement rules change, the same seed can tell a different story.
A seed alone is not a replay contract
A deterministic round is a function of every input that can affect the output. That includes the seed, initial state, roster or participant data, market definitions, engine build, random-number algorithm, event ordering, and settlement code. Replaying only the seed proves very little.
The minimum useful archive is a versioned input bundle. It should identify the exact bytes or immutable identifiers used by the round. “Latest roster” is not an input. It is a moving pointer. “Current engine” is not a version. It is an invitation to rewrite history.
The broader pool mechanics in the parimutuel explainer matter here because settlement depends on both the simulated outcome and the accepted position log. Both sides of that equation must be replayable.
Commit-reveal binds only what was committed
A commit-reveal scheme publishes a commitment before a value is revealed. After the reveal, an observer can apply the documented serialization and hash procedure and check whether the result matches the earlier commitment.
That proves a narrow fact: the revealed value corresponds to the commitment. It does not prove the value was sampled fairly. It does not prove the operator committed every input. It does not prove the published engine consumed the revealed value. It does not prove the settlement code matched the simulation.
A serious design states the boundary. If the commitment covers only the seed, say so. If it covers a manifest containing the seed, engine version, data hashes, and market rules, publish the manifest format. Auditability begins when the claim is specific enough to fail.
Random draws need a stable order
Seeded pseudo-randomness is deterministic only when calls occur in the same sequence. Insert one extra draw for an animation, reorder a collection, or skip a branch on one runtime and every later result can diverge.
The engine should pass one explicit random source through all stochastic code. Hidden calls to a platform random function break the chain. Collections that affect draw order should be sorted by stable identifiers. Concurrency should not decide which event consumes the next random value.
Tests should replay a fixed archived round and compare the event log and settlement output. A test that checks only the final score can miss a different path that happens to land on the same result.
Arithmetic and time are part of determinism
Floating-point behavior, rounding order, clock sources, and time-zone parsing can produce divergence even when randomness is controlled. The simulation needs explicit arithmetic and timing rules. Monetary settlement should use an exact representation with a declared rounding policy. Event time should advance from simulation state rather than wall-clock delay.
Cross-runtime replay deserves its own test. If a browser, server process, and audit tool are expected to agree, compare their outputs against the same archived manifest. “Works on the production box” is not independent verification.
The backtest discipline in the browser backtesting guide carries over: pin inputs, pin code, separate training from evaluation, and make the result reproducible by someone who did not author it.
Settlement must be a pure consequence of the archive
The accepted positions need immutable identifiers, timestamps, market definitions, and statuses. The simulation output needs an event log and final market resolutions. Settlement should consume those records and return either a completed ledger or a typed error.
Useful errors include commitment mismatch, missing input, unsupported engine version, replay divergence, invalid market state, and duplicate settlement attempt. Each needs a cure. A missing input cannot be cured by guessing. Replay divergence cannot be cured by overwriting the archive. Duplicate settlement cannot be cured by paying again.
Idempotency matters. Running settlement twice against the same valid round should not create a second transfer. That is a ledger property, not a simulation flourish.
Crashes expose whether the design is real
A restartable round needs a checkpoint whose state is itself versioned and verifiable. Resuming from an opaque memory dump may restore service, but it does not create an audit trail. The system must know which events were committed, which positions were accepted, and whether settlement began.
When required state is unavailable, the honest state is disputed or void according to published rules. The product should preserve evidence and stop. Quietly regenerating a round with the same seed but a different input bundle is not recovery; it is a new round wearing the old identifier.
Verification needs an independent path
An audit tool should accept the archived manifest, validate the commitment, load the named engine version and inputs, replay the event stream, and compare output hashes and settlement. It should not call the live production service and accept its answer.
A product surface such as the live page can expose replay controls, but the proof sits underneath: immutable artifacts, documented algorithms, deterministic tests, and a failure state that refuses to bluff.
The useful claim is not “provably fair.” It is more modest and more testable: given this published manifest and this engine, an independent replay either matches or returns a named error. Anything broader needs evidence the architecture can actually cash.
