Provably Fair Social Casino: How Bink.bet's HMAC-SHA256 System Works

At signup (or on rotation), Bink generates a 256-bit random server seed. The player picks or accepts a client seed. These two halves together drive every outcome until the player chooses to rotate.

Before you place a single bet, Bink publishes SHA-256(serverSeed) — a one-way hash of the server seed. You record this hash. The server now cannot change the seed without the hash changing, and the published hash is permanent.

For round n, the outcome is derived from:

HMAC-SHA256(serverSeed, clientSeed + ":" + n)

The first 8 bytes of the HMAC output map to a 0.00–100.00 float, then through a game-specific outcome function (Dice maps to a roll; Plinko maps to a peg sequence; Roulette maps to a slot; and so on).

When you rotate seeds (or on Bink's automatic rotation), the server seed is revealed. You verify SHA-256(revealedSeed) === committedHash. If it matches, the server never swapped the seed mid-session — every round you played was derived from the seed you committed to at the start.

With the revealed server seed, the client seed, and the nonce, you can independently re-derive every outcome of every round. Bink's on-site verifier accepts the triplet and returns the exact outcome the server produced. A mismatch is exactly what tampering would look like, which is the point: you do not have to take Bink's word for it, because the algorithm is open and the check is yours to run.

Provably fair applies to the 27 Bink Originals and to nothing else. Studio games from outside providers — slots, live dealer, PvP — run on the provider's own RNG, never receive a Bink seed, and cannot be verified this way. Bink does not describe them as provably fair, and neither should anyone quoting this page.

Source code is open at packages/crypto-utils/src/games/. The live verifier sits at /provably-fair and at /games/<game>/verify per game, and the methodology, the test vectors and the limits of what the system covers are written up in the self audit.