Sealed Poker Dealing: Moving Hole Cards Out of the Game Process
How a separate dealer delivers hole cards, what bots receive, why dealing failures void a hand, and where the design still depends on trusting the operator.
Taking the full deck out of the game process
A poker table needs a service to manage turns, bets, pots and settlement. Most of that work does not require knowing players’ hole cards. BluffKing’s earlier standard dealing path gave the game service the full deck. The recent change moves shuffling and hole-card delivery into a separate dealer process. Standard Hold’em tables now use sealed dealing, including practice games against bots.
The benefit is a smaller set of code that handles unshown cards during normal play. The game process still decides whose turn it is, whether a raise is legal and how to distribute pots. The dealer sends human hole cards to the corresponding client over a separate connection. In the rules engine, those cards initially occupy slots without card values.
“Sealed” has a specific limit: the dealer still knows the full deck, and the operator must still be trusted. This is a division of responsibilities and data flows between processes. It is not a cryptographic protocol that hides cards from every server component.
When information reaches the game service
At hand creation, the dealer generates a deck, a deck commitment and a collection ticket for each seat. The game service sends each player their ticket; the client uses it to collect its two hole cards from the dealer. The normal delivery path does not require the game service to relay human hole-card plaintext.
| Stage | What the game process normally receives | Material retained by the dealer |
|---|---|---|
| Hand creation | Deck commitment and seat tickets; bots’ own hole cards are fetched separately where needed | Human hole-card values and future board cards |
| Flop, turn and river | Board cards that may be public on the current street | Later board cards and unshown human hole cards |
| Contested showdown | Hole cards of the remaining contenders | Cards not disclosed at showdown |
| Hand completion | The full deck and commitment-checking material for persistence and later review | Secrecy from the game service is no longer promised at this point |
The timing matters. The objective is to reduce exposure while decisions are being made, while retaining history and training after the hand. Obtaining the completed deck does not mean publishing everyone’s folded cards to the table. User-facing history queries still need their own access controls.
A bot needs only its own cards
A server-run bot must know its own hand to make decisions. A table with bots therefore cannot be described as one where the game process knows no hole cards at all.
Sealed dealing narrows the exception to specific seats. Bot seats are declared when the hand is created, and a dedicated interface serves hole cards only for those seats. Human cards cannot be fetched through that bot interface. Human hole-card slots in the rules engine remain opaque until showdown or hand completion requires disclosure.
This lets human tables and practice tables share the sealed-dealing structure while providing the data bots need. It constrains normal interface behaviour; it does not prove that the operator cannot modify the bot or server program.
Void the hand when dealing cannot continue
A separate dealer creates failure cases that must be handled: an unavailable dealer, incomplete hole-card delivery to a client, a failed board request, or completed-deck material that fails validation.
When a sealed-dealing error prevents the hand from continuing, the hand is voided and its committed chips are returned. Recovery must also preserve additional chips already credited during the hand. The system does not switch to plaintext dealing to finish that hand. Subsequent hands continue to use sealed dealing once the required service and delivery are working again. Repeated consecutive dealing failures close the table rather than retrying indefinitely.
This describes sealed-dealing failures, not a rule that refunds chips whenever someone disconnects. Ordinary reconnects, action timeouts and misconduct in the advanced encrypted protocol have their own handling. This failure path is not a general refund promise.
The trust boundary that remains
Process isolation can reduce accidental exposure and misuse. On its own, it cannot protect against an operator who controls every service. Several implementation facts define that limit:
- The dealer holds the complete plaintext deck.
- The game service receives seat tickets. They are bearer credentials, not cryptographic keys held exclusively by players’ devices.
- The dealer accepts internally authenticated disclosure and settlement commands, relying on the game service to call them at the right time. It does not independently verify the complete betting transcript.
- After the hand, the game service can obtain the full material for persistence and review.
The precise claim is therefore: during normal hand execution, unshown human hole cards bypass the game service’s plaintext delivery path, provided the operator runs the implementation correctly. This cannot be expanded into “nobody at the platform can see the cards” or “the operator need not be trusted.”
The deck commitment answers a separate question: does the material returned at completion match the initial commitment? The implementation hashes the hand identifier, seed, random nonce and card order together, then checks the commitment when accepting the full deck. That check cannot establish that nobody saw the cards early, or by itself exclude selection before commitment. The sealed-deck commitment also differs from the older seed-proof format; it does not establish that legacy verification tools support every new hand.
Checking the boundaries in code
The regression checks associated with this change cover more than whether a hand finishes successfully:
- Hole cards are delivered directly over the dealer connection with the expected hand, seat and commitment.
- Board cards are disclosed by street, and the set of showdown seats cannot change after disclosure.
- The bot interface rejects requests for human hole cards.
- The full deck opened at successful settlement has 52 cards and matches the initial commitment.
- A sealed-dealing failure produces an explicit void outcome while retaining sealed dealing for subsequent hands.
These checks support implementation behaviour. They are not an independent security audit and cannot remotely prove which source a live process runs. This article describes the September 28–30, 2026 sealed-dealing changes, principally in sealed_dealer.rs, mp_engine_blind_live.rs and game-session orchestration. Internal implementation files are not presented as published audit material.
A practice worth reusing
For sensitive data, start by listing what each component actually needs to do its job. Then narrow the flow by time and role: retrieve information when it becomes public, give each role its own portion, and release review material after completion. Apply the same constraints to recovery so a failure does not bypass the boundary maintained during normal operation.
BluffKing applies that approach to a poker hand: the game service advances the rules, the dealer holds and delivers cards, and an unrecoverable dealing failure explicitly ends the hand. Players keep their familiar betting controls while fewer normal code paths handle unshown hole cards.