Designing a Two-Player Duel Game on Kaspa

A two-player duel on Kaspa — High Card, Rock-Paper-Scissors, odd-even — sounds like the simplest possible on-chain game: no hidden state, no dealer, no shuffling, no proving. Two people pick a value, the contract compares them, winner takes the pot. In practice, the hard problem is not the game logic. It is the *protocol*: how two strangers agree to wager, lock money, reveal their choices honestly, and settle — all without a trusted third party, on a proof-of-work DAG that confirms in seconds.

This article walks through the cryptographic design of a Kaspa P2P game protocol for two-player duels as we have scoped it internally. The duel engine is a roadmap item, not an implemented product. Arena Blackjack is the live game surface; Dice is in engineering with its production arm off pending independent review. Everything below describes a system we have planned but not built.

The problem: trustless two-party wagering

A duel between two people who already trust each other is trivial — one hands the other money after the game. The interesting case is two people who do not trust each other, connected only by a link and a Kaspa address. The on-chain contract must enforce every move:

1. Both players commit their choices before seeing the other's. 2. Both reveal — and the reveal is verifiably the same value they committed. 3. The outcome is deterministic from the two revealed values. 4. If either player disappears, the honest side is compensated from a bond, not left waiting.

Each of these is a separate cryptographic and covenant-engineering problem.

Multiplayer commit-reveal: the core mechanism

The commit-reveal pattern is the backbone of every Kaspa Forge game. For a duel, it works in three phases.

Phase 1 — Commit. Each player generates a secret locally — a random byte string, never transmitted, never stored on-chain in plaintext. They hash it and publish only the hash. On Kaspa, this means constructing a transaction whose covenant output pins SHA-256(secret) or BLAKE3(secret) as part of the room's on-chain state. The hash is a *commitment*: it locks the player into a choice without revealing it.

Think of it as putting a sealed envelope on the table. Everyone can see the envelope exists; nobody can open it until the owner does.

Phase 2 — Reveal. After both commitments are confirmed on-chain, each player broadcasts their secret. The contract — or an off-chain verifier watching the DAG — hashes the revealed secret and compares it to the commitment. If they match, the reveal is valid. If a player reveals a value that does not hash to their commitment, the contract rejects it and the timeout branch applies.

This is the player opening their envelope. The hash proves it is the same envelope they placed earlier.

Phase 3 — Outcome and settlement. The covenant script evaluates the two revealed values against the game rules (highest card wins, RPS matrix, parity check) and routes the locked funds accordingly. On Kaspa, this is a single covenant transaction with deterministic payout outputs. Kaspa's transaction fee model and UTXO structure, described in the Kaspa wiki's developer knowledge base, make this settlement fast and cheap — a Duel settlement carries none of the overhead of ZK proof generation or Merkle-path verification.

Player A  ─── hash(a)  ──→  ROOM_OPEN
Player B  ─── hash(b)  ──→  COMMITTED
Player A  ─── reveal a ──→  ┐
Player B  ─── reveal b ──→  ┘ evaluate → SETTLED

Covenant state machine: how the contract enforces honesty

A Kaspa covenant — enabled by Toccata opcodes now live in mainnet — is a script attached to a UTXO that constrains how that output can be spent. For a duel game, the covenant encodes the entire state machine:

ROOM_OPEN    + both commitments present  → COMMITTED
COMMITTED    + both reveals present      → evaluate → SETTLED (winner/push)
COMMITTED    + deadline expired           → TIMEOUT (bond to honest side)
ROOM_OPEN    + deadline expired           → TIMEOUT (bond to creator)

Each state transition is a single transaction spending the current covenant output and producing the next one. The covenant checks:

• Commitment presence — does the successor transaction include a commitment hash?
• Reveal validity — does hash(revealed_secret) match the pinned commitment?
• Game rules — is the winner determined correctly from the two values?
• Deadline enforcement — has the current DAA score exceeded the timeout anchor plus the delay?

The timeout mechanism deserves precision. Kaspa's consensus uses virtualDaaScore as a monotonic clock. A covenant pins a deadline as anchorDaa + delayBlocks, and the script checks that the spending transaction's DAA score has not exceeded it. If the deadline passes and a player has not acted, the timeout branch fires and awards the pot — including the offender's bond — to the waiting player.

This is the same deadline pattern Arena Blackjack uses for its PLAYER_SEED_TIMEOUT and DEALER_TURN_TIMEOUT branches. The duel reuses the structure without ZK, Merkle trees, or a prover — making it the simplest possible consumer of the covenant layer.

Bond > stake: the liveness guarantee

Every Arena game separates *stake* (the wager) from *bond* (the liveness deposit). For a duel, the bond must be strictly larger than the stake. Here is why:

If bond ≤ stake, a player who is losing can simply stop responding. The timeout fires, but the cost of losing the bond is less than or equal to the cost of losing the game honestly. The rational move is to disappear — the worst case is no worse than playing and losing.

With bond > stake, abandoning the game always costs more than finishing it. A player who walks away loses their bond *plus* their stake, while the honest side receives the full pot. The math forces completion.

Pot locked in covenant = 2 × stake + 2 × bond

Timeout branch (B disappears):
  A receives = stake(A) + bond(A) + stake(B) + bond(B) − fees
  B receives = nothing

