What a Kaspa Baccarat Game Would Require

A Kaspa baccarat game — specifically punto banco — would need three things: a commit–reveal seed scheme for randomness, a covenant encoding the fixed drawing rules, and the existing Arena room infrastructure for stakes, timeouts, and settlement. It would not need a zero-knowledge proof, a Merkle tree, or a prover. That is the short answer. The longer one involves understanding why punto banco's rigid rules make it the simplest card game to put on-chain, and why Kaspa Forge hasn't built it yet. Baccarat is a roadmap item, not a live product.

Why Baccarat Needs No Zero-Knowledge Proof

Arena Blackjack uses a RISC Zero / Groth16 proof to demonstrate that a 52-card deck was shuffled correctly without revealing the hidden order. That proof exists because blackjack involves sequential decisions under partial information — the player acts on visible cards, the dealer acts afterward, and hidden state persists across multiple moves.

Punto banco has none of this structure.

Once both seeds are known, the deck order is fully determined. Every card position, every draw decision, and the final outcome follow mechanically from the shuffle. There is nothing to hide and nothing to prove in zero knowledge — the covenant itself is the verifier. This puts baccarat in the same cryptographic tier as Dice: commit–reveal seeds, deterministic resolution, no guest program, no Merkle paths, no prover fee.

The Kaspa wiki describes how Kaspa's scripting layer validates transactions against UTXO conditions. A baccarat covenant would encode the drawing tables and payout logic directly in those conditions, the same way the Dice program encodes its 684-case outcome matrix and roll gate.

The Commit–Reveal–Resolve Flow

A baccarat hand on Kaspa would follow a three-phase lifecycle, each anchored to a transaction or controller action.

Phase 1 — Commit. Both parties lock their secret seeds before either is disclosed. In the Arena model:

1. Player commit. The player's Desk wallet generates a random seed, hashes it with BLAKE3 using a domain separator and game ID (the established Arena convention), and includes the hash in the JOIN transaction. The JOIN carries the player's stake and liveness bond, funding a Game UTXO.

2. House commit. The dealer daemon commits a per-bet seed — one seed per hand, not per room — pinned inside the Room covenant. Per-bet seeds prevent the house from selectively skipping rounds where its seed would produce a player-favorable outcome.

At this point neither side knows the other's seed. The deck order is unknowable.

Phase 2 — Reveal. After both commitments are confirmed:

1. Player reveal. The player signs a PLAYER_REVEAL transaction exposing their seed. The Desk wallet enforces that the revealed value hashes to the earlier commitment.

2. House reveal. The controller broadcasts the house seed. The Dice architecture specifies a forward contract that lets the controller submit the reveal directly on-chain, bypassing the gateway — so the house cannot selectively withhold a losing reveal.

With both seeds public, anyone can recompute the BLAKE3 concatenation, derive the deterministic Fisher–Yates shuffle over positions 0–51, and obtain the full deck order.

Phase 3 — Resolve. This is where baccarat diverges from blackjack and converges with Dice. There are no intermediate moves — no hit, stand, double, or split. The covenant executes the entire hand in one pass:

1. Deal. Draw cards from positions 0–5 (at most six cards: two to Player, two to Banker, up to one more to each). 2. Evaluate. Card values: 2–9 face value, 10/J/Q/K = 0, A = 1. Hand total = sum mod 10. 3. Check naturals. If either hand totals 8 or 9, the hand ends. 4. Player draw. Total 0–5 → draw third card; 6–7 → stand. 5. Banker draw. Fixed lookup table indexed by (banker total, player third card value or "no draw"). 6. Compare and pay. Higher total wins. The covenant verifies seeds match commitments, the shuffle is canonical, drawing rules are correct, and payout outputs sum to the locked game value.

One transaction, one settlement.

Covenant Branch Structure

Even without player decisions, the covenant needs timeout branches to handle liveness failures:

├── RESOLVE          — both seeds revealed, compute outcome, pay
├── PLAYER_TIMEOUT   — player did not reveal in time
│   └── bond forfeited to house, stake returned per policy
└── DEALER_TIMEOUT   — house did not reveal in time
    └── bond forfeited to player, stake + house bond returned

The timeout mechanism is permissionless: anyone can broadcast the timeout transaction once the deadline DAA score is reached, collecting the forfeited bond as incentive. The Arena architecture translates deadlineDaa − virtualDaaScore into a wall-clock countdown, with the covenant's CSV delay as the authoritative clock.

