⬛ Provably Fair Verifier

wristd.com · verify every hand was dealt honestly

How Provably Fair Works

1 · Before the Hand
The server draws a secret server_seed and publishes SHA-256(server_seed) together with the hand's nonce. It does this before anyone chooses a client seed, so the seed your entropy will be mixed with is already fixed and public as a hash.
2 · You Provide a Seed
Every seated player may set a client_seed. The table seed is all of them sorted and joined with |. Because the commitment came first, the server cannot redraw its seed to suit the entropy it sees.
3 · Deck Derivation
Fisher-Yates over 52 cards, where each swap index comes from HMAC-SHA256(key=server_seed, msg=client_seed + ":" + nonce + ":" + i), taking the first 8 bytes big-endian modulo i+1.
5 · What This Does Not Prove
You can check three things here: that the revealed server_seed matches the hash committed before the hand, that the deck recomputes to the order actually dealt, and that your own client seed is one of the components of the table seed.

You cannot check that the other components came from the players they are attributed to. The table seed is published as a|b|c with each part named against a seat, so a component belonging to no seat is visible — but a component is still only a string this server asserts. Substitution is detectable, by you, if you look; it is not prevented.

Stated plainly: the scheme is sound exactly when every contributing component is checked by the player who submitted it, and nothing in the protocol forces that to be true. The server commits its own seed before it can see any client seed, so it cannot redraw that to suit them — the remaining freedom is a component nobody checks.

Note that a seat which never chose a client seed contributes no component at all, so the list can be shorter than the number of players at the table. That is expected, not a discrepancy — the count to compare against is the number of seats that set a seed, which is why each component is named against its seat.

Two things that sound like improvements and are not. Committing client seeds in advance would prevent rather than detect, but costs a commitment round before every deal. And generating a seed on behalf of a seat that did not choose one would make this worse, not better: it would manufacture components that nobody is watching, which is precisely the freedom this is meant to constrain. A seat contributing nothing gives the server nothing to search over; a seat contributing a value no one checks is the whole problem.
4 · After the Hand
The server reveals server_seed and records the deck order it dealt. Both checks below must pass: the seed has to match the commitment, and the shuffle recomputed from it has to be the exact order that was dealt. A matching hash on its own proves only that the seed was not swapped — not which cards came off the deck.

Check a Past Hand

Verify a Hand


⏳ Computing HMAC-SHA256…