How to Verify Provably Fair Blackjack

Provably Fair blackjack is a way to check completed results against cryptographically committed data and the exact game algorithm. A complete check starts with commitment verification, continues with result replay, and checks the payout separately.

A hash match confirms that the revealed data is consistent with the saved commitment. It does not, on its own, verify the full hand, unbiased input selection, withdrawals, profits or legal availability.

This guide explains how to check a real hand history and provides a separate synthetic exercise that needs no account or money. No actual logged-in wager was verified while preparing this guide.

How Provably Fair compares with other verification methods

Provably Fair can let you reconstruct results from revealed data, but it does not replace an algorithm audit or make every game use the same protocol.

RNG (random number generator) and Provably Fair are not opposing categories: Provably Fair also uses pseudorandom output. The practical difference is what data is disclosed and what you can check independently.

See the comparison of Provably Fair and certified RNG for more detail. Treat provider documentation as a protocol description, not an independent security certificate.

What to save before and after play

Before betting, save the commitment and exact game parameters. After completion, save the revealed data, complete history and payout records.

Where supported, choose an unpredictable client seed after the server commitment has been fixed. This concerns the timing of inputs, not finding favourable cards.

Revealing the server seed may require seed-pair rotation. In the documented Stake protocol, rotation reveals the old server seed; do not assume every provider reveals it immediately after each hand. See Stake’s calculation documentation.

Keep these three parameters distinct:

• Nonce: the wager counter within a seed pair, not an arbitrary global round ID.
• Byte-stream cursor: the offset from which reading the generated bytes resumes.
• HMAC block counter: the block index used when a wager needs more bytes.

In the cited Stake implementation, the HMAC block counter is floor(cursor / 32), and the offset within that block is cursor modulo 32. Each HMAC-SHA256 block supplies 32 bytes, enough for eight four-byte values. See Stake’s implementation.

Also preserve the exact payload serialization. A seed that looks hexadecimal may be literal UTF-8 text rather than decoded hexadecimal bytes. Whitespace, line breaks and field order in a serialized object can matter.

Why there is no universal blackjack verifier

Verification requires the specific provider, game and version. The label Provably Fair does not imply a shared commitment scheme or card-generation algorithm.

Sources: Stake implementation, Stake conversions, Stake game events and BGaming’s Provably Fair explanation.

Sampling with replacement means a generated card is not removed from the possible outcomes before the next draw. In the cited Stake mapping, the same rank-and-suit card can therefore recur. This differs from shuffling a finite deck and drawing cards without replacement.

A third-party game hosted by a casino does not automatically use that casino’s Originals protocol. Identify the game provider first. For example, in our BC.Game review the verify icon belongs to BC Originals, not to the provider games in the same lobby.

Original English BGaming source paragraph describing a deck committed before betting

This original English excerpt from BGaming’s primary page describes its claim that the deck is committed before the bet. It is a provider statement about the protocol, not an independent audit of an actual hand.

How to verify a complete finished hand

A complete check requires the commitment, revealed inputs, exact algorithm and full action history. Without complete history, result replay cannot be finished.

1. Find documentation for the exact game and version. Identify the hash function, input format, byte-to-card conversion, deck model and dealing order.
2. Save the prebet data. Record the commitment hash, seed pair, client seed, nonce, rules and recording time.
3. Obtain the completed history and revealed old inputs. If seed-pair rotation is required, preserve the connection between the old pair and the wager first.
4. Perform commitment verification. Hash the exact bytes or string specified by the protocol and compare the result with the commitment saved before play.
5. Replay the byte stream and card mapping. Use the correct HMAC, encoding, byte-stream cursor, HMAC block counter and card array.
6. Compare the complete dealing and action path. Include hit, stand, double and split decisions, separate split hands, the dealer upcard and hole card, and subsequent dealer actions.
7. Check the payout separately. Apply the published rules to the completed hand and compare the result with the settlement record.

The general Provably Fair verification guide explains the broader evidence-saving process.

The primary documentation used here does not establish how the synthetic stream below is allocated between player and dealer hands. The example therefore labels cards only by stream position; it does not assign them to hands or claim to verify a real wager.

What the ToolsGambling tool checks

The Provably Fair tool helps compare a computed SHA-256 hash with a provided commitment hash. In this exercise, it does not reconstruct Stake Blackjack.

Enter these synthetic values into the four corresponding fields:

Click “VERIFY HASH” and compare the computed SHA-256 with the provided value. For this commitment verification, the client seed and nonce do not affect the hash: it is SHA-256 of the server seed text.

The tool also displays HMAC-SHA512 and a roll. Neither reconstructs the documented Stake Blackjack algorithm, which uses HMAC-SHA256 and its own card mapping.

Synthetic commitment verification in the English ToolsGambling tool running on localhost

This screenshot is from localhost, not the production website. The interface verdict “GAME IS FAIR” is overbroad: only the hash match was checked here. The screenshot does not prove production compatibility with a particular game.

How to repeat the synthetic card calculation

You can repeat this calculation locally with Node.js 22 or newer, without dependencies, an account or money. It validates a documented byte stream and card mapping, not actual settlement or allocation of cards to hands.

Use these exact inputs:

• Server seed: 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef.
• Client seed: tg-blackjack-demo.
• Nonce: 7.
• First HMAC block message: tg-blackjack-demo:7:0.
• Second HMAC block message: tg-blackjack-demo:7:1.

