# How to Verify Provably Fair Blackjack

> Learn what to save, how to check the commitment hash and replay cards, with a reproducible example, tested code and clear verification limits.

- Source: https://toolsgambling.com/blog/provably-fair-blackjack
- Author: Evgeniy Volkov (ToolsGambling)
- Published: 2026-03-20
- Updated: 2026-10-27
- Cite as: "Provably Fair Blackjack: How to Verify Results", ToolsGambling, https://toolsgambling.com/blog/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.

| Approach | What you can check | Limit |
|---|---|---|
| Audited RNG game | The scope, version and findings of an available audit report | The report usually does not supply the inputs needed to replay each of your hands |
| Provably Fair | The commitment hash and, with complete history and an exact specification, result replay | A hash match does not establish correct payouts, operator reliability or the absence of every possible influence |
| Live dealer game | Visible cards and actions through the stream and any available recording | A stream is not itself a cryptographic commitment and does not expose every off-camera process |

See the [comparison of Provably Fair and certified RNG](https://toolsgambling.com/blog/provably-fair-vs-rng-certified) 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.

| When | What to save | Why it matters |
|---|---|---|
| Before betting | Commitment hash and seed-pair identification | Connects the reveal to the commitment that existed before play |
| Before betting | Recorded client seed and nonce | Identifies the wager within that seed pair for replay |
| Before betting | Provider, game name, version and rules | Determines the correct algorithm and payout conditions |
| After completion | Revealed old server seed or exact revealed protocol payload | Allows you to recompute the commitment |
| After completion | Every dealt card and action, including dealer cards and separate split hands | Allows comparison of the entire hand, not just its opening cards |
| After completion | Stakes, final payouts and settlement records | Allows a separate check of the financial result |

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](https://stake.com/provably-fair/calculation).

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](https://stake.com/provably-fair/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.

| Verification component | Documented Stake approach | Documented BGaming approach |
|---|---|---|
| What is committed | A hash of the server seed | A hash of the exact serialized Result+Secret payload |
| How the client seed participates | In the HMAC message with the nonce and HMAC block counter | In a subsequent transformation of the result under the documented protocol |
| How game values are generated | An HMAC-SHA256 byte stream followed by conversion | Transformation of the committed result according to the implementation |
| What matters for blackjack | The documented mapping to 52 cards uses sampling with replacement | The specific game specification is required; Stake’s method cannot be substituted |

Sources: [Stake implementation](https://stake.com/provably-fair/implementation), [Stake conversions](https://stake.com/provably-fair/conversions), [Stake game events](https://stake.com/provably-fair/game-events) and [BGaming’s Provably Fair explanation](https://bgaming.com/provably-fair).

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](https://toolsgambling.com/partners/bc-game) 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](https://toolsgambling.com/media/article/2026/10/bbbe4e9fca7fc6ba75c5dde93f7dfeb6.webp)

*This original English excerpt from [BGaming’s primary page](https://bgaming.com/provably-fair) 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](https://toolsgambling.com/blog/how-to-verify-provably-fair) 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](https://toolsgambling.com/casino/provably-fair) 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:

| Field | Value |
|---|---|
| Server seed | `0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef` |
| Client seed | `tg-blackjack-demo` |
| Nonce | `7` |
| Provided hash | `a8ae6e6ee929abea3afcfc5258c8ccd6f85273e0d4626d26c7279f3250f77c8e` |

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](https://toolsgambling.com/media/article/2026/10/e450182b942c6c4c20a225b95f706a1f.webp)

*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`:

```javascript
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:

```sh
node blackjack-demo.mjs
```

The expected two output lines are:

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

The first HMAC-SHA256 block is:

```text
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.

| Stream position | Four bytes | Value after division | Index | Card |
|---|---|---|---|---|
| 1 | `[214,58,1,42]` | `0.8368225791491568` | 43 | Q♣ |
| 2 | `[90,146,53,172]` | `0.3537934822961688` | 18 | 6♠ |
| 3 | `[196,132,73,150]` | `0.7676435462199152` | 39 | J♣ |
| 4 | `[8,88,76,199]` | `0.03259734972380102` | 1 | 2♥ |
| 5 | `[143,91,222,217]` | `0.5599955825600773` | 29 | 9♥ |
| 6 | `[71,237,108,149]` | `0.28096655500121415` | 14 | 5♠ |
| 7 | `[169,230,61,174]` | `0.6636694478802383` | 34 | 10♠ |
| 8 | `[50,73,102,123]` | `0.19643249991349876` | 10 | 4♠ |
| 9 | `[96,25,84,16]` | `0.37538648024201393` | 19 | 6♣ |
| 10 | `[101,104,210,161]` | `0.39613071852363646` | 20 | 7♦ |
| 11 | `[169,76,102,69]` | `0.6613220137078315` | 34 | 10♠ |
| 12 | `[72,146,206,81]` | `0.28349008061923087` | 14 | 5♠ |

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](https://stake.com/provably-fair/conversions) for the conversion method and [game events documentation](https://stake.com/provably-fair/game-events) 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:

| Payout rule | Net profit | Total payout including returned stake |
|---|---:|---:|
| 3:2 | 15 units | 25 units |
| 6:5 | 12 units | 22 units |

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](https://toolsgambling.com/blog/optimal-blackjack-strategy). For variation in results, see the [blackjack losing-streak odds guide](https://toolsgambling.com/blog/blackjack-losing-streak-odds). 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.

| Problem | What to check | Next action |
|---|---|---|
| Commitment hash mismatch | Seed pair, extra newline, encoding and exact payload serialization | Repeat the calculation from the original record; do not alter inputs by guesswork |
| Hash matches but cards differ | HMAC variant, byte-stream cursor, HMAC block counter, deck model, card array and dealing/action order | Compare the implementation with documentation for the exact version |
| Server seed has not been revealed | Reveal conditions and whether seed-pair rotation is required | Ask for the reveal procedure; do not try to “decode” the hash |
| Incomplete history | Hit cards, split hands, dealer hole card, dealer actions and settlement record | Request missing records and treat full verification as unfinished |

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.

**Provably Fair vs Traditional: Verifiability Comparison**

|  | Game Type |
|---|---:|
| Provably Fair BJ | 95 |
| Live Dealer (Camera) | 60 |
| RNG + eCOGRA Audit | 40 |
| Land-Based Casino | 30 |
| RNG No Audit | 10 |

## FAQ

### Can I share verification data with someone else?

Independent replay requires the revealed old server seed or exact revealed payload, client seed, nonce, saved commitment hash, complete history and algorithm version. Do not share passwords, account credentials or wallet secrets. Check the history for personal information before publishing it.

### Is provider documentation an independent security certificate?

No. Documentation describes the stated algorithm and helps you prepare a result replay. By itself, it does not establish that the published algorithm matches the deployed code or replace an independent security review.

### What if support does not provide the missing history?

Save your request, the support response and all available raw data. Record exactly which part of verification remains impossible and pause play until the issue is resolved. Incomplete history prevents verification of the full hand, but does not by itself prove fraud.