Provably Fair Blackjack: Math, Not Casino Trust

Provably fair blackjack should mean more than a badge beside a table. It should mean that a player can independently answer four questions: Was the deck fixed before either side could exploit it? Did every revealed card come from that exact deck? Did the hand follow the published rules? Did the money move according to the final result?

KaspaForge Arena turns those questions into machine-checkable conditions. Its first live game is non-custodial, house-dealt blackjack on Kaspa mainnet. Commit–reveal fixes the randomness, a zero-knowledge proof validates the hidden shuffle, Merkle paths authenticate each card, L1 covenants constrain state transitions and payouts, and the Desk wallet verifies the exact transaction before signing.

That is a stronger idea of fairness than “we tested our random-number generator” or “here is a hash after the hand.” Casino fairness is usually certified. KaspaForge fairness is reconstructible.

Provably fair blackjack in one minute

If you only remember one idea, remember this: the dealer seeing a deck is not the same as the dealer being able to change it.

In the current HOSTED beta, the KaspaForge prover receives both seeds and can reconstruct the full card order. But by then the protocol has bound the hand to one deterministic shuffle. A different order would produce a different deck root, different card openings and a different proof statement. It would not be a valid continuation of the same game.

The system separates five jobs that ordinary casino software often asks one trusted backend to perform:

• Fix the randomness before either participant can choose a favorable seed after the fact.
• Prove the hidden shuffle without exposing future cards to the player or publishing them on-chain.
• Authenticate each reveal against the one committed deck.
• Enforce legal transitions and payouts in the Kaspa L1 covenant.
• Verify before signing inside the player's own wallet boundary.

In this article

• Certified randomness versus reconstructible fairness
• The five layers behind KaspaForge blackjack
• How one KaspaForge blackjack hand works
• Why seeing the deck does not let the dealer reorder it
• The mathematical invariants
• What the protocol proves—and what it does not
• Public mainnet beta rules and fees
• How to verify a settled hand

Certified randomness versus reconstructible fairness

Regulated online casinos are not mathematically lawless. The UK Gambling Commission's Remote Technical Standard 7 requires random outcomes to be acceptably random and prohibits adaptive discarding or substitution of RNG results. The GLI-19 standard for interactive gaming systems similarly describes evaluation of RNG implementations and game-selection behavior.

Those are meaningful controls. But they answer a different question: Did a regulator or laboratory find that the operator's system met a standard? The individual player still consumes an outcome produced by infrastructure they cannot inspect during that specific hand.

Many crypto casinos narrow that gap with a server-seed hash, a client seed and an after-the-fact reveal. That can prove an RNG result was derived from previously committed data. It is useful, but blackjack is not one random number. It is a hidden ordered deck, a sequence of partial reveals, player choices, dealer rules, timeouts and value transfers.

KaspaForge therefore treats fairness as an end-to-end chain:

This is not an accusation that every other casino cheats, and no responsible article can prove a universal negative about every blackjack implementation. The distinction is architectural: KaspaForge gives the player a route to reconstruct the particular hand, not merely a reason to trust the operator category.

The five layers behind KaspaForge blackjack

Calling the system “ZK blackjack” is tempting, but incomplete. No single acronym proves the whole game. KaspaForge combines five independently meaningful mechanisms, each answering a different question.

1. Commit–reveal fixes when choices stop

The dealer first publishes a cryptographic commitment to its seed. The player's seed is also committed through the verified game flow. A commitment works like a sealed envelope: it hides the value now but makes changing it later detectable.

Only after both sides are bound does the protocol combine the seeds with the game domain and unique game ID. Neither participant gets to inspect the other's final contribution and then quietly search for a more profitable replacement.

2. The zkVM proves the hidden computation

The combined seed drives a canonical, unbiased Fisher–Yates shuffle of the 52-card deck. A zkVM guest computes the deck and emits a compact journal bound to the exact game, rules, commitments and deck root. A Groth16 receipt proves that this hidden computation followed the approved program.

The proof does not publish future cards to the player or chain. It proves that the committed root came from the specified shuffle. KaspaForge's HOSTED pipeline also independently checks the proof artifact with a CPU verifier before it can enter the deal transition.

3. Merkle paths authenticate individual cards

The shuffled deck is committed as a SHA-256 Merkle root. When a card becomes visible, the dealer supplies that card's position and authentication path. The verifier recomputes the path to the root.

This lets the protocol reveal exactly what the game needs—an initial card, a hit, the dealer's hole card—without exposing the remaining deck. A fake card, wrong position or path from another deck will not reach the committed root.

4. Kaspa L1 covenants constrain the money and state

Funds move through a Room UTXO into a Game UTXO and finally into terminal P2PK outputs. The covenant permits only the defined T0–T4 state transitions, legal player and dealer actions, timeout branches and exact payout shapes.

The covenant does not need to know every hidden card in advance. It consumes the proof-bound state and revealed evidence required by each transition. An operator backend can propose a move; it cannot make Kaspa consensus accept an output pattern forbidden by the covenant.