Normal settlement:
  Winner receives = 2 × stake − fees
  Loser receives  = bond(loser) (returned)
  Winner's bond   = returned

In the planned design, the creator funds their stake and bond when creating the room; the invited player funds their own when joining. The covenant's payout paths are fully deterministic from the game outcome — no oracles, no dispute resolution, no off-chain negotiation.

Covenant game invitations: secret-gated rooms

Current Arena Blackjack rooms are created by an operator. They appear in a public lobby; anyone can join an open seat. This works for house-banked games where the operator controls room lifecycle.

A duel is different. The creator wants to play against a *specific person* — but without a pre-existing identity system, allowlist, or registration. The cryptographic solution is a secret-gated invitation:

1. The creator generates a random invitation_secret. 2. The room's covenant pins SHA-256(invitation_secret) as part of its on-chain state. 3. The creator shares a link containing the preimage: https://…/duel?reveal=<invitation_secret>. 4. When the invited player opens the link, their client presents the secret to the covenant. The script verifies hash(preimage) == pinned_hash and admits the player.

The creator does not need to know the invited player's Kaspa address in advance. Anyone with the link can sit — but only one opponent seat exists, and the first valid admission wins. This is not an allowlist; it is a one-time-use cryptographic lock. The link *is* the key.

This design carries a specific trade-off: if the link leaks, a stranger could join instead of the intended opponent. For casual play, this risk is acceptable — the creator controls when to fund the room and can cancel before funding if the wrong party appears. For higher-value duels, the link can be shared through an encrypted channel. Kaspa Forge's Desk encrypted browser profile is one such channel — keys stay on the user's device, and the session is isolated from the host operating system.

What exists today vs. what the duel needs

The duel engine inherits several components already built and running in Arena Blackjack:

• Covenant state machine — the pattern of state transitions enforced by Kaspa L1 scripts is proven across live mainnet hands.
• Commit-reveal seed mechanics — the two-phase hash-then-reveal for randomness generation maps directly to game-choice commitments.
• Timeout enforcement — DAA-scored deadlines with bond-slashing branches are operational.
• Desk signing flow — local key custody, encrypted profile, per-action password confirmation, fail-closed wallet WASM.

What the duel does *not* inherit — and what must be built from scratch — is permissionless room creation. Today, opening a new Arena room is an operator ceremony involving root-owned policy, dealer key management, and inventory control. The duel requires any user to:

1. Create a room covenant with their chosen game parameters. 2. Fund it with their stake, bond, and a fee reserve. 3. Generate and pin the invitation secret. 4. Broadcast the room to a discoverable surface — or simply share the link privately.

This is the single hardest capability gap. It touches admission logic, covenant template flexibility, Desk UI for room creation, and the security boundary between operator-managed and user-created rooms. The internal architecture plan notes that a duel is the *cheapest* vehicle to build and audit this capability because it carries none of the complexity of ZK proofs, shuffled decks, or multi-round dealer turns. Once permissionless room creation exists, a P2P dealer for Blackjack and other two-party games can inherit it.

Honest boundaries and current limitations

Several things must be stated plainly:

• This is not a product. The duel engine is a roadmap design with no shipped code, no live room, and no invitation link. Arena Blackjack is the only live game surface.
• Dice is in engineering with its permanent production arm off pending independent review. Duel comes after Dice in the pipeline, and the pipeline has already been reordered once based on measured priorities.
• The permissionless room-creation capability does not exist yet. Until it is built, tested, and reviewed, the duel engine cannot function — even as a prototype.
• Social demand is unmeasured. The architecture plan explicitly defers the duel engine until there is measured demand for social (non-house-banked) games. Mandatory room creation, invitation, and waiting for a second participant carry high friction for a game that resolves in seconds.
• No audit has occurred. The designs described here are internal planning documents, not reviewed artifacts. The three-round independent review process that Dice went through — V1 NO-GO, V2 NO-GO, V3 GO — is the standard. Duel designs would face the same rigor before any mainnet deployment.

The timeout semantics deserve a specific caveat. In Blackjack, a soft timeout returns the player's stake minus fees when they fail to act — the game voids rather than punishing. For a duel, the plan calls for a stricter rule: the entire pot (stake plus bond of the unresponsive side) goes to the honest player. This is the correct incentive for a symmetric game with no house, but it means the covenant must handle edge cases around partial reveals, transaction replacement, and DAA-clock drift with no tolerance for ambiguity.

Where this leads

A working duel engine is not an end in itself. It is the infrastructure for any two-player covenant game — High Card, Rock-Paper-Scissors, odd-even, and whatever profiles the community invents over a single covenant form. More importantly, it is the first surface where *users*, not operators, create and fund on-chain game rooms. That capability — permissionless room creation with cryptographic admission and bond-enforced liveness — is the foundation a future P2P dealer for Blackjack would stand on.

The path runs through Kaspa's covenant layer: Toccata opcodes make the state machine enforceable on L1, DAA scores provide the clock, and the proof-of-work DAG provides the finality. No oracle, no off-chain settlement, no custodial escrow. Two players, one contract, one settlement transaction.

For now, the design lives in planning documents and internal architecture notes. When it moves to code, it will face the same independent review cycle that produced three rounds of Dice audit before a GO verdict. That process is the point: trustless games require trustless engineering.