Kaspa Forge
Documentation · Arena · Mainnet beta

How KaspaForge Arena works

KaspaForge Arena is a non-custodial protocol for provably fair games. Its first game is peer-to-peer blackjack. Kaspa L1 covenants control the money and legal game states; zero-knowledge proofs verify the hidden deck and shuffle. No casino account, platform token or trusted dealer is required.

Beta boundary. Arena uses real KAS on mainnet. The protocol has passed repeated adversarial reviews and end-to-end games, but beta software still carries risk. Use the published table stake, keep your encrypted Desk backup current and inspect the settlement receipt.

One hand, five independently checkable layers

There is no single “trust the ZK” shortcut. Each layer proves or enforces a different part of the hand.

01 · RandomnessCommit–reveal

Dealer and player commit their seeds before either can adapt to the resulting shuffle.

02 · Hidden computezkVM / Groth16

Proves the deterministic shuffle and hidden deck order without publishing unrevealed cards.

03 · Card openingMerkle tree

Every shown card carries a path back to the deck root committed by the proof.

04 · MoneyKaspa L1 covenant

Allows only legal Room → Game moves, timeouts and bounded settlement outputs.

05 · ConsentWallet admission

The browser verifies the room and exact JOIN transaction before it signs.

How the ZK-proven deck is generated

  1. The dealer commits first. The room fixes the dealer's seed commitment before a player can join. Publishing a commitment reveals no seed but prevents changing it later.
  2. The player joins with a commitment. One password confirmation creates the player identity, verifies and signs the exact JOIN, and publishes the player's seed commitment.
  3. The player reveals the seed. The reveal must match the earlier commitment. The dealer seed, player seed, game identity and rules now determine one exact shuffle input.
  4. The program performs an unbiased deterministic Fisher–Yates shuffle. The same byte-exact Arena program must produce the same 52-card order from the same inputs. There is no server-side “pick a deck” API.
  5. The hidden deck becomes a SHA-256 Merkle tree. Its root is public; unrevealed cards stay hidden. A card can later be opened together with a Merkle path that proves it belongs to that exact deck and position.
  6. The prover produces one proof bound to this game. The zkVM journal binds the rules, game identity, commitments and deck root. A proof from a different room or different rules cannot be substituted.
  7. Verification happens before dealing. New public rooms use KaspaForge's hosted RTX prover, but its artifact is accepted only after an independent CPU verifier reports it valid. Only then can the covenant advance to the dealt state.

What ZK proves — and what it does not

ZK proves the hidden deck and shuffle. It is deliberately not described as proving “the whole game.” Commitments prevent seed changes; Merkle paths authenticate revealed cards; the covenant enforces legal moves and payouts; the client verifies what it signs. The combined model is stronger and more precise than assigning every guarantee to one acronym.

From an open table to an on-chain receipt

  1. Room. The dealer funds an open Room covenant with its stake, liveness bond and network-fee reserve.
  2. Sit down. The Desk verifies the public room, prepares the exact player coin if needed, signs JOIN locally and starts the seed flow with one password confirmation.
  3. Prove and deal. The hosted proof is generated, independently verified and bound into the transition that commits the deck root.
  4. Play. Hit and stand advance a single Game UTXO. Revealed cards are checked against their Merkle paths; the covenant rejects a transition that is not legal from the current state.
  5. Dealer resolution. H17 or S17 is part of the room rules and proof inputs. The dealer cannot switch the rule after the room was funded.
  6. Settlement. The terminal branch pays the bounded player, dealer, service and prover outputs and records the exact transaction. The Arena lobby links that receipt in the public settled-hands list.

Current beta table economics

Actual wager
5 KAS vs 5 KAS. The stake shown for a seat is the amount actually at risk as the blackjack wager.
Liveness bonds
Player adds 2 KAS; dealer adds 5 KAS. Bonds return through normal settlement and protect timeout behavior.
Network reserve
Dealer supplies 5 KAS for dynamic move fees. It is not a wager; the unused part returns in settlement.
Game service
0.1 KAS, an exact terminal output equal to 1% of the 10 KAS combined stake.
Hosted proof
0.25 KAS, paid only for a HOSTED proof service that was actually provided and accepted.
Full Game lock
22 KAS = 10 KAS stakes + 7 KAS bonds + 5 KAS network reserve. It is not a 22 KAS wager or pot.
Payouts
A win pays even money (1:1): the winner takes both stakes minus the service and prover outputs. A natural blackjack also pays 1:1 in the current rules — the payout table is pinned by the room's rules hash, so it cannot change mid-hand. On a push both stakes return, each side carrying half of the service and prover outputs.

How to verify your hand

  1. Open Verify game at the table to inspect the game id, rules, commitments, deck root, proof status and move log.
  2. After settlement, open Receipt from Latest settled hands. It leads to the exact terminal transaction in the public Kaspa explorer.
  3. Check conservation: the 22 KAS Game lock must equal participant outputs + service output + hosted-prover output + network fees. The unused reserve is already inside participant outputs and is not counted twice.
  4. If the proof, room projection or signed admission chain is missing or invalid, the client must refuse instead of asking you to trust the server copy.

Why blackjack is Arena's first game

Blackjack is simple enough to finish but hard enough to stress the platform: hidden dealer information, a random deck, H17/S17 variants, player choices, multiple proof stages, timeouts, fee ceilings and a terminal payout from shared funds. The reusable result is larger than one card game — verified admission, the program generator, wallet boundary, proving pipeline, Room → Game state machine and audit methodology can support future provably fair games.