Why On-Chain Poker Is Harder Than On-Chain Roulette
Industry Analysis · Protocols & Markets

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.

  1. Mental poker protocols (Shamir-Rivest-Adleman 1979 → Barnett-Smart 2003 → Beaver 2025) have closed the bandwidth and proof-cost gaps that historically blocked deployment.
  2. Three architectures ship today: zkSNARK-wrapped shuffles, stateful-contract penalty schemes, and heads-up commit-reveal — each with different cost and liquidity profiles.
  3. The hard problems left are collusion and bot detection, which are product problems, not cryptography problems.
  4. 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:

  1. Shuffled randomly, with no party — including the operator — knowing the order
  2. Distributed selectively, where each player learns only their own hole cards
  3. Verifiable at showdown, so that nobody played a card they did not legitimately hold
  4. 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.

01 · SETUP 02 · ENCRYPT 03 · SHUFFLE 04 · DEAL 05 · REVEAL P₁ P₂ P₃ Keypairs H = Σ hᵢ aggregate key 52 ElGamal (αᵢ, βᵢ) encrypted deck π · re-rand Bayer-Groth ZK proof ? αᵢ^xₖ Chaum-Pedersen partial decrypt A K verify on-chain contract TRUST MODEL No single party knows the deck order. Each player learns only their own hole cards. A smart contract verifies every step. All cheating is provably detectable on-chain. COST PROFILE Roulette VRF call ~100k gas Direct shuffle proof ~50M+ gas SNARK-wrapped ~300k gas SNARK proof cost: ~200 bytes on-chain
Figure 1. The five-stage mental poker protocol flow. Every step is verifiable on-chain.

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.

The three deployable architectures · cost & readiness
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.

Frequently asked

Questions operators ask

Why can't we just use Chainlink VRF for poker the way we do for roulette?
Because VRF produces public randomness. Roulette's outcome is public the moment it is generated. Poker requires randomness whose output is selectively private — each player must learn their hole cards while every other player remains ignorant of them. No single oracle, no matter how trustless, can produce private randomness shared with one specific party without becoming a trusted dealer.
Is on-chain poker actually faster or just trustless?
Trustless, not faster. A well-engineered traditional poker client deals a hand in tens of milliseconds. The fastest mental poker constructions today add a few hundred milliseconds per deal — acceptable for cash games, marginal for high-frequency tournament play. The value proposition is verifiable fairness and trustless settlement, not latency.
What happens to the rake in a fully on-chain model?
It becomes a smart-contract parameter, visible on-chain and immutable per table. This is one of the genuine commercial advantages: players can verify they were not over-raked, which is one of the most persistent trust complaints traditional rooms face. Some projects route rake to a DAO treasury or distribute it to token holders; others run it as conventional revenue.
How do you handle KYC and AML if the contract is permissionless?
This is the real regulatory frontier. The cleanest approach is geo-restricted front-ends that perform KYC at the application layer while the contract itself remains permissionless. The contract's permissionless nature does not insulate operators from licensing requirements in the jurisdictions they serve, and the "code is law" defence has not been tested in poker-specific enforcement actions yet.
If on-chain poker is so deployable, why hasn't a major operator launched one?
Three reasons. First, the engineering investment is non-trivial and existing operators have working products. Second, regulatory uncertainty makes incumbents cautious about being first. Third — and most underappreciated — incumbents make most of their margin from recreational players whose appetite for self-custody and seed phrase management is approximately zero. The UX problem is bigger than the cryptography problem.
Which chain is best suited for on-chain poker?
No mainnet L1 is well-suited as a settlement layer for live cash games due to confirmation latency. The realistic candidates are application-specific rollups (with their own sequencer for sub-second finality), high-throughput L1s like Solana for non-state-channel approaches, or specialised chains with built-in mental poker primitives. Most production deployments will be hybrid: off-chain interaction with periodic on-chain settlement.
End of article · 1,500 words
Set in Fraunces and Inter Tight.