Provably Fair: How Our Commit-Reveal Pattern Works
A technical deep-dive into the server-seed / client-seed / nonce commit-reveal pattern that powers every demo on the platform.
The commit-reveal pattern
Every bet on NexusPlay uses a three-part provably-fair scheme: a server seed (committed before the round), a client seed (chosen by the player), and a nonce (incrementing counter).
How it works
- Commit: Before the round, the server generates a random 256-bit server seed. It sends only the hash of that seed to the client. The player cannot predict the outcome from the hash.
- Bet: The player places their bet with their own client seed. The nonce increments per round.
- Reveal: After the round resolves, the server reveals the full seed. The client can verify that
hash(seed) == committed_hashand thatfloatFromSeed(seed, clientSeed, nonce)produces the displayed result.
Why this matters
The operator cannot tamper with the outcome after the commit — the hash locks it in. The player cannot front-run the seed — they only see the hash. Both parties can verify the full chain after the fact.
Implementation notes
Our demo uses a non-cryptographic hash for the commit display (performance). A production build would use SHA-256 + a certified RNG audit. The floatFromSeed function uses an FNV-1a + xorshift mix to produce a deterministic 0..1 float from the seed tuple.
Demo-grade only. A production build requires a certified RNG audit (e.g., GLI-19 / iTechLabs). This post describes the pattern, not a certified implementation.