The server seed is literal UTF-8 text. Do not decode it as hexadecimal bytes.

Save this independently tested code as blackjack-demo.mjs:

import { createHash, createHmac } from 'node:crypto';
const serverSeed = '0123456789abcdef'.repeat(4);
const clientSeed = 'tg-blackjack-demo';
const nonce = 7;
const bytes = Buffer.concat([0, 1].map(block =>
  createHmac('sha256', serverSeed)
    .update(`${clientSeed}:${nonce}:${block}`, 'utf8').digest()
));
const ranks = ['2','3','4','5','6','7','8','9','10','J','Q','K','A'];
const suits = ['♦','♥','♠','♣'];
console.log(createHash('sha256').update(serverSeed, 'utf8').digest('hex'));
const cards = Array.from({ length: 12 }, (_, position) => {
  const float = bytes.readUInt32BE(position * 4) / 2 ** 32;
  const index = Math.floor(float * 52);
  return ranks[Math.floor(index / 4)] + suits[index % 4];
});
console.log(cards.join(' '));

Run it with:

node blackjack-demo.mjs

The expected two output lines are:

a8ae6e6ee929abea3afcfc5258c8ccd6f85273e0d4626d26c7279f3250f77c8e
Q♣ 6♠ J♣ 2♥ 9♥ 5♠ 10♠ 4♠ 6♣ 7♦ 10♠ 5♠

The first HMAC-SHA256 block is:

d63a012a5a9235acc484499608584cc78f5bded947ed6c95a9e63dae3249667b

The first four bytes, [214, 58, 1, 42], are read as an unsigned big-endian 32-bit integer and divided by 2 ** 32, producing 0.8368225791491568. Multiplying by 52 and rounding down gives index 43, which maps to Q♣.

The card array uses rank-major order: 2, 3, 4, 5, 6, 7, 8, 9, 10, J, Q, K, A. Within each rank, suits appear as ♦, ♥, ♠, ♣. The letters J, Q, K and A mean jack, queen, king and ace.

The ninth card starts the second 32-byte block because the first eight values consume the first block. The HMAC block counter changes from 0 to 1, while the nonce remains 7.

The repeated 10♠ and 5♠ are valid under sampling with replacement. They do not indicate an error in this synthetic calculation.

The displayed fractional values are text representations of the numbers. If you shorten them, round only for display: compute each index from the unrounded value. See Stake’s conversions documentation for the conversion method and game events documentation for the card mapping.

Why payout rules need a separate check

Correctly reconstructed cards do not guarantee the same payout across games. The game’s published rules determine settlement.

For a winning natural blackjack—an ace and a ten-point card in the initial two cards—with a 10-unit stake:

The difference is 3 units. This example assumes a winning natural blackjack and application of the stated payout rule to a 10-unit stake. It does not cover pushes, insurance or other conditions, and does not calculate the exact house edge.

House edge is the player’s expected loss under specified rules, strategy and calculation basis, not the probability of losing an individual hand. RTP is the long-run theoretical return under defined conditions, not the winning-hand rate or a promised session return.

For playing decisions, use the separate optimal blackjack strategy guide. For variation in results, see the blackjack losing-streak odds guide. Provably Fair verification replaces neither strategy nor risk management.

What to do when verification does not match

Check the inputs and specification before drawing conclusions about fraud. A discrepancy can result from the wrong seed pair, encoding or an incompatible algorithm.

Do not silently change whitespace or field order in a serialized object. Do not convert a hexadecimal-looking server seed into decoded bytes unless the specification requires it.

Preserve the exact raw data, screenshots, time, game version and reproducible calculation. Pause play while the discrepancy remains unresolved, and ask support for missing records or the exact specification.

Can you predict cards, and what remains outside verification?

A strong commitment hash does not provide a practical way to recover the hidden active server seed. Changing the client seed is not a profit strategy.

Revealing an old server seed discloses previously hidden data; it does not invert the hash. Cryptographic collision resistance is a practical security property, not a claim that collisions are mathematically impossible.

Even successful result replay leaves other questions that need separate scrutiny:

• Server seed preselection.
• Selective aborts.
• Withholding records needed for verification.
• Differences between published and deployed code.
• Correct settlement and fulfilment of operator obligations.

Do not install bots promising card predictions or give them wallet secrets. A verifiable algorithm does not promise wins or guaranteed profits.

Gambling involves financial risk. Do not use money needed for essential expenses or treat technical verification as permission to gamble. Availability and requirements depend on your circumstances and local rules; this guide is not legal advice.

What to look for when assessing a game’s technical transparency

Look for the data needed for independent verification, not merely a claim of “fairness.” If a key component is missing, consider in advance that the result may not be reproducible.

Check five things:

1. Exact disclosed algorithm. Are the input format, encoding, card conversion and dealing rules available?
2. Prebet commitment and timing. Can you save the commitment before choosing the client seed and starting play, where that sequence is supported?
3. Complete logs and reveal. Are the old seed-pair records, nonce, every card and action, and seed-pair rotation conditions available?
4. Independent replay compatibility. Can you reproduce the calculation outside the operator’s interface for that exact game and version?
5. Published payout rules. Can you separately compare the stake, completed hand and actual payout?

This checklist helps assess verifiability. It is not an operator endorsement or confirmation of a licence. Keep commitment verification, result replay and payout verification separate: they are three different tasks.