Kaspa Forge
Documentation · Arena · Mainnet beta

How KaspaForge Arena works

KaspaForge Arena is a non-custodial protocol for provably fair games. Its first live game is house-dealt S17 blackjack in public mainnet beta. Any unlocked Desk profile can join an OPEN table with its own wallet key. Kaspa L1 covenants control the money and legal game states; zero-knowledge proofs verify the committed deck and shuffle. The current hosted-prover trust boundary is stated explicitly below.

Also live: Arena Dice. The second public mainnet game uses two committed seeds, a deterministic 16-bit roll and covenant settlement. See the Dice rules, rooms, fees and verification guide.
Public beta boundary. Arena uses real KAS on mainnet. Six joinable OPEN S17 house tables are available at 5, 10, 25, 50, 75 and 100 KAS per side; public tables have no per-wallet allowlist. 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 committed deck without publishing unrevealed cards to the player or chain.

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 from the player and chain. 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. Public rooms use KaspaForge's hosted RTX prover. 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.

Current hosted-prover boundary. The live dealer is the KaspaForge house, not another player. To build the proof, the hosted prover receives both the dealer and player seeds and can reconstruct the full deck. The verified proof prevents substituting a different deck after those commitments, and the covenant constrains moves and payouts; ZK does not hide the witness from the prover or make the current dealer P2P. A true player-hosted P2P dealer with privacy-preserving proving is a separate research track, not a live feature.

From an open table to an on-chain receipt

  1. Room. The KaspaForge house dealer funds an OPEN Room covenant with its stake, liveness bond and network-fee reserve.
  2. Sit down. Any unlocked Desk profile may take an available OPEN seat with its own P2PK key; there is no per-wallet allowlist. Desk verifies the 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. S17 is part of the current 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, 10, 25, 50, 75 or 100 KAS per side. One joinable OPEN S17 table stands at each tier; the stake shown for a seat is the amount actually at risk.
Liveness bonds
Player adds 2 KAS; dealer adds 5 KAS. Bonds return through normal settlement and protect timeout behavior.
Network reserve
The dealer supplies the measured move-fee reserve. It is not a wager; the unused part returns in settlement.
Game service
0.9% of the two-stake bank: 0.09, 0.18, 0.45, 0.9, 1.35 or 1.8 KAS at the six tiers, charged only to the winner. Bonds and the reserve are outside the fee base.
Hosted proof
0 KAS on all current OPEN tables. KaspaForge currently covers the HOSTED proving cost.
Payouts
A regular win pays even money (1:1) before the disclosed winner-only service fee. A two-card player natural against a non-natural dealer pays 3:2. The payout rule is pinned by the room's program identity and cannot change mid-hand.

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 selected table's 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.

Run the public verifier

The standalone KaspaForge Arena Verifier opens both commitments, rebuilds the complete deck and Merkle root, matches disclosed cards to forced positions and replays the branch transcript. It includes a settled mainnet vector, exact dependency lock and mutation tests. For the player-facing overview, rules and current tables, see Kaspa Blackjack.

git clone https://github.com/pcdoctormsk-ctrl/arena-verifier.git
cd arena-verifier
./scripts/check.sh
cargo run --locked --manifest-path arena-verify/Cargo.toml -- /path/to/proof.json

Scope of v0.1: this is an evidence-consistency verifier, not a Kaspa light client. It does not fetch transaction bytes or independently verify DAG inclusion, Groth16 proof bytes, H17/S17 branch legality or settlement outputs. Inspect the linked transactions separately; the repository's SCOPE.md lists every checked and unchecked field.

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.