Can a Kaspa Blackjack Table Remove the House Dealer?

Short answer: technically yes, but not yet. Research into a dealerless Arena Blackjack table — where a regular user, not KaspaForge, acts as dealer — confirmed that local zero-knowledge proving can keep the dealer's secret seed on their own device. The covenant still enforces legal play and correct payouts regardless of who deals. However, implementation is deliberately deferred: current demand for peer-to-peer Kaspa blackjack does not justify the engineering and UX cost of shipping it today.

This article walks through how Arena Blackjack proves a fair shuffle, why making the dealer permissionless is harder than it sounds, what the research found, and where the honest product boundaries sit.

How Arena Blackjack Proves a Fair Shuffle

Every Arena Blackjack hand starts with a cryptographic shuffle. Two parties contribute entropy:

shuffled_deck(game_id, dealer_seed, player_seed)
  → canonical 52-card permutation
  → deck_root (Merkle commitment)

The dealer_seed and player_seed are each generated locally by their respective party. Together they deterministically produce a single 52-card permutation — the shoe for that hand. A Merkle root of this permutation (deck_root) is committed on-chain inside the Game covenant.

To prove the shuffle was computed correctly without revealing either seed, Arena uses a RISC Zero zero-knowledge proof. The guest program takes both seeds as private witness — input that never appears on-chain — and produces a proof that the claimed deck_root was honestly derived. The Kaspa covenant script verifies this proof on-chain via the OpZkPrecompile 0x20 opcode before any cards are dealt.

This is the same verification model described in the Kaspa wiki developer knowledge base: the covenant enforces what transactions are legal, and the ZK proof is one of the facts it checks.

Once the opening deal is proved, subsequent moves — Hit, Stand, Double, Split — follow deterministic dealer rules. Each transition is a new covenant spend: the player signs their decision locally, the dealer's deterministic action is computed from the current hand state, and the next Game UTXO is published. The covenant checks that every card drawn matches the committed deck and that payouts at the end are correct (3:2 for natural blackjack, even money otherwise, per current Arena rules).

The key guarantee: even if one party knows the deck, they cannot change the payout or the legal sequence of cards. The covenant script is the arbiter, and it runs on every Kaspa node.

The Dealer's Secret Problem

In today's Arena Blackjack — a public mainnet beta — KaspaForge is the dealer for every table. The hosted prover infrastructure builds the ZK proof, which means both dealer_seed and player_seed pass through the prover as private witness.

For a house table, this is the declared trust model. The house already generated dealer_seed; giving it to its own prover is not a new exposure. The covenant prevents the house from altering payouts even if it wanted to.

But what if a regular user wants to be the dealer? This is the core challenge of a P2P dealer protocol: a table where neither party is KaspaForge, and the covenant alone enforces the rules.

The problem is immediate. If the user-dealer sends their dealer_seed to a hosted prover — even one they don't control — that prover can reconstruct the entire 52-card permutation:

prover sees:  dealer_seed + player_seed
prover knows: full deck order before any card is revealed

The covenant still prevents the prover from altering payouts or forcing illegal plays. But deck privacy is lost. A prover that knows the deck could, in theory, leak it or use it to inform side-channel decisions. For a trustless P2P game, this is unacceptable — the dealer's secret must remain secret.

This is not a flaw in Arena's covenant design. It is a fundamental property of the current proving pipeline: whoever builds the proof sees the witness.

Five Paths the Research Explored

The research brief evaluated five distinct approaches to solving the dealer's secret problem. Each was assessed across four axes: soundness (can the proof be forged?), privacy (who sees the seeds?), liveness (can a party stall the game?), and selective abort (can a party bail out after learning something advantageous, like the next card?).

A. Local prover on the dealer's device. The dealer's own machine — a desktop helper or native client — builds the RISC Zero proof. The dealer_seed never leaves their device. This is the most direct path to true dealerless blackjack: the owner of the secret proves the statement locally. The trade-off is hardware requirements — proof generation takes CPU or GPU time, and the dealer must keep their application running until the proof completes.

B. Privacy-preserving outsourced proving. Techniques like multi-party computation (MPC), split proving between the dealer's device and a hosted GPU, or oblivious computation where a remote prover assists without seeing the raw witness. Each candidate was evaluated for a concrete protocol, security assumptions, and compatibility with the existing OpZkPrecompile 0x20 verification path. Whitepapers without runnable code were noted as research references, not implementation options.