5. The Desk wallet verifies before it signs

The browser wallet does not receive a vague “join this table” request. Its narrow WASM admission boundary rebuilds and verifies the program, Room terms and exact JOIN transaction, binds the player's key, and signs locally only after those checks pass.

This matters because cryptographic settlement is useless if the front end can trick a wallet into signing a different stake, rule set or destination. The Arena verification guide documents how the layers bind together.

How one KaspaForge blackjack hand works

The public interface feels like a card game. Underneath, each hand is a short cryptographic ceremony.

Step 1: choose a published OPEN Room

KaspaForge currently maintains twelve permanent public tables: 5, 10, 25, 50, 75 and 100 KAS stake tiers, each available in H17 and S17 form. Any Desk profile can take an OPEN seat with its own P2PK identity; there is no per-wallet allowlist for the player seat.

Before the wallet signs, it checks the Room's program identity, rules hash, stake, bonds, proof mode, fee pins and destination constraints. The visual table is a projection of those verified terms—not their source of truth.

Step 2: lock both contributions into Game

The dealer-funded Room already exists on Kaspa. JOIN adds the player's exact contribution and transforms the Room UTXO into a Game UTXO. There is no casino account balance and no bridge-wrapped chip: the live object is a Kaspa output governed by the game covenant.

Step 3: bind both seeds and the shuffle

The dealer commitment predates the player reveal. Once both contributions are fixed, the protocol derives the combined seed in a domain separated by the game ID and deterministically shuffles the canonical deck. The resulting Merkle root becomes the identity of that hand's card order.

Step 4: prove and deal

The hosted prover constructs the shuffle proof. The accepted receipt binds the program, game, rules, commitments and deck root. Initial cards are then opened with Merkle paths. Future cards remain hidden from the player and public chain until the rules call for their reveal.

Step 5: play only valid successor states

Hit and stand are covenant transitions, not mutable rows in a casino database. Each revealed card must authenticate against the fixed root. Dealer behavior is pinned by the chosen H17 or S17 program. A move built for another Room, another rules hash or another predecessor state does not become a valid successor here.

Step 6: settle to participant keys

At the terminal state, the covenant enforces the allowed payout layout. Participant outputs return directly to participant-controlled P2PK addresses; service and accepted HOSTED-proof fees use separately pinned outputs. The chain records the settlement transaction, and the proof-evidence bundle becomes available only after durable terminal settlement.

Why seeing the deck does not let the dealer reorder it

This is the most important nuance in KaspaForge's current trust model.

The HOSTED prover sees both seeds and can reconstruct the full deck. Zero knowledge hides future cards from the player and public chain; it does not hide the witness from the prover doing the computation. We state that plainly because “the dealer can never see the deck” would be false.

But knowledge is not control. Once the seed commitments, game binding and deck root are fixed, the dealer has three sharply different possibilities:

• Continue with the committed order. The proof, Merkle openings and covenant transitions agree.
• Try to substitute or reorder cards. The root, authentication paths or proof statement no longer agree, so the candidate transition is invalid.
• Stop responding. This is a liveness failure, not a valid alternative deck. Covenant timeout branches and bonds define how funds can exit when a participant or service fails to act.

Think of a sealed transparent machine. The operator may eventually see every gear inside, but the serial number, assembly proof and output checks prevent replacing the gearbox while claiming it is the same machine.

The guarantee is therefore precise: the dealer cannot turn the already committed hand into a different valid card order. It is not a promise that servers never fail, networks never partition or software contains no bugs.

The mathematical invariants

The implementation has exact byte domains and canonical encodings; the simplified notation below is for intuition, not a replacement for the open-source Arena verifier.

Seed binding

Before reveal, each side is bound by a one-way commitment:

C_dealer = Commit(dealer_seed)
C_player = Commit(player_seed)

At reveal, the verifier recomputes both commitments. A changed seed fails equality.

One deterministic deck

The game derives a domain-separated combined seed and runs the pinned shuffle:

combined_seed = BLAKE3(domain || game_id || dealer_seed || player_seed)
deck = FisherYates([0..51], combined_seed)
deck_root = MerkleRoot_SHA256(deck)

The critical property is determinism: the same valid inputs produce one card order and one root. There is no operator-controlled “pick the nicest of several shuffles” step after reveal.

Authenticated card reveals

For every visible card at position i:

MerkleVerify(card, i, path, deck_root) = true

Changing the card, its position or its path breaks the equality.

State continuity

Every move consumes one specific predecessor and creates one permitted successor:

Game(state_n) --allowed action + valid evidence--> Game(state_n+1)

The program ID, rules hash, game ID, commitments, root and monetary terms travel through that chain of custody. A proof from a different table cannot simply be pasted into this hand.

Terminal value constraints

Settlement is valid only if the terminal outcome and output layout match the covenant branch. That ties the mathematical replay to actual KAS movement. Fair cards with an arbitrary off-chain payout would be an incomplete protocol; KaspaForge closes the loop on L1.

