How Hold’em Dealing Works: Randomness, Commitments and Hole-Card Privacy

Does the server managing bets need to know everyone’s hole cards in advance? BluffKing’s current default moves shuffling and private-card delivery into a separate dealer process. The game server advances play without handling unrevealed human hole cards in its normal delivery path.

This article covers only the default “sealed dealing” implementation for Texas Hold’em; other games are outside its scope. Server invisibility here means the game process does not handle unrevealed human hole cards in normal operation. The separate dealer still knows the full deck, and the operator must still be trusted. This is not a cryptographic guarantee that every server-side component is unable to read cards.

Fair dealing involves three distinct questions

Is the deck generated using reliable randomness? Does the deck material returned after settlement match the opening commitment? Do unrevealed cards enter code that has no need to see them?

The default implementation addresses these with a cryptographically secure random generator, a deck hash commitment, and process isolation. Each serves a specific purpose and has a specific boundary.

First: shuffle using secure randomness

For each hand, the dealer obtains a 32-byte, 256-bit seed from the operating system’s secure random source. It uses a ChaCha20 random generator to produce shuffle randomness. The ChaCha RNG documentation identifies this family as cryptographically secure random generators.

The program applies a Fisher–Yates shuffle to a standard 52-card deck: moving backwards, it randomly chooses an index within the remaining range and swaps the two cards. With uniform choices at each step, the algorithm produces a uniform random permutation. The current index generator uses rejection sampling to avoid modulo bias.

Correct execution therefore does not choose the next card in response to player identity or betting actions: the entire order is generated when the hand is created. This relies on the random source, algorithm and running code being correct. The algorithm’s name alone does not prove that a malicious operator has not modified the software or preselected decks.

Second: commit to the deck before play

After generating the deck, the dealer computes a SHA-256 commitment—a digital fingerprint of a sealed card box:

commitment = SHA-256(
  protocol tag + hand ID + seed + random nonce + full deck order
)

The game server receives this commitment at creation, and clients receive it with their card-collection information. When the hand ends and the complete material returns, the system checks for exactly 52 distinct valid cards and recomputes the commitment against the original value.

Under secure-hash assumptions, substituting different final deck material that still matches the original commitment is computationally infeasible. NIST’s Secure Hash Standard describes message digests as a way to detect changes made after digest generation.

A hash checks consistency. It does not encrypt the cards or prove nobody saw them. The final check establishes consistency with the opening commitment; it cannot independently rule out pre-commitment selection and does not mean players have independently verified every aspect of fairness. The final check does not cross-check delivered hole cards, published board cards or showdown cards against the returned deck, nor does it replay the shuffle from the seed. Whether the cards actually played came from the committed deck still relies on the dealer executing correctly.

Third: deliver hole cards directly to players

The game process manages turns, legal bets and pot distribution. The dealer process generates and retains the deck, delivers hole cards and releases public cards at the appropriate stages.

At hand creation, the game process normally receives the commitment and per-seat collection tickets. It forwards each ticket to the corresponding player. The client then uses a separate WebSocket connection to the dealer to redeem its ticket for its own two cards.

1. The dealer generates and retains the deck, passing the commitment and per-seat tickets to the game process.
2. The game process forwards each ticket to its player.
3. The client connects to the dealer with its ticket and receives its own two hole cards directly.

The client checks hand ID, seat, commitment, card ranges and that the two cards differ. This rejects mixed-up hands, seats and malformed messages. Matching the commitment string alone does not verify a full-deck commitment from only two cards.

Human hole cards no longer need to pass through the game process’s normal plaintext delivery path. The engine can represent them with placeholders and continue processing bets. Fewer code paths handle unrevealed cards, reducing opportunities for accidental exposure or misuse.

The game can finish without advance knowledge of hole cards

Calls, raises, folds and pot accounting primarily use public actions. The game process obtains card values when they become necessary:

A dedicated interface supplies hole cards only for registered bot seats and refuses human seats. Obtaining the full deck after play does not publish everyone’s folded cards to the table: user-facing history remains subject to access controls.

The time boundary is explicit: during play, normal data flow limits unrevealed human hole cards entering the game process; after completion, it may obtain the full material.

Failures should not bypass the card boundary

If dealer availability, card delivery or card retrieval fails in a way that prevents continuation, the hand follows cancellation and stake-return handling. It does not switch the hand to an ordinary plaintext dealing path just to finish. Subsequent hands continue to select sealed dealing; repeated failures close the table.

This concerns sealed-dealing failure, not a promise to refund every player disconnection. Reconnection, action timeouts and dealing failures have distinct handling.

What exactly does the design establish?

Secure randomness makes the deck difficult to predict without its secret material. The commitment checks consistency between final material and the opening value. Process isolation and direct delivery reduce the exposure of unrevealed human hole cards.

However, the dealer knows the full deck, and the game service holds redeemable collection tickets. The dealer accepts internally authenticated board-release and settlement commands rather than independently validating the entire betting history. An operator controlling all services can bypass these normal workflows; a player cannot remotely establish the running binary from the page alone.

The accurate claim is: when the current default implementation runs correctly, unrevealed human hole cards bypass the game process’s normal plaintext delivery path, normal execution sets the deck at creation, while the final check only establishes that returned material matches the opening commitment; it does not independently prove that every card actually delivered matched that deck. Each constraint has concrete code behind it, and the operator trust boundary is equally concrete.