C. TEE/attested hosted proving. A trusted execution environment (Intel SGX, AMD SEV, or similar) runs the prover in an enclave. The user verifies remote attestation before sending their seed. This can provide practical privacy but introduces a new trusted hardware root — not a cryptographic guarantee. Supply chain, rollback, DMA, and host-admin attack surfaces all apply.

D. Protocol or statement changes. Redesign the shuffle so no single prover ever sees both seeds: committed or encrypted decks, staged proofs per card, verifiable shuffle protocols with two participants, or two-party proving where the dealer proves a small local part and the hosted prover handles the heavy public computation. Any change to the guest program or journal schema means a new image_id, new program version, and new Room/Game inventory — existing live UTXO cannot be migrated.

E. Honest hosted model (fallback). Accept that the hosted prover sees the deck, document the trust boundary explicitly, and rely on the covenant to prevent outcome manipulation. This is not true P2P — it would be a distinct "prover-assisted" class of table with a clearly stated trust assumption.

The Local Prover Verdict

The research concluded with a GO — LOCAL DEALER PROVING verdict.

The finding: a dealer's device can build the RISC Zero proof locally, keeping dealer_seed entirely on-machine. The proof was verified by an independent local verifier and by the Kaspa TxScriptEngine on simnet parameters. Cold and warm latency, peak memory, and transport bytes were measured on representative hardware — not estimated from marketing claims.

The critical property: in the local model, the hosted prover is removed from the trust equation entirely. The dealer generates their seed, builds the proof, and broadcasts the result. No third party ever sees the deck order. Kaspa multiplayer randomness — the combined entropy of both seeds — remains distributed between the two players only.

This mirrors the principle that makes Kaspa Safe non-custodial: the secret (here, the dealer seed; there, the vault key) stays on the user's device. The covenant enforces the rules on-chain regardless.

Why Implementation Is Deliberately Deferred

Despite the positive research verdict, the product decision was to defer implementation. The reasoning is economic, not technical:

• Current Arena Blackjack tables see modest, steady usage as a public mainnet beta.
• The hosted-dealer model works: the covenant enforces fairness, and the trust boundary — house sees the deck, cannot change outcomes — is clearly documented.
• Building a local prover client — with installation, updates, crash recovery, encrypted session persistence, and hardware compatibility across platforms — is significant engineering for a feature whose demand has not materialized at scale.
• The research artifacts (threat model, options matrix, secret flow analysis, benchmark logs) are preserved and reproducible. When demand justifies the investment, the implementation path is clear.

This is not a shelved experiment. The research is complete, the verdict is documented, and the technical foundation is sound. It is a deliberate product decision to build what users need now and defer what they might need later.

Trade-offs and Honest Boundaries

A few things the research did not find:

• No privacy-preserving outsourced proving was proven viable for the current RISC Zero/Groth16 stack with compatible, runnable code. MPC and oblivious proving remain active research areas in the broader ZK ecosystem, but none produced a drop-in path for Arena's guest program.
• TEE-based proving introduces a new trust root, not a trustless guarantee. It may be practically sufficient for some users, but it should not be marketed as equivalent to cryptographic privacy.
• Protocol changes are expensive. Any modification to the shuffle statement means a new program version, new Room inventory, and no migration of existing live UTXO. This is a hard constraint of covenant-based design — the on-chain script is immutable once funded.

The current Arena Blackjack beta — with KaspaForge as dealer — remains the live product. Its trust model is: the house sees the deck, the covenant enforces legal play and correct payouts, and the ZK proof is publicly verifiable. That model is honest and functional today.

What This Means for Kaspa's Self-Custody Gaming Stack

The P2P dealer research illustrates a broader design principle in Kaspa Forge: the covenant is the referee, not the platform. Whether KaspaForge operates the prover or a user-dealer does, the on-chain script determines what transactions are legal. The prover's role is to produce evidence that the shuffle was honest — it cannot change the rules.

This separation — proof generation off-chain, rule enforcement on-chain — is what makes the model extensible. A future P2P dealer table would use the same covenant, the same OpZkPrecompile 0x20 verification, and the same deterministic dealing rules. Only the proof-building location changes.

For Kaspa holders and miners, the takeaway is architectural: covenants on Kaspa's Toccata mainnet enable game logic that is transparent, immutable, and independent of who operates the infrastructure. The blockDAG confirms the transactions. The script decides the outcome. Everything else is implementation detail.

---

*Product status: Arena Blackjack is a public mainnet beta. P2P dealer research is complete; implementation is deliberately deferred. Dice is engineering work with its permanent production arm off pending review. Duel and baccarat are roadmap ideas, not products.*