No hit/stand branches. No dealer-turn phase. No PLAYER_ACTION_TIMEOUT or DEALER_TURN_TIMEOUT. The branch count drops from blackjack's double digits to three.

What Baccarat Would Reuse From Arena

The internal work plan identifies a reusable Room/Game/admission/watcher/session API layer. Dice consumes it as the first non-blackjack game; baccarat would consume the same layer:

The last three rows are what baccarat does *not* need. Everything above them is built, audited (Blackjack runtime GO, Dice V3 GO), or in the production pipeline.

The Desk lobby would display baccarat rooms using the same GET /api/arena/v1/rooms endpoint, the same StakeCard component, and the same seven-second polling cadence. The sitDownAtArenaRoom flow — local preparation, server seat, self-transfer, covenant rebuild, password prompt, signature — would be identical. The only new UI surface would be a bet slip (Player / Banker / Tie) and a simplified table visualization.

Bet Types and Commission Handling

Traditional punto banco offers three primary bets: Player (1:1, no commission), Banker (1:1 minus 5 % commission), and Tie (typically 8:1). On-chain, the commission is a payout arithmetic problem, not a game-logic problem. The covenant computes the winner, then applies the commission to the banker-win payout before constructing outputs. The Dice architecture already handles asymmetric payouts across branches; baccarat adds a percentage cut to one branch.

Side bets (Perfect Pair, Dragon Bonus) would add branch complexity and covenant mass. The work plan does not mention them; the honest first version would ship the three primary bets only.

Estimated Cost

The internal work plan places baccarat in the same cost class as Dice: roughly 0.03 KAS per resolved hand, compared to approximately 0.21 KAS for a blackjack hand. The savings come from the same source — no ZK prover invocation, no Merkle path construction, no multi-transaction decision sequence. Two player-side transactions plus one resolution, versus blackjack's longer chain.

Exact cost depends on covenant mass (determined by the drawing-rule lookup table size and branch count) and the network fee rate at deployment. The Dice audit measured specific gram weights per branch; baccarat would need the same measurement before any number is final.

Honest Boundaries and Current Status

Baccarat is a roadmap item, not a live product. The Arena roadmap, revised in August 2026, orders future games as: European Roulette → Kaspa Slots → Hi-Lo → Baccarat. The duel engine, originally second after Dice, has been deferred pending measured demand for social games. Baccarat is not scheduled for immediate development.

The work plan also notes that house-banked baccarat offers the same product experience as house-banked Dice with different imagery — diminishing returns on a new game when the underlying mechanics are equivalent. That is a product prioritization argument, not a technical one.

Several prerequisites are not yet in place:

• Dice is not armed. The Dice consensus layer passed its third independent audit (GO, 04.08.2026), but the production controller branches and UI are engineering work with the permanent production arm off pending review. Baccarat would inherit the reusable layer that Dice is meant to validate first.
• The public verifier covers blackjack only (v0.1). The arena-verifier repository verifies evidence consistency for blackjack hands. Extending it to Dice and then to baccarat is planned but not implemented.
• No covenant drawing-rule encoding has been specified. The general approach (lookup table in script) is sound, but the exact byte layout, mass budget, and opcode path are undetermined.
• Commission handling in covenant payout logic is straightforward in principle but untested in the Arena program. Blackjack and Dice payouts are integer-ratio, not percentage-based.

None of these are blockers in principle — they are sequencing realities. The cryptographic architecture for a Kaspa covenant casino game like baccarat is materially simpler than what blackjack already requires. The distance is a product decision, not a cryptographic one.

Summary

Building a provably fair baccarat game on Kaspa — a covenant casino game with no ZK dependency — would require:

1. Commit–reveal seed generation — identical to Dice, using BLAKE3 with domain separation. No ZK guest, no Merkle root, no prover. 2. A three-branch covenant — resolve, player timeout, dealer timeout. No decision branches. 3. Drawing-rule lookup tables encoded in the covenant script — the only genuinely new engineering. 4. Commission arithmetic in the payout path — a payout variant, not a new primitive. 5. The existing Arena infrastructure — Room UTXOs, bonds, timeouts, Desk admission, controller settlement.

The hard part is not the game logic. It is the sequencing: Dice must ship and prove the reusable layer, roulette and slots must validate the template pattern, and only then does baccarat become the lowest-risk next game to build.