A plain hash takes one input. HMAC takes two - a key and a message - and produces a result that depends on both. Without the key, nobody can compute or predict the output, even if they know the message.
Example (illustrative format; each casino documents its own):
HMAC-SHA256(key = "server-seed-example", message = "my-client-seed:0")
= d72796e116600ebb1e872c081b29e2e9ab21b19f9f9bb6ea5caf9603261c1c40HMAC-SHA256(key = "server-seed-example", message = "my-client-seed:1")
= 0d8527d5032dd6a4f9b9f28b11a5c1b05986cb32497eb96073e6aa07ca0b11ceThe nonce went from 0 to 1, and the output is unrelated. The game then converts these bytes into numbers - for Plinko, one number per row, deciding left or right.
Why it matters: the exact construction (which value is the key, how the message is formatted, how bytes become results) differs between casinos. A verifier has to match it exactly, which is why we reproduce each operator's algorithm against real rounds before calling it verified.
In ProvablyHero tools
Verifiers show every HMAC step.