What the protocol proves—and what it does not

Strong security communication includes boundaries. Here is the honest version.

KaspaForge is non-custodial, but non-custodial does not mean risk-free. Real KAS is at stake. Covenant timeouts reduce dependence on an always-online operator, yet players still face game variance, software risk, network conditions and the economic terms of the selected Room.

The beta is house-dealt. True player-hosted or distributed dealing remains a separate research track. That limitation affects privacy and service topology; it does not give the current dealer a way to reorder a hand while preserving the same valid commitment and proof.

Public mainnet beta rules and fees

KaspaForge Arena is live as a public mainnet beta, not a simulation. The current policy is intentionally narrow and machine-enforced.

For the six stake tiers, the game-service fee is 0.1, 0.2, 0.5, 1, 1.5 or 2 KAS. The HOSTED proof fee is 0.2, 0.4, 1, 2, 3 or 4 KAS. Bonds and the dealer-funded network reserve are outside that percentage base. Exact values are pinned in the Room and verified before JOIN; accepted proof fees appear as their own output only after the proof service was delivered and the hand settled.

The 1:1 natural payout is particularly important. Standard casino blackjack often markets a higher natural payout, so omitting the V1 rule would make “mathematical fairness” hollow. Verifiability lets you calculate the terms; it does not make every term favorable.

How to verify a settled hand

After a dealt hand reaches durable terminal settlement, Desk exposes a bounded proof-evidence bundle. A live hand does not reveal the dealer seed or full deck early; premature requests fail closed.

The browser verifier—and the independently runnable open-source CLI—perform the following evidence checks locally:

• Opens both seed commitments.
• Rebuilds the canonical BLAKE3/Fisher–Yates deck.
• Recomputes the SHA-256 Merkle root.
• Matches every revealed card to the position forced by the reconstructed deck and replayed state.
• Replays the public branch transcript to a dealt terminal state.
• Displays proof and settlement transaction IDs for separate chain inspection.

The interface presents cards, totals, a human-readable timeline and four top-level verification results. Advanced disclosure shows all 52 reconstructed positions, seeds, hashes, IDs and downloadable JSON. The full deck is derived locally from the seeds—it is not accepted as a claim handed back by the server.

Version 0.1 of the public CLI is deliberately an evidence-consistency verifier, not a Kaspa light client. A green result proves that the disclosed seeds open their commitments, reproduce the stated root, account for the shown cards at their forced positions and replay to a terminal transcript. It does not fetch transaction bytes or independently verify DAG inclusion, the Groth16 receipt, H17/S17 branch legality or settlement outputs. Those are consensus-level claims; the receipt links their transaction IDs for inspection, and the repository's SCOPE.md keeps this boundary explicit.

To run it yourself, download a completed hand's proof JSON and pass it to the CLI:

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

For protocol details, read How Arena verification works. For the wider security model and disclosure process, see KaspaForge Security. The standalone verifier, schema, mainnet vector and reproducibility checks are published in pcdoctormsk-ctrl/arena-verifier; the separate recovery repository remains scoped to KaspaForge's recovery tools.

Why blackjack is the right fairness test

A coin flip only needs one hidden bit and one payout. Blackjack forces a protocol to solve the harder problem:

• A full hidden sequence must remain committed but only partially revealed.
• Player choices change which cards become relevant.
• The dealer has a hidden card and a conflict of interest.
• H17 and S17 produce different legal dealer behavior.
• A hit must not leak the next card before the player's action is committed.
• Timeouts must recover funds without inventing a favorable result.
• Settlement must bind game logic to real monetary outputs.

That complexity is why blackjack is Arena's flagship first game. It demonstrates a reusable stack for hidden-state applications: deterministic program generation, verified wallet admission, covenant state machines, hosted proving, reproducible builds, adversarial tests and independently checkable settlement.

The product is not “a casino with blockchain payments.” The game itself is an L1-controlled protocol, and the hidden part is connected to that protocol by commitments, a proof and authenticated openings.

Play provably fair blackjack with your own wallet

KaspaForge replaces the most important casino promise—“trust us, the backend dealt honestly”—with a verification path a player's own software can execute.

The claim is deliberately narrower than perfection and stronger than branding. The hosted dealer can see the committed deck but cannot reorder it into another valid deck. Every shown card must open against the same root. Every move must fit the same state machine. Every terminal payout must fit the covenant. After settlement, the player can reconstruct the deck and transcript from both seeds, then inspect the referenced KAS settlement separately.

If that is the standard you want from provably fair blackjack, enter KaspaForge Arena, inspect the Room terms before signing and verify the hand when it settles.

Method note. Product claims in this article describe the public beta state on 4 August 2026. KaspaForge publishes the protocol guide and a narrowly scoped verifier so readers can check its implemented guarantees rather than relying on this article alone. The verifier's explicit non-goals are part of that publication. Browse more engineering notes in the KaspaForge Blog.