Deep Sea Dive X — Whitepaper

Deep Sea Dive X is a crash-style multiplier game themed as a submarine descent. A round begins when the player commits a bet and presses Dive. The multiplier grows continuously with elapsed time until either the player cashes out or the submarine implodes at a hidden, pre-committed crash point.

Every round is server-authoritative and provably fair: the crash point is decided on the server the moment the round starts, sealed by a SHA-256 commitment before the client sees anything, and revealed after the round ends so any third party can recompute it.

The multiplier curve is deterministic and grows exponentially with elapsed seconds t:

m(t) = 1.00 · e^(k · t)

The crash point C is drawn from a heavy-tailed distribution with a configurable house edge h. Using the standard crash-game construction, given a uniform u ∈ (0, 1] derived from the round HMAC:

C = max(1.00, floor( (100 − h) / (1 − u) ) / 100)

With house edge h = 1% the theoretical RTP is 99.00%. A small share of rounds bust at 1.00× to fund the edge; the tail rewards long dives. Payout on cash-out is bet × m(t_cashout), rounded to 6 decimals.

Cosmetic rival submarines shown in adjacent lanes are decorative only. They do not affect payout, do not share the player's seed, and their outcomes cannot influence the crash point.

1. At round start, the server generates a 32-byte random serverSeed and a monotonic nonce.
2. The server publishes only serverSeedHash = SHA-256(serverSeed), the nonce, and the player-supplied clientSeed. The raw seed and crash point are never sent while the round is live.
3. The crash point is computed as C = f( HMAC-SHA256(serverSeed, clientSeed:nonce) ) and stored server-side, gated by row-level security.
4. When the round ends (cash-out or crash), the serverSeed is revealed. Anyone can (a) verify SHA-256(serverSeed) == serverSeedHash and (b) recompute C from the seeds and nonce, then compare against the round record.

Because the commitment is published before the round starts, the operator cannot change the outcome after the fact, and the player cannot learn it in advance.

• Server clock is authoritative. Cash-out requests recompute m(t) from the server-recorded started_at. If m ≥ C at request time, the round is forced to crashed regardless of what the client claims.
• Atomic finalization. Cash-out and auto-crash updates are guarded by WHERE status = 'diving', eliminating double-settle races between concurrent finalizers.
• No leaked outcome. The client only ever receives elapsed-time-derived multipliers. Fields server_seed and crash_point are unreadable via public RLS policies while the round is live.
• Bet validation. Bets are validated server-side against min/max bounds, currency whitelist, and — when an operator context is provided — operator activity and player-wallet allowlist.
• Signed round records. Every round is persisted with seeds, hash, nonce, bet, currency, and final status, and is exposed through the public fairness feed once finalized.

Operators are onboarded via the admin console. Each operator receives an API key (shown once, stored only as a SHA-256 hash) and manages an allowlist of approved player wallets.

• Round lifecycle: startRound → pollRound (or client-side ticker) → cashOut.
• Currencies: USDC by default; additional currencies may be enabled per-operator.
• Wallet gating: when an operatorId is supplied, only wallets on that operator's active allowlist may open rounds.
• Revocation: operators and individual wallets can be deactivated instantly from the admin panel; in-flight rounds are unaffected, but no new rounds may be opened.

• Per-round bet is bounded between 0.01 and 1000 units of the selected currency.
• One active round per player at a time; overlapping rounds are rejected server-side.
• Operators are expected to enforce their own deposit, loss, and session limits upstream; this game does not custody player funds.
• The game surface includes mute controls and does not employ dark patterns to prolong sessions.

The public Fairness Verifier lists the latest finalized rounds with their seeds, nonces, and crash points. Anyone can paste the revealed serverSeed, clientSeed, and nonce into the verifier and reproduce the crash point locally in the browser.

The reference implementation of computeCrashPoint and SHA-256 is shipped in the client bundle at src/lib/crash-formula.ts so operators and auditors can inspect and re-run it independently of any server response.