Liar's Dice Is Coming to 6proclub: Provably Fair Bluffing

Liar's Dice — the bluff-and-bid dice game made famous by Pirates of the Caribbean — is the most ambitious game on the 6proclub roadmap. Here is why it is hard to build, and why it is worth it.

The most differentiated game in the 6proclub roadmap is also the hardest to build, and the one we are most excited to ship. It is Liar's Dice — the bluff-and-bid dice game you might know from Pirates of the Caribbean or from a Saturday night with friends and a stack of dice cups.

This post is a preview. Liar's Dice is not live yet, and likely will not be for several months. But it is the game that, when it lands, will mark 6proclub graduating from "good iGaming site" to something more interesting: the only platform where every cryptographic primitive of fairness, including the hardest one, is provable end to end.

Why this game is the flagship

Backgammon's fairness primitive is dice generation. Every roll is provably fair. We have written about how that works at length — SHA-512 commit-reveal, server seed published as a hash before the roll, revealed after, browser re-derives every die from the seed. Not hard, mathematically. The hard part is wiring it to a game and a UI cleanly.

War's fairness primitive is deck shuffle. Same idea, different output: a permutation of 52 cards instead of two integers between 1 and 6. Slightly harder, but the same protocol shape — server commits, client contributes, both reveal, third party verifies.

Liar's Dice's fairness primitive is commit-reveal on hidden information. And this one is genuinely hard.

Here is the difference. In backgammon, the dice are public — both players see the roll. The cryptography only needs to prove that the roll was honest. In Liar's Dice, each player rolls five dice that only they can see. The bidding is based on those hidden dice. The whole game is a bluff: you make claims about the total dice across both players, your opponent decides whether to believe you, and at any point either side can call "liar" and force a reveal.

For this game to be provably fair, the platform has to prove that the dice each player saw were the dice they actually had at the start of the round. Not modified mid-round. Not faked at reveal time. Not influenced by the opponent's bids.

That is multi-party commit-reveal on hidden state. It is a real cryptographic primitive, and almost no online game implements it correctly. Most "provably fair" sites are hand-waving over a much simpler scheme that doesn't apply to hidden-information games.

The protocol

Here is roughly how Liar's Dice will work on 6proclub. The full spec is more detailed, but this is the shape.

1. Round start: dice commit

When a round begins, each player's browser:

• Generates 5 random dice values locally (1–6 each)
• Generates a 32-byte nonce — random, never reused
• Computes a commitment hash: SHA-256(dice || nonce)
• Sends the commitment hash to the server

The server collects both players' commitment hashes and broadcasts them publicly. At this point, the dice are locked. Neither player can change their dice without breaking the hash, and each commitment is now in the public game record.

The server does not see the actual dice values yet. It only sees the hashes.

2. Bidding phase

Players take turns making bids. A bid is (quantity, face_value) — for example, "four 5s" means "I claim that, across both of our hands combined, there are at least four dice showing the value 5."

Each bid must be strictly higher than the previous one (either higher quantity, or same quantity with higher face value). Bids are public, recorded, and signed.

The standard rule: 1s are wild. A bid of "four 5s" is satisfied by any combination of 5s and 1s totalling four. This makes the bid math more interesting and tracks the most common tournament rule worldwide.

The server still does not know either player's actual dice during the bidding phase. It only knows the commitment hashes from step 1 and the bids being made. There is no way for the server to nudge the bidding by leaking information.

3. The call

At any point on their turn, instead of making a higher bid, a player can call "liar." This challenges the most recent bid and triggers the reveal.

4. Reveal phase

Both players must, within a 15-second timeout, send their (dice, nonce) to the server. The server:

• Verifies for each player that SHA-256(dice || nonce) === commitment from step 1. Any mismatch is automatic forfeit for that player.
• Counts the total dice across both hands matching the bid's face value (with 1s wild).

If the actual count is at least the bid's quantity, the bid was good — the caller loses a die. If the actual count is less than the bid's quantity, the bid was bluffing too aggressively — the bidder loses a die.

5. End-round

Whoever lost a die continues to the next round with one fewer die in their cup. Rounds continue until one player has zero dice left — that player has lost the match.

6. Verification

After the game, the verify page shows for every round: each commitment hash, each revealed (dice, nonce), and the bidding sequence. Anyone can re-derive every round outcome from the public log by hashing the revealed dice and confirming the commitment matches, then counting the dice and confirming the round outcome was correct.

The only thing the verify page can't prove is whether each player chose their dice "fairly random" or, hypothetically, with some bias. But since they had to commit before seeing each other's hand, biased dice gain you no information advantage — and game-theoretically, optimal Liar's Dice play uses true randomness anyway. The protocol's correctness does not depend on either player being a good random source.

Why this is hard to build

Three honest reasons we are not shipping this in the next month.

One: the protocol is more elaborate than backgammon's

Backgammon's commit-reveal happens once per game (for the whole dice chain). Liar's Dice's commit-reveal happens once per round, and a single match might have 5–15 rounds. That is 5–15 commitment hashes, 5–15 reveals, 5–15 verification steps to plumb through the verify page.

The bidding phase also adds protocol complexity — every bid is a server-mediated message, signed by the bidder's session token, with rules about validity (must be higher than the previous bid, must be on this round's turn, etc.). Bidding is essentially a turn-by-turn protocol layered on top of the commit-reveal scaffolding.

Two: the UI is genuinely novel

Backgammon, War, and even chess all have well-established digital UIs to reference. Liar's Dice does not. Most online versions are 15-year-old Flash ports, and they all look it.

We have to design from scratch:

• Cup-and-dice presentation. Each player sees their own five dice, hidden from the opponent. The cup-lifting moment at reveal is dramatic and has to feel earned.
• Bid-history panel. Every bid this round, in order, with the current high bid highlighted.
• Bid-making interface. Two dials (quantity + face value), a "raise" button, a "call liar" button, with disabled states when a bid would be illegal.
• Probability hints (advanced setting, optional). A serious Liar's Dice player wants to see the binomial probability of a bid being met. New players want it hidden.
• Reveal animation. This is the showcase moment. Both cups lift, dice tumble onto the felt with physics, server-counted total appears with a count-up animation, and the outcome banner ("BID GOOD" or "BUSTED") reveals who lost a die.

Each of these is a small UI design problem. Together they are a large one.

Three: 2-player only at v1

Liar's Dice is genuinely better with 4–6 players — that is where the bluffing math gets interesting and the social dynamics light up. But the cryptographic protocol for multi-party commit-reveal (3+ players each committing and each revealing, with partial-reveal handling on timeout) is significantly harder than the 2-player case.

We will ship the 2-player version first. That validates the protocol, the UI, and the engine. The 4–6 player version is a v2, and a clearer one once v1 is out the door and battle-tested.

When?

Honestly: a few months out. Probably after War has been live for a couple of months, after we ship Rock Paper Scissors as game #3, and after we have enough platform maturity that the matchmaking, timeout handling, and forfeit-and-payout systems are battle-tested by real volume.

The estimated build effort is 25–35 hours of focused engineering — roughly three times War's footprint. We are committing to that effort, not stretching toward it. The extra time is what makes the game right.

Why it is worth waiting for

Most iGaming sites have 200 slot variants and call that a catalog. 6proclub is going for something different: four distinct game shapes, each one demonstrating a different cryptographic primitive of fairness.

• Backgammon = provably fair dice (public state, commit-reveal of seed)
• War = provably fair shuffle (public state, commit-reveal of permutation)
• Rock Paper Scissors = provably fair simultaneous choice (commit-reveal of opponent's move)
• Liar's Dice = provably fair hidden state (commit-reveal of dice you cannot see)

When all four ship, no other platform on the internet has this. It is the moment 6proclub stops being "another fairness-first iGaming site" and becomes "the only place skill players go because the math is actually transparent across every game shape we play."

If that sounds interesting, start playing backgammon now while you wait. Every roll is provably fair, and the same engine that runs the dice today is the foundation for everything coming next.

The hardest game on the roadmap is also the most interesting one. We will see you at the cup.