The /live page on Shark Snip runs a parimutuel coin-betting sim that, in 2026, is the only fully deterministic, seed-replayable, server-auditable live betting engine I know of. This post is the technical explainer of why that matters and how it works under the hood. Not marketing copy — actual mechanics, with the kinds of edge cases that come up in production. If you have ever wondered "what is this thing actually doing when I drop coins on Mahomes ML at 11:43pm Wednesday," this is for you.
For the broader category context — what parimutuel even means and why it matters for sports — start with the parimutuel cornerstone post. This post assumes you know the basics.
What "deterministic" means in this context
A deterministic simulation is one where, given the same starting state and the same inputs, you get bit-identical output every time. For our live sim, the starting state is the seed (a 64-bit integer), the round metadata (teams, kickoff, base lines), and the published feature pack version. The output is the entire play-by-play, ending in a final score and a settled parimutuel pool.
Why this is unusual
Most "sim" products in betting are either Monte Carlo wrappers around fixed projections (CBSSports does this) or random-draw engines with no replay guarantees (most fantasy sims). Real-money live betting books obviously do not run sims at all — they react to actual games. Coin-betting sims that are deterministic exist mostly in poker (RNG verification) and crypto (provable fairness), almost never in sports. We borrowed the pattern.
The seed lifecycle, end to end
One round is a tight loop: commit, accept bets, reveal, simulate, settle.
1. Commit
When a round opens, the engine picks a 64-bit seed via the OS CSPRNG. It computes commitHash = sha256(seed) and publishes only the hash. The actual seed is stored encrypted server-side. Players see the round metadata (Bills vs Dolphins, kickoff in 4 minutes, base spread Bills -3.5) and the commit hash. The hash is durable evidence that the seed cannot be changed after this point.
2. Accept bets
Players ante coins onto sides of the parimutuel pool. Common markets per round: home ML, away ML, game total over/under, "will there be a passing TD in the first 3 minutes" props. Bets are timestamped and stored in a public-readable log. While bets accumulate, the engine displays the live pool distribution — so you can see the Saints ML pool is fat and the Chiefs ML pool is thin, and price your stake accordingly.
3. Reveal
At round lock (typically 30 seconds after open), the engine reveals the seed. Anyone can verify sha256(revealedSeed) === commitHash. If verification fails, the round is voided and all stakes refunded. If it passes, simulation begins.
4. Simulate
The seed is passed to the engine's PRNG. From there, every stochastic decision — play call mixing, steering-behavior tie-breaks, NGS trace sampling, WFC constraint resolution — pulls from seedrandom(seed). The simulation runs through a full game (or game-segment for shorter rounds) producing the play-by-play that streams to the browser.
5. Settle
Final score + market resolutions are computed. The parimutuel pool minus the 5% takeout is distributed to winning ticket holders proportional to their stake share of the winning pool. Settlement is atomic — coin balances update once, never partially. The round's full metadata (seed, bet log, settlement) is committed to the public round archive.
What makes the simulation engine itself deterministic
Saying "we seed the PRNG" is easy. Actually making 22-player football simulation deterministic in JavaScript is harder than it sounds. Three rules the engine follows.
Rule 1: one PRNG, threaded everywhere
There is exactly one seedrandom instance per round, threaded through the simulation context. No code calls Math.random() — there is a lint rule that fails CI on any such call. Every steering decision, every play-call sample, every constraint propagation accept/reject pulls from the threaded PRNG. This is the single most important discipline; one rogue Math.random would break replay completely.
Rule 2: order-stable iteration
JavaScript objects are insertion-ordered now, but Set and Map iteration can be subtle. The engine uses arrays sorted by player ID for any place the iteration order matters. WFC constraint propagation iterates players in a stable order regardless of which cell first triggered the propagation. This guarantees that two replays of the same seed visit constraints in the same order.
Rule 3: integer time, not float time
Simulation steps in 50ms ticks (20 Hz) using integer tick counts, not floating-point seconds. Float accumulation drift across long simulations would otherwise diverge between replays on different machines. Every physical quantity stored as scaled integers (yards × 100, time × 20 ticks per second). Conversion to float happens only at render time.
What this buys players
Audit trail for every settled bet
If you lost a 50-coin Saints ML bet on round 7741, you can replay it. Drop the seed and round metadata into the inspector on /live and the engine walks you through every play that contributed to Saints losing 13-26. You can see the third-quarter punt that flipped field position, the fourth-down conversion that sealed it. Real-money sportsbooks reveal none of this. The closest analog is poker site hand-history download.
Reproducible bet research
You can build models against the sim's output. Pull 1,000 historical rounds, train a TF.js classifier (see the backtesting cornerstone), evaluate on a fresh slice. The model's predictions are testable because the rounds are replayable. Compare to real-world betting where "I would have bet X" is unfalsifiable.
Community-verifiable fairness
The commit-reveal scheme is the same one crypto provable-fairness games use. Anyone, including skeptics, can verify that we did not adjust the seed after seeing bet distribution. The audit window is open — every round's seed + commit hash is stored in the round archive forever. This is the strongest fairness guarantee a betting product can offer, modulo the operator's hash function not being broken.
A worked round: seed 7741, Chiefs at Saints
To make the loop tangible, walk through round 7741 from October 7, 2024 — the same game we used as the Mahomes-Saints example in the backtest cornerstone. The round was open from 11:43:00 to 11:43:30 local. Seed commit hash a4f2...c1d9. Round metadata: Chiefs (away) vs Saints (home), base spread Chiefs -3.5, base total 41.5, kickoff 4:25pm ET (real-game kickoff time, used for narrative; the sim runs in compressed real-time).
Pool composition at lock
- Chiefs ML: 1,847 coins from 28 players (avg 66 coins per ticket)
- Saints ML: 612 coins from 17 players (the contrarian side)
- Total over 41.5: 1,290 coins from 22 players
- Total under 41.5: 1,168 coins from 19 players
- Combined round pool: 4,917 coins
Seed reveal and simulation
At 11:43:30 the seed reveals: 7741. Verification: sha256(7741) === a4f2...c1d9. The engine boots the simulation with seed 7741 and runs ~6 simulated minutes of play in 90 seconds of real time. The play-by-play streams in three layers: ASCII (instant), pixel_32 sprite art (after 4 seconds), painted_2d (after 12 seconds). The crossfade is purely cosmetic; the engine state is bit-identical from frame 1.
Resolution
Final score: Chiefs 26, Saints 13. Chiefs ML wins. Total (26+13=39) under 41.5 wins. Pool settlement, 5% takeout:
- Chiefs ML pool after takeout: 1,847 + 612 of ML pool minus takeout = 2,336. Divided among 1,847 winning coins: 1.265 payout per coin. Each Chiefs ML ticket gets 126.5% of stake back (26.5% profit).
- Total under pool after takeout: 1,290 + 1,168 of total pool minus takeout = 2,335. Divided among 1,168 winning coins: 2.00 payout per coin. Each under ticket doubles its money — because the under was the contrarian side.
Anyone who bet Chiefs ML and total under doubled their stake on under (+100%) and gained 26.5% on ML — a combined effective return of about 152%. That is a parimutuel edge a fixed-odds book would not have paid the same way, because under at -110 fixed odds returns 91% on win, and combining requires either a same-game parlay (with sportsbook-set correlated odds) or two separate bets at their separate prices.
Auditability after the fact
Drop seed 7741 + round metadata into the /live inspector tomorrow, next month, or three years from now. The engine replays the round in headless mode, walks you through every play, shows the pool resolution math. If you suspect a different result is "right," you can read the WFC constraint propagation log frame by frame. This level of audit is impossible at any real-money sportsbook.
Where determinism does not apply
To stay honest: a few corners of the experience are not deterministic and we do not claim they are.
- Visual rendering. The pixel-art player figures, the camera pan, the ASCII fallback — those are stylistic layers on top of the deterministic state. Two replays look the same in spirit but exact frame timing varies with browser and device.
- Network latency for live in-round bets. The instant at which your bet hits the pool depends on your latency. The pool composition you see is a snapshot; by the time you submit, the pool may have moved. The settlement math handles this honestly (your stake share is computed from final pool at lock), but the in-round experience has some real-world chaos.
- Pool composition itself. The seed determines the simulation outcome but not who bets what. Two replays of the same seed in two parallel universes would have different pool compositions and therefore different payouts to winners, even if the winning side is identical.
How this connects to the broader product
The deterministic sim is the testbed for everything else. Models trained on /tinker get evaluated against sim rounds before they ship to picks. Strategies prototyped on the desk get stress-tested against parimutuel pools at known seeds. The sim is a controlled environment that real-money books cannot offer because real games are not replayable.
If you want to actually try the loop: drop into a live round, watch the seed commit, ante some coins, see the reveal, watch the play-by-play resolve. Then replay the seed in the inspector and audit the math. The whole loop takes about a minute and teaches more about parimutuel + determinism than any spec doc.
One important point about scale: the engine intentionally limits its determinism guarantees to gameplay state, not to wall-clock visuals or network ordering. This is the right tradeoff. If we tried to guarantee bit-identical render frames across browsers, we would have to ship a pixel-perfect rendering engine alongside the sim, which doubles the complexity for a guarantee nobody actually needs. Bettors care about whether the pool math is honest and whether the final score is auditable. Both of those guarantees hold rigorously, and the rendering is allowed to feel native to each device.
The flip side: when bug reports come in about "the sim showed me a different play than the audit replay," 95% of the time it is a rendering frame lost in the browser's animation queue, not a state divergence. Tooling on the inspector page distinguishes between the two — the state ground truth is the JSON event log, and the rendered animation is one of several valid visualizations of that log.
Read next
For the math intuition of the pool itself: the parimutuel cornerstone. For the practice-vs-real-money frame: coin sims vs real-money books. For practice on the desk strategy side: open the bettor desk and try a sim-backed bankroll Kelly recipe.
Price examples and pass rules
Use names as evidence, not decoration. The useful SEO win is that Josh Allen, Ja'Marr Chase, Bijan Robinson and Puka Nacua and Chiefs, Bills, Dolphins, Eagles and Lions appear inside decisions, thresholds, and internal links instead of being dumped into a keyword list.
- Spread example: if Chiefs-Broncos opens Chiefs -3.5 and your fair number is -2.8, +3.5 is the bet, +3 is a pass, and the moneyline needs roughly +155 or better before it replaces the spread.
- Total example: if a Bills outdoor total opens 46.5 and wind moves from 8 mph to 21 mph, an under projection at 42.8 still needs a playable number; under 45 or better is different from chasing 43.5.
- Futures example: Bengals AFC North +280 is 26.3% before hold. If your fair number is 30%, stake modestly, track portfolio correlation, and avoid stacking every Burrow, Chase, and Higgins bet into the same thesis.
- CLV rule: a good write-up is not enough. Track whether the spread, total, prop, or futures price closed better than your entry before grading the process.
Use closing-line value guide to keep the examples attached to measurable prices.
Research note board
Use this table to turn the guide into a decision note. The point is to know when the idea is actionable and when it is only context.
| Angle | Input to verify | Example application | Pass when |
|---|---|---|---|
| Market price | Spread, total, moneyline, prop price, or futures hold | Chiefs and Bills compared through hold | The price has moved past the number that created the edge |
| Football or sport context | Role, pace, weather, injury status, opponent style | Josh Allen role news mapped to the relevant market | The original input changes or remains unconfirmed |
| Review loop | Entry, close, result, and reason code | same-game parlay logged with a clear thesis | You cannot explain whether the process beat the market |
Bet responsibly — set limits, never chase losses.
Expected bankroll growth at 55% edge
Expected geometric growth of a $100 bankroll under different Kelly multipliers across 1000 bets at p=0.55, decimal=2. Full Kelly maximises long-run growth but produces the deepest drawdowns; fractional Kelly trades growth for variance.
EV per $100 across win rate × odds grid
Expected value of a $100 stake at each combination of true win rate and market odds. Anywhere the cell is positive you have a long-run profitable bet; the magnitude shows how aggressive Kelly will size it.
