Provably fair verification

The RNG flow uses a server-seed commitment before outcomes and a later seed reveal. Verification must use the exact game/version inputs and outcome mapping. Wallet HMAC signatures authenticate money requests; they are a separate mechanism.

Commitment and deterministic input

The current RNG service commits to a server seed with SHA-256, not SHA-512. Once the seed is revealed, its SHA-256 must match the previously published hash. The shared provably-fair primitive uses:

commitment = SHA256(serverSeed)
hash = HMAC_SHA256(key = serverSeed, message = clientSeed + ":" + nonce)

Use the exact seed strings and nonce representation. Do not substitute SHA256(serverSeed + clientSeed + nonce): that is a different algorithm. The game-specific mapping from the hash-derived value to an outcome is also needed; these two expressions alone are not a complete verifier for every game.

Game differences

Crash and Double take client seeds from up to the first three accepted bets and concatenate them for their round RNG request. Single-player games use their own round inputs. Blackjack also has a shoe/dealing flow. Do not assume all games combine every participant's seed or expose the same verifier.

Server seed reveal can follow seed lifecycle rules rather than occur immediately at the end of every bet. A commitment or seed ID alone does not allow independent reproduction before reveal. Ask Moonshot for the game/version verification procedure and reveal availability used by your enabled environment.

Partner acceptance

Record a sandbox round reference, its pre-outcome commitment, the exact client seed input, nonce, revealed seed when available, and outcome. Check the commitment and run the supported game verifier. If any value differs, preserve the round reference and contact [email protected].

Agree verification-data access, retention and any certification requirements during onboarding. Do not promise a universal retention period or certification status from this documentation alone.