How provably fair Plinko works: from a hash to a ball path

Provably fair Plinko works in three steps. The game commits to a secret server seed by publishing its hash; each drop combines that seed with your client seed and a nonce into a new hash; and the game reads that hash one piece at a time as left or right bounces. After the seed is revealed, you can repeat the calculation and confirm every path.

This guide walks through one complete, fictional 8-row drop, so you can see exactly how a hash becomes a slot.

The ingredients

The game shows you SHA-256(server seed) up front. You can't reverse that to find the seed, but once the seed is revealed you can hash it yourself and check it matches.

Step 1: Build the drop hash

A common design computes:

HMAC-SHA256(key = server seed, message = "client seed:nonce")

That produces 32 bytes, usually shown as 64 hex characters. Each new drop increments the nonce, so every drop gets a fresh, unpredictable hash.

Step 2: Read the hash as bounces

For an n-row board, the game needs n left/right decisions. One simple and common style uses one byte per row:

• Take bytes 1 to n of the hash (two hex characters each).
• Convert each to a number from 0 to 255.
• 0–127 means left; 128–255 means right.

Because each byte is uniform over 256 values and exactly half are 128 or above, each bounce is a fair 50/50. The final slot is the count of rights, which is why provably fair Plinko produces the same binomial odds explained in how Plinko works.

Some games instead turn the hash into one number and pick a slot directly, or use several bytes per decision. The method varies; the principle of "hash in, path out" doesn't.

Worked example (fictional seeds)

All values below are fictional and made for this guide.

• Server seed: fictional-server-seed-7f3a
• Published hash of server seed (SHA-256): ef13903aceeb84bda8d244d672648893b9f24c283e82700f41f31282393ee7a3
• Client seed: fictional-client-seed
• Nonce: 42
• Rows: 8

HMAC-SHA256(key = server seed, message = fictional-client-seed:42) gives:

dde3438f937d296ad23d310681c5c6f4f89ac123eb5f6a58e030d068d38fe8fb

Now read the first 8 bytes:

Four rights and four lefts: the ball lands in slot 4, the centre slot of an 8-row board. On our fictional medium-risk table from Plinko risk levels and multiplier tables, that slot pays 0.4×, so a 1-unit drop returns 0.4 units.

We computed these hashes with Python's standard hmac and hashlib libraries; you can reproduce them with any SHA-256 tool that supports HMAC.

Verify it yourself: a short script

This is the whole check for the fictional example above, using only Python's standard library:

import hmac, hashlib

s, c, n, rows = "fictional-server-seed-7f3a", "fictional-client-seed", 42, 8

h = hmac.new(s.encode(), f"{c}:{n}".encode(), hashlib.sha256).hexdigest()

path = ["R" if int(h[2*i:2*i+2], 16) >= 128 else "L" for i in range(rows)]

print(h, path, path.count("R"))

It prints the hash, the eight bounces and the slot number, 4. To check a real game, swap in that game's own formula and your revealed seeds.

Verification checklist

1. Before playing, copy the server seed hash and your client seed somewhere safe.
2. Play, noting the nonce of any drop you want to check.
3. Rotate the seed so the game reveals the old server seed.
4. Hash the revealed seed with SHA-256. It must match the hash you saved in step 1.
5. Recompute the drop using the game's published formula, your client seed and the nonce.
6. Map the hash to a path using the game's published rule, count the rights, and confirm the slot and multiplier.
7. If anything doesn't match, stop playing and keep your records.

What provably fair does and doesn't prove

It does show that a drop's result was fixed by seeds committed before you played, and that the game didn't swap results afterwards.

It doesn't show that the game is good value. The house edge lives in the pay table, which is public and fixed. A perfectly verifiable game still returns less than 100% over time; see expected value and variance of a Plinko drop.

It doesn't let you predict the next drop. Without the server seed, the next hash is unpredictable, and once the seed is revealed it's no longer in use.

Common questions about the mapping

Why not use all 64 hex characters? An 8-row board needs only 8 decisions. Unused bytes are simply ignored. A 16-row board uses 16 bytes; still well inside 32.

Is "≥ 128" fair? Yes: 128 values (128–255) mean right and 128 values (0–127) mean left.

What if the game uses a different rule? Use theirs. The only thing that matters for verification is that you apply the same published rule the game did.

Summary

Provably fair Plinko turns server seed, client seed and nonce into a hash, and reads that hash as a sequence of fair left/right bounces. The committed seed hash stops after-the-fact changes, and anyone can recompute a drop. It proves integrity, not value: the pay table's edge still applies. Plinko is gambling; play only with money you can afford to lose. If it stops being fun, see responsible gambling.