Why On-Chain Poker Is Harder Than On-Chain Roulette
And why the cryptography is finally catching up to the product — opening an 18-month window for serious operators.
The short answer
Roulette needs one verifiable random number. Poker needs a 52-card deck that is shuffled with no party knowing the order, dealt privately to each player, verifiable at showdown, and recoverable on dropout — secure multi-party computation over private state with rational adversaries. The cryptographic stack to ship this commercially is now mature.
- Mental poker protocols (Shamir-Rivest-Adleman 1979 → Barnett-Smart 2003 → Beaver 2025) have closed the bandwidth and proof-cost gaps that historically blocked deployment.
- Three architectures ship today: zkSNARK-wrapped shuffles, stateful-contract penalty schemes, and heads-up commit-reveal — each with different cost and liquidity profiles.
- The hard problems left are collusion and bot detection, which are product problems, not cryptography problems.
- Heads-up products will ship first and at scale. Multi-way cash games are 12–18 months behind, contingent on prover acceleration.
On-chain dice launched in 2014. On-chain roulette has been a solved problem since the first audited VRF integrations went live. Yet more than a decade into "provably fair" crypto gambling, online poker — the highest-margin, highest-LTV product in the entire gambling industry — still has no peer-to-peer, decentralized rake-collecting operator at meaningful scale.
This is not because nobody has tried. It is because poker breaks every assumption that makes a roulette wheel easy to verify on a blockchain. The good news for operators evaluating the space: the cryptographic primitives that close the gap are no longer research-stage. They are deployable today.
This piece walks through why the asymmetry exists, what each generation of mental poker protocols actually does, where the live projects sit, and what an industry operator needs to understand to ship a product within the next 18 months.
The asymmetry: public randomness vs. private state
Roulette and dice need exactly one thing from a blockchain: a random number nobody can predict or manipulate, generated after bets are locked. That is a solved problem. A typical implementation uses a commit-reveal scheme combined with a verifiable random function (VRF) — Chainlink VRF being the dominant choice — where the operator commits to a seed, the player's bet is included in the input, and the output is a signature that anyone can verify against the operator's public key. Total on-chain footprint: roughly 100k gas, one external call, two storage writes.
Poker needs something fundamentally different. A 52-card deck must be:
- Shuffled randomly, with no party — including the operator — knowing the order
- Distributed selectively, where each player learns only their own hole cards
- Verifiable at showdown, so that nobody played a card they did not legitimately hold
- Recoverable on dropout, because a player who folds or disconnects cannot be allowed to lock funds permanently
That last requirement is what kills naïve constructions. A player who realizes they are losing has every incentive to grief the protocol, and any scheme that requires all n players to participate in revealing the deck creates an n-of-n liveness assumption that breaks the moment one player rage-quits.
This is the gap between a single verifiable random number and a secure multi-party computation over private state with rational adversaries. Roughly 40 years of cryptography research sit between them.
Mental poker, from Shamir-Rivest-Adleman to today
The original 1979 Shamir–Rivest–Adleman protocol established the framework still in use: players collaboratively shuffle an encrypted deck such that no single party knows the permutation. The mechanism is commutative encryption — each player encrypts the deck with their own key, shuffles, passes it on, and at the end the deck is jointly encrypted by everyone. Decrypting a single card requires every player to release their per-card key share for that index.
The scheme has known weaknesses. The original protocol leaks quadratic residue information, which is why Goldwasser and Micali introduced semantic security in 1982 — partly motivated by exactly this. Modern instantiations (Barnett-Smart 2003, Castellà-Roca 2005, Wei-Wang 2012) replace the commutative cipher with ElGamal over an elliptic curve and add zero-knowledge proofs of correct shuffle, correct decryption-share generation, and correct card unmasking.
A modern Barnett-Smart-style flow:
- Setup. Players generate keypairs over a group G and compute an aggregate public key
H = Σ hᵢ. - Deck encryption. Each card cᵢ is encoded as a group element and ElGamal-encrypted under H, giving ciphertexts
(αᵢ, βᵢ) = (gʳⁱ, cᵢ · Hʳⁱ). - Shuffle. Each player applies a secret permutation π and re-randomizes every ciphertext, then produces a zero-knowledge shuffle argument (Bayer-Groth or Neff) proving the output is a permutation and re-encryption of the input — without revealing π.
- Deal. To reveal card i to player j, every player except j publishes their partial decryption
αᵢ^xₖwith a Chaum-Pedersen proof that this matches their public key share. Player j combines these to recover cᵢ. - Showdown. Players reveal secret keys for the cards they held, and a smart contract verifies that the revealed plaintexts are consistent with the encrypted deck.
Every step is verifiable on-chain. The catch — and this is the only thing that matters commercially — is cost. A Bayer-Groth shuffle proof for a 52-card deck runs to several thousand group operations. Verifying that on EVM L1 is economically infeasible. Verifying six of them per hand for a six-handed table is comically so.
The cryptography is no longer the binding constraint. The remaining engineering — prover acceleration, dropout handling, threshold key management — is incremental, not foundational.
The three approaches actually being built
There are essentially three deployable architectures right now, each with different trade-offs. The table below summarises them; details follow.
| Architecture | How it works | Best for | Key constraint | Status |
|---|---|---|---|---|
| zkSNARK shuffle | Wrap the full mental poker protocol inside a SNARK; post only the proof on-chain. | Multi-way tables, any chain with cheap calldata. | Prover time (10–60s naïve; sub-second with hardware accel). | Live · scaling |
| Stateful penalty | Players run cryptography off-chain; chain holds collateral and judges fraud proofs. | High-stakes cash games where collateral isn't a UX problem. | Capital lockup > max hand value per seat. | Reference impl. |
| Commit-reveal (HU) | Both players commit and reveal random values; cards derived by hashing. | Heads-up hold'em, sit-and-go, HU cash. | Does not generalise to n > 2 players. | Ship today |
| Threshold ElGamal | (t,n) secret sharing so any t honest players can complete deals after dropouts. | Mid-stakes multi-way cash with realistic disconnect rates. | Higher round complexity; bandwidth-heavy. | Beaver 2025 |
Approach 1: zkSNARK-wrapped mental poker
Rather than verify the shuffle proof directly on-chain, wrap the entire shuffle + deal protocol inside a SNARK. Players run mental poker off-chain, generate a Groth16 or PLONK proof that they executed it correctly, and post only the ~200-byte proof and a few public inputs to the chain. This is the approach taken by zkHoldem (Khartes Studio), whose zkShuffle circuit proves a correct shuffle and re-encryption of the deck. The on-chain verifier is constant-cost regardless of deck size. Geometry Labs published a general-purpose mental poker library along the same lines.
The trade-off is prover time. A naïve circuit for a 52-card shuffle proof can take 10–60 seconds on commodity hardware, which is a non-starter for live cash games where humans expect sub-second responsiveness. Recent hardware acceleration (SZKP and similar FPGA work published at PACT '24) brings this down by 1–2 orders of magnitude, and recursive proof aggregation lets shuffles be batched across hands.
Approach 2: Stateful contracts with on-chain penalties
The Kaleidoscope and Royal Flush family of protocols (David, Dowsley, Larangeira, Kiayias et al.) take a different angle: do the cryptography off-chain between the players, and use the blockchain only as a judge that enforces penalties when someone misbehaves. The chain holds collateral; if a player deviates — fails to deal, refuses to reveal, signs an invalid message — the honest players publish a fraud proof and seize the cheater's deposit. The 2017 "Instantaneous Decentralized Poker" paper formalised this with stateful contracts, with a reference Solidity implementation.
The cost is collateral lockup: every player must post a bond significantly larger than the maximum hand value to make cheating unprofitable. For high-stakes tables this is fine. For micro-stakes recreational play, the capital efficiency is brutal.
Approach 3: Commit-reveal shortcuts for heads-up
In a recent piece, Bram Cohen argued — correctly — that the cryptography community has been overcomplicating this. For heads-up hold'em specifically, you don't need mental poker at all. Both players commit to random values, reveal sequentially, and the cards are derived by hashing committed values together with a public deck encoding. Hole cards stay private because each player only learns their own slot's committed values from the other side.
This collapses to standard commit-reveal with on-chain enforcement. Gas cost is negligible. The catch is in the name: heads-up only. The construction does not generalise cleanly to n > 2 because the collusion surface explodes — any n-1 colluding players can reconstruct the n-th player's cards.
Where the math still bites
Dropout handling. If a player disconnects mid-hand, the remaining players need to either continue (requiring threshold decryption with a (t,n) scheme so any t honest players can complete deals) or terminate the hand cleanly. Threshold ElGamal works but adds round complexity. The Beaver 2025 paper ("Extending Mental Poker", Cryptology ePrint 2025/1821) extends the protocol family with OT extension and correlated pseudorandomness, materially cutting per-deal communication overhead.
Collusion detection. Mental poker prevents a single cheater from peeking at cards. It does not prevent two players from sharing their hole cards over a side channel. This is a product problem masquerading as a cryptography problem; the only mitigations are statistical — the same hand-history analysis and ML-based detection traditional operators already use.
Bots. The same applies. The Obscuro/TEN experiment in May 2025, which sat LLMs at an on-chain table to bet against each other, was a marketing piece — but foreshadows the operational reality. If you cannot distinguish humans from agents at the table, recreational liquidity dies. On-chain identity primitives (proof-of-personhood, Worldcoin-style attestations) are the most likely path.
What the industry should take from this
The cryptography is no longer the binding constraint. zkSNARK-wrapped shuffles and stateful-contract penalty schemes are deployable today. The remaining engineering is incremental.
Heads-up products will ship first and at scale. The commit-reveal construction needs no novel cryptography and runs on any EVM chain. Expect HU cash and HU SNG to be the first liquid on-chain markets.
The hard problems are the same hard problems traditional operators face. Collusion detection, bot detection, and recreational-player protection are surveillance and product problems. Decentralisation helps with rake transparency and bankroll trust; it does not help with table integrity.
The window for a serious operator to enter this market — with the cryptographic stack mature, regulatory ambiguity still favorable in several jurisdictions, and incumbent online poker rooms haemorrhaging trust over RNG and bot scandals — is open now, and likely for the next 18–24 months. After that, the operators that have launched will have the liquidity, and liquidity in poker is winner-take-most.

