Crypto Casino — Technical Architecture

The visible “casino” is a thin real-time UI over two hard systems: a money ledger and a crypto wallet. Roughly 80% of the genuine engineering difficulty lives there, not in the games. This document maps the full system — the player-facing surface, the money internals, the third-party integration contracts, the account/identity/responsible-gambling subsystem, the operator back-office, and the operational flows that tie them together — ranks every component by how optional it is to launch, and goes one level into the parts that are actually hard.

1What these platforms are

People call them “casinos,” but technically each is four products fused into one balance and one real-time session:

1. In-house provably-fair games (Dice, Crash, Plinko, Mines, Limbo, Keno, Wheel, Hilo) — built and run by the operator. The cryptographic differentiator and the highest-margin surface. OPTIONAL
2. Aggregated third-party content — thousands of slots + live dealer (Evolution, Pragmatic, Hacksaw…) pulled in through an aggregator over a seamless-wallet API. The operator runs none of it.
3. A sportsbook — usually a third-party turnkey (BetBy, Digitain, Altenar) bolted onto the same balance.
4. A multi-chain crypto bank — deposits/withdrawals + custody across BTC/ETH/TRON/SOL/LTC/BNB + stablecoins, with an internal ledger.

The “casino” you see is a UI over a money ledger and a wallet service. Everything else either sits on those two, or is integrated rather than built.

Two products are easy to forget because of where they sit. The first is the player-facing application itself (§4) — the ~150-feature real-time client (wallet, lobby, bonus center, VIP, social, provably-fair verifier, responsible-gambling controls) that is the casino to the user. The second is the invisible operator back-office (§14) — a 15-plus-module admin panel for players, payments, bonuses, affiliates, risk, and analytics. Beneath both is a fifth load-bearing subsystem players only half-see: accounts, identity & responsible gambling (§13) — registration, authentication, KYC, limits, self-exclusion, geolocation. Each of these is as much engineering as the games, and you cannot run real money without at least their cores.

2Component optionality ranking

The single most useful lens on this system: most of what makes it look like Stake is optional. The mandatory core is small. Axis = can you ship and operate without it?

3System architecture

                         ┌─────────────────────────────────────────┐
                         │              Edge / CDN                   │
                         │  Cloudflare (DDoS, WAF, geo, bot mgmt)    │
                         └───────────────┬──────────────────────────┘
                                         │
            ┌────────────────────────────┼────────────────────────────┐
            │                            │                             │
     ┌──────▼──────┐            ┌────────▼────────┐           ┌────────▼────────┐
     │  Web/App     │  WS/REST  │   API Gateway    │  gRPC     │  Realtime / WS   │
     │ (Next/React) │◄─────────►│ (auth, rate-     │◄─────────►│  fan-out (NATS/  │
     │  + mobile    │           │  limit, routing) │           │  Redis pub/sub)  │
     └──────────────┘           └────────┬─────────┘           └─────────────────┘
                                         │
   ┌───────────────┬─────────────────────┼─────────────────────┬──────────────────┐
   │               │                     │                     │                  │
┌──▼───────┐  ┌────▼──────┐      ┌────────▼────────┐    ┌───────▼───────┐   ┌──────▼──────┐
│  LEDGER   │  │Wager engine│      │ Wallet / Chain  │    │  Aggregator   │   │ Sportsbook  │
│ (double-  │  │ + in-house │      │ Service (HD     │    │  Adapter      │   │  Adapter    │
│  entry,   │  │  games +   │      │ wallets, hot/   │    │ (seamless     │   │ (3rd party) │
│  balances)│  │  RNG)      │      │ cold, signing)  │    │  wallet API)  │   │             │
└──┬────────┘  └────┬───────┘      └────────┬────────┘    └───────┬───────┘   └─────────────┘
   │                │                       │                     │
   │           ┌────▼─────┐          ┌───────▼──────┐      ┌───────▼────────┐
   │           │ seed     │          │ Custody (MPC/ │      │ Game providers │
   │           │ commit/  │          │ HSM) + nodes/ │      │ (Evolution,    │
   │           │ reveal   │          │ RPC + indexer │      │  Pragmatic...) │
   │           └──────────┘          └───────────────┘      └────────────────┘
   │
┌──▼─────────────────────────────────────────────────────────────────────────┐
│  Cross-cutting: Accounts/Identity/KYC · Bonus/VIP · Anti-fraud/AML · Risk    │
│  Geolocation · Responsible-gambling limits · Notifications (email/SMS/push)  │
│  Event pipeline → data warehouse · Audit/significant-events log · Observability│
├──────────────────────────────────────────────────────────────────────────────┤
│  BACK-OFFICE / ADMIN (§14): players · payments · bonuses · affiliates ·       │
│  reports/graphs · risk · CMS · staff RBAC · PROVIDER SETTLEMENT (GGR rev-share)│
└──────────────────────────────────────────────────────────────────────────────┘

Cross-cutting services in the lower box are not optional plumbing details: accounts/identity (§13), the significant-events/audit log and event pipeline → warehouse (§17), and notifications are load-bearing subsystems referenced throughout. They’re drawn flat here because every vertical column depends on them.

4Player-facing application core TIER 0/1 depth TIER 2

The product the user actually touches — and the surface the original document omitted entirely. A mature crypto casino client is ~150 features across roughly a dozen areas. It is a real-time single-page app: one seamless balance, updated over WebSocket, shared across originals, slots, live, and sport. Below is the surface map drawn from the Stake / BC.Game / Shuffle help centers, tiered by how much you need at launch.

4.1 Surface map

4.2 Engineering notes

• One seamless balance, many surfaces. The client never holds authoritative money; it renders the ledger balance (§5) pushed over WS, and every surface (originals, an aggregated slot iframe, the sportsbook) debits/credits that same balance. Optimistic UI is fine for animation; the server is the truth.
• Provably-fair verifier is a player-facing feature, not just a backend property. The seed panel (client seed editable, server-seed hash shown before bets, nonce/cursor counters, rotate-to-reveal) and a standalone re-hash verifier are part of the trust pitch (§7, §8). Stake ships a public server-seed-unhash + HMAC-SHA256 reproducer.
• Geo & eligibility gate at render, not just at the edge. Game launch, deposit, and bet must respect jurisdiction state and self-exclusion/limit state returned by §13 — the client enforces what it can but treats the server as authoritative.
• i18n + local-currency display is table stakes: balances shown in the player’s fiat equivalent (needs the price oracle, §6), 15+ languages, regional payment methods.
• Responsible-gambling visibility is a UI requirement. Limit/self-exclusion controls and links to help must be reachable from any screen where play occurs; if help links are down, some standards say play must stop (§13.4).
• Heavy catalog caching + personalization (recommendation engine, recently-played, favorites) — the lobby is a high-read, low-write surface separate from the money path.

4.3 Reference-product observations

• Shuffle: public help pages show account verification tiers (email, basic information, ID, proof-of-address), deposits/withdrawals with confirmation-dependent deposits and irreversible blockchain withdrawals, a 50+ level VIP program with daily/weekly/monthly bonuses, rakeback and reloads, plus unusually explicit provably-fair implementation docs (byte generator, float generation, commitment/reveal).
• BC.Game: public help pages/search snippets show a broad wallet surface, VaultPro as an interest-bearing savings product, VIP/SVIP host workflows, daily/recharge/rakeback/weekly/monthly rewards, bonus wagering rules, account locks/self-exclusion, and original-game provably-fair verification.
• Stake: public help pages show Vault as a security/separated-storage feature, session/passkey/2FA controls, payments, casino/sports, bonuses/promotions and loyalty as first-class help-center categories. Do not project BC.Game's VaultPro yield semantics onto Stake's Vault.

5The money ledger TIER 0

The hardest correctness problem in the system. You are running a multi-asset bank with adversarial users; a single double-spend or lost-update is a direct, unrecoverable loss.

Non-negotiable design: true double-entry, append-only

Never store balance as a single mutable integer you UPDATE. Store append-only ledger transactions made of balancing ledger lines; balance is a derived (and cached) sum.

ledger_transactions
  id                 (monotonic)
  type               (deposit, withdrawal_hold, withdrawal_settle, bet, payout, bonus, rollback, adjustment)
  ref_type / ref_id   (chain tx / provider txn / game round / admin action)
  idempotency_key    UNIQUE
  status             (posted, reversed, voided)
  created_at

ledger_lines
  id
  transaction_id
  account_id         (player, house, provider_payable, bonus_liability, jackpot_pool, fee, onchain_inventory...)
  asset              (BTC, ETH, USDT...)
  balance_bucket     (withdrawable, bonus_locked, withdrawal_hold, vault, promo, provider_settlement...)
  amount             (signed integer minor units — NEVER float)
  created_at

Invariant: for each ledger_transaction, the sum of all ledger_lines.amount per asset equals zero. A bet moves value from player withdrawable balance to house/game clearing; a payout moves value back; a withdrawal moves player funds into a hold, then settles the hold against on-chain inventory. Money is conserved by construction because every credit has an equal debit.

The five invariants

1. Atomicity — all ledger lines for one money event are committed in one DB transaction. Instant in-house games may debit stake and credit payout in one transaction; aggregated content often arrives as separate bet, win, and rollback callbacks, each atomic and linked by round/transaction ids.
2. Idempotency — every mutating op carries an idempotency key; retries (network, provider callbacks, chain reorgs) must not double-credit. Essential for crypto deposits and aggregator callbacks, which retry aggressively (§9).
3. No spendable negative balance — enforced at write time (conditional update / serializable isolation / row lock), not read-then-write. Under concurrency this is the classic lost-update bug. One provider-specific exception is a correction_debit after resettlement: model it explicitly as a negative receivable / recovery balance, not as an invisible overdraft.
4. Integers only — satoshis, wei, micro-USDT. Floats anywhere in the money path is a defect.
5. Auditability — reconstruct any balance at any timestamp from the log alone; reconcile against on-chain holdings daily.

6Crypto wallet, custody & payments TIER 0 hardening TIER 1

Unified (seamless) wallet — one balance, many consumers

There is exactly one player balance (the custodial ledger, §5). Every content source — in-house games and every third-party provider — debits and credits that same balance in real time; providers never hold player funds. This is the “seamless wallet” model, as opposed to the legacy “transfer wallet” where players manually move funds into a per-provider sub-wallet.

Deposits

• Unique deposit address per user per chain via HD wallets (BIP-32/44 from a master xpub), or memo/tag on memo chains (XRP destination tag; EOS/XLM/Hedera memo), or per-user vault addresses.
• A chain indexer watches for incoming txs, matches them to users, and waits for a per-chain confirmation threshold before crediting. In a custody platform this is the deposit-control / confirmation policy: the deposit counts toward available balance only once it “clears” — that is the credit trigger.
• Reorg handling: a credited-then-orphaned deposit must roll back idempotently. The confirmation threshold is the primary mitigation — higher depth on high-value credit paths trades latency for safety.
• Sweeping from per-user addresses into an omnibus/hot vault, with gas management — the classic “USDT-TRC20 stuck because no TRX for gas” problem. A gas-station pattern auto-funds the base asset before sweeping ERC-20/TRC-20 tokens.

Withdrawals

• Hot wallet signs; cold wallet (multi-sig / policy) holds the majority of reserves. With MPC custody the hot/cold distinction is where the signing key-share lives — an automated co-signer (hot, 24/7) vs an air-gapped device (cold).
• Pipeline: request → risk/AML → (auto-approve under threshold | manual review over) → sign → broadcast → confirm → settle. Idempotent at every step — a double-broadcast is a double payout (carry an externalTxId-style permanent dedup key).
• Dynamic fee estimation per chain; batching to save fees (e.g. multi-destination BTC txs every ~30s).
• Key management: HSM or MPC custody. Private keys never on app servers.

6.1 Custody model (Fireblocks-class infrastructure)

Whether you run your own nodes + HSM or use a custody provider, the object model is the same and worth naming explicitly:

• Vault account — an on-chain wallet whose keys are MPC-secured. Two structuring patterns: segregated (one vault per end-user) or omnibus (pooled). Casino intake topology is usually: per-user intermediate deposit vaults → sweep into an omnibus deposits vault → fund a withdrawal pool (the hot float).
• Asset wallet (one per asset in a vault) → one or more deposit addresses (multiple on UTXO chains; static address + rotating tag/memo on memo chains).
• Hot vs cold = which device holds the final MPC key-share: an API co-signer (automated) vs an air-gapped, QR-approved device.

6.2 Withdrawals at scale

A single hot wallet is a throughput and stuck-transaction bottleneck. The at-scale pattern:

• Withdrawal pool: spread requests round-robin across several withdrawal wallets. Rough sizing per 1 TPS of withdrawals: ~5–6 wallets on EVM, 2–3 on Bitcoin, ~2 on Solana/TRON (with parallel txs), ~10 on Stellar (one tx per account per ledger).
• Stuck transactions: monitor the queue; if a tx sits unconfirmed beyond a window (~2h), cancel/resubmit; use RBF / CPFP to unstick low-fee txs; respect the Bitcoin 25-tx unconfirmed-chain limit (apply CPFP before hitting it). On EVM, manage nonces (reuse on unmined failure) and watch for txs stuck in CONFIRMING.
• Gas station: a designated vault auto-fuels base asset (with a gasThreshold / gasCap / maxGasPrice) so token sweeps and payouts don’t fail for lack of gas.

6.3 Authorization policy (the money-out control surface)

Withdrawal safety is a policy-engine problem, not an if amount > X check. A transaction-authorization policy evaluates rules top-down, first match wins, default-deny:

• Per-rule: action (allow / block / route to N-of-M approval), asset, amount threshold (single-tx or aggregated over a time window), source, destination, and destination-address type (whitelisted vs one-time).
• Whitelisted destinations (internal / external / contract) require an admin-quorum approval to add; one-time addresses (needed for arbitrary player payouts) bypass per-address approval but should be gated behind a strict rule (specific signer group + amount cap).
• Separation of duties: the initiator (operator) ≠ the approvers (authorization group) ≠ the designated signers; “operator-as-authorizer” disabled enforces four-eyes. Policy changes themselves require admin-quorum (hardware-MFA).
• AML screening hook: a PENDING_AML_SCREENING stage where a chain-analysis provider verdict gates progression (§13.3, §15).

6.4 Transaction lifecycle & webhooks

Deposits and withdrawals move through an explicit status machine you consume via webhooks. A representative lifecycle:

SUBMITTED → PENDING_AML_SCREENING → PENDING_ENRICHMENT → PENDING_AUTHORIZATION
          → QUEUED → PENDING_SIGNATURE → BROADCASTING → CONFIRMING → COMPLETED
terminal-negative: BLOCKED (policy) · REJECTED · FAILED · CANCELLED

• Webhook handlers must be idempotent (dedupe on tx id + status; webhooks retry).
• Reconciliation hazard to design for: a withdrawal can land COMPLETED_BUT_3RD_PARTY_FAILED / _REJECTED — the on-chain send succeeded and funds left the vault even though a downstream step failed. These must be reconciled explicitly or you silently lose money on the books.

6.5 Pricing & reconciliation

• Balances are per-asset; UI often shows USD-equivalent → a price oracle is needed. Stablecoins (USDT/USDC) are the dominant volume and simplify this.
• A daily job proves sum(on-chain holdings) ≥ sum(user liabilities). Any drift is a P0. This is the single most important operational safeguard, and it ties wallet + ledger together (§18 flow vi).

7Original games TIER 2 — OPTIONAL

7.1 The thin shared substrate (not a game)

Everything “provably fair” reduces to one deterministic function: RNG(serverSeed, clientSeed, nonce, cursor) → stream of floats in [0,1).

• serverSeed — 32 random bytes. Publish only SHA256(serverSeed) before any bet (the commitment).
• clientSeed — player-owned string; their entropy.
• nonce — +1 per bet, atomic, strictly monotonic.
• cursor — byte offset for games needing > 32 bytes (a 52-card shuffle, 16-row Plinko, 25-tile board).

// byte stream: chain HMACs by round index
function* byteStream(serverSeed, clientSeed, nonce) {
  let round = 0;
  while (true) {
    const d = hmacSha256(serverSeed, `${clientSeed}:${nonce}:${round}`); // 32 bytes
    for (const b of d) yield b;
    round++;
  }
}
// 4 bytes -> uniform float, base-256 positional
function bytesToFloat(b) {
  let f = 0;
  for (let i = 0; i < 4; i++) f += b[i] / Math.pow(256, i + 1);
  return f; // [0,1)
}

Selection over a finite set uses a Fisher–Yates shuffle driven by the stream; any non-power-of-two integer draw uses rejection sampling, never modulo (modulo bias is an exploitable fairness defect). On seed rotation the old serverSeed is revealed; a public verifier re-hashes it (must equal the commitment) and replays every outcome with the same code.

Fairness invariants (and how they break)

1. Commit SHA256(serverSeed) before the first bet; never mutate the seed in use.
2. nonce strictly monotonic per seed pair, enforced atomically.
3. Outcome derivation is pure — a function of (serverSeed, clientSeed, nonce, cursor) only. No wall-clock, no post-bet input.
4. No modulo bias anywhere randomness maps to a finite set.
5. The verifier uses the same code path as production — drift is the classic silent-cheat surface.

Note: provable fairness is the crypto-casino alternative/supplement to traditional certified-RNG. The public standards still expect server-side-only outcome generation, RNG strength against state-compromise/known-input attacks, and statistical testing (§8.1) — provable fairness gives the player self-verification on top.

7.2 The shared wager engine (the real reusable layer)

This — not fairness — is the engine worth factoring out. Every game runs the same lifecycle:

1. validate bet (limits, balance, RG limits, session)
2. atomically DEBIT stake        (idempotency_key = bet_id)
3. nonce = next(seedPair)         (atomic increment)
4. outcome = game.resolve(rng(...), betParams)
5. payout  = game.payout(outcome, betParams)   // house edge baked in
6. atomically CREDIT payout (if > 0)            (same bet_id txn)
7. record bet (seeds-hash, nonce, params, outcome, payout)  // replay/dispute

Shared concerns that live here: limits & max exposure (cap max payout per round so one hit can’t blow the bankroll), autobet (the main ledger-load multiplier), deterministic replay, and the real-time fabric for shared-round games.

7.3 The intellectual core: house-edge / RTP / exposure

The genuinely hard part — and nothing to do with crypto. For each game you design the payout function so that:

• RTP is exact and provable: RTP = Σ P(outcome)·payout(outcome) must equal (1 − edge) across every legal bet config (every dice target, every Plinko risk level, every mine count).
• Variance is intentional: big-multiplier tails are a design choice with a bankroll consequence.
• Max single-round exposure is bounded so the tail is survivable. Actuarial work — you size limits from the payout distribution.

For any single-outcome game the fair multiplier is just (1 − edge) / P(win). The work is in multi-outcome games where you shape a whole distribution.

7.4 Per-game summary

8Game session & round integrity TIER 1

A layer the original document skipped: the rules every game round must obey regardless of who built it. These come straight out of the public iGaming technical standards (GLI-19 / Delaware) and they constrain in-house games and shape how you consume aggregated content. They are the difference between “the math is right” and “the round survives a disconnect, a crash, and a dispute.”

8.1 Outcome authority & RNG

• Outcome is generated server-side only. The client contains no result logic; randomness comes from an approved RNG (or the provably-fair substrate, §7) independent of the player device. This is also what makes replay-for-dispute possible.
• RNG strength & testing. Resist known-input and state-compromise-extension attacks (don’t seed from clock alone; re-seed from external entropy); pass standard statistical batteries (chi-square, runs, serial correlation, coupon-collector…) at high confidence. In-house games typically need RNG/fairness certification (GLI / iTech Labs) before a regulated launch.
• No adaptive payout / no “near-miss.” Outcome likelihood must not change with payout history; a losing outcome can’t be swapped for a different displayed losing outcome.

8.2 RTP & fairness bounds

• Minimum theoretical RTP (standards default ~75% for house-banked games) met at every wager configuration — ties directly to §7.3.
• Advertised long-odds rule: the highest advertised chance-based award must be reachable (default ≥ 1 in 100,000,000) or the true odds shown.
• Paytable & rules accessible without depositing or wagering; min/max bets stated; where RTP is shown, explain how it’s derived.

8.3 Mandatory in-session display

During play the client must surface, at minimum: current funds available to wager; current wager amount + active wagers; and for the last completed game — the outcome and amount won. The credit meter is shown whenever a wager can be placed; restricted/bonus credits are wagered before unrestricted funds (§5 callout).

8.4 Game recall / history

Every round must be reconstructable and re-presentable as a labeled replay: date/time, stake (incl. bonus), outcome, funds before/after, player choices, intermediate phases, and any jackpot award. Bonus/feature rounds retain at least the last ~50 events. This is the dispute-resolution substrate and feeds the per-game log (§17.2).

8.5 Interrupted-game recovery load-bearing

This applies to stateful originals (Mines mid-board, Blackjack mid-hand, a Crash position) and to aggregated games — where you handle it via the provider’s rollback and round-status semantics (§9). Either way it must be idempotent against the ledger.

8.6 Autoplay, demo & jackpots

• Autoplay: defaults to manual; player sets per-spin stake, count, and total spend; must auto-stop at the player’s threshold and offer stop-after-current-game. (Autobet is also the ledger’s main load multiplier — §7.2.)
• Demo / play-for-fun: must be clearly flagged, must accurately represent the real game, and must never touch the real credit meter or fire money-moving seamless callbacks. Keep demo on a wholly separate path from the ledger.
• Jackpots: display the live value (standards: refresh ≥ every 30s), no truncation on win, winner notified by round end. Mystery/multi-level/network jackpots with bet- and time-based triggers are a Tier-2 differentiator (§14).

9Aggregated content & the seamless wallet TIER 1

You will not build slots or live dealer — you integrate them. This is the default game catalog and the reason originals are optional.

• Aggregator (SOFTSWISS Game Aggregator, Slotegrator, EveryMatrix, Hub88) → one integration to tens of thousands of games from hundreds of studios/providers (Evolution, Pragmatic, Hacksaw, BGaming, etc.).
• Game launch: request a signed launch URL with a session token, iframe it; the provider handles rendering + RNG + certification.

The novel engineering is not the games — it’s implementing the money callback contract correctly and idempotently. The original doc summarized this as “/bet, /win, /rollback, HMAC.” The real contract is more demanding. Hub88, St8, 568win and similar integrations differ in endpoint names, signature schemes, amount scaling, status codes, token rules and rollback behavior; your platform should implement a provider adapter per integration and normalize those callbacks into one internal wallet protocol.

9.1 The callback contract (operator-hosted endpoints)

The provider/aggregator is the client; you expose signed callbacks it calls on every money event:

9.2 Idempotency — two levels, not one

• Money-movement key (transaction_uuid / transaction_id / transferCode): an action with the same key must never be processed twice. This is the exactly-once guarantee on the ledger.
• Request key (request_uuid): dedupes the HTTP call — a duplicate must return the identical stored response (same balance/status), not reprocess.
• Retain transaction ids and old session tokens for months: a late credit or cancel may reference a token a week or more old, and a rollback may arrive for a transaction you never recorded as succeeding → handle rollback-of-unknown as an idempotent no-op.

9.3 Authentication & money semantics

• Signature over the whole body — examples include RSA-SHA256 (Hub88) and ECDSA P-256 (St8), per a key bound to your operator id, often plus an IP allowlist. Verify the entire payload, not just known fields, and don’t reject unknown fields — providers add fields without notice.
• Amount representation differs per provider and is a top bug source: Hub88 sends an integer = value × 100000 (so $3.56 → 356000); other providers send decimal strings or their own minor-unit scale. Agree and pin the scaling per integration.
• Currency is fixed for the life of a session token; a currency change requires a new token and relaunch.
• Correction-debit exception: some provider/sports resettlement flows require a correction_debit even when the player cannot cover it. Do not let this make normal spendable balance semantics fuzzy; post it to an explicit receivable/recovery bucket or a controlled negative sub-balance and still reconcile it as provider-driven correction (§5).

9.4 Round lifecycle, status codes & the rollback rule

• Round is the linking entity: all debits/credits of one round share a round id; the final transaction carries round_closed: true (there is usually no separate “round end” endpoint). Multi-bet and cumulative-bet rounds are supported.
• Status codes are an enumerated contract (e.g. RS_OK, RS_ERROR_NOT_ENOUGH_MONEY, RS_ERROR_INVALID_TOKEN, RS_ERROR_DUPLICATE_TRANSACTION, RS_ERROR_LIMIT_REACHED…). Return the right one — provider behavior branches on it.
• The rollback-trigger rule: the provider rolls a bet back on network failure/timeout or any non-OK status except insufficient-funds and limit-reached (those are clean business declines). So a flaky/slow wallet doesn’t just degrade UX — it generates rollbacks.

9.5 Reconciliation hooks & settlement

Providers expose a transactions/round list pull (by time range / round / user) for reconciliation — store every callback yourself and reconcile against it. That feeds the B2B layer:

Operator ↔ provider settlement (the B2B money layer)

Distinct from the player wallet, and easy to forget. Per bet, no funds move to the provider — their game server calls your seamless wallet to debit/credit the player’s balance. The money you owe providers is settled separately, B2B:

• You record every provider transaction yourself (per game, per provider) and compute GGR (and NGR after bonuses) per provider.
• Providers/aggregators bill on a revenue-share (a % of GGR) or fixed-fee basis, usually monthly; they issue reports/invoices.
• Reconciliation: their numbers vs your internal records, per provider, every cycle. Discrepancies are chased — a standing back-office function surfaced in the admin panel (§14) and flow §18(vi).
• Some providers require a prepaid float / minimum balance held with them; you manage that liquidity and top it up.

So the “seamless wallet that pays different providers” is two mechanisms: real-time player-balance callbacks (per bet) + periodic GGR rev-share settlement (B2B). Conflating them is a common modelling error.

10Sportsbook TIER 2 — OPTIONAL

Almost always a turnkey provider (BetBy, Digitain, Altenar) integrated like the aggregator: their odds engine + trading + settlement, your wallet + identity. In-house (rare, very expensive) means real-time odds feeds, a risk engine, bet-slip + cash-out logic, automated settlement, and a trading team — a whole company on its own. Note the sportsbook reuses the seamless-wallet contract (§9), including correction_debit/credit for odds resettlement and bet-builder/cash-out as multi-leg round semantics.

11Real-time tier TIER 2 — coupled to originals

• WebSockets for: Crash ticks, live bet feed, chat, balance updates, sports odds, leaderboards.
• Pub/sub backbone (Redis Streams / NATS / Kafka) decouples producers (game engines) from WS fan-out. Scale gateways horizontally; never let engines hold per-client sockets.
• The tightest latency budget in the system is Crash cashout — the player’s request is stamped against the server-authoritative multiplier and rejected if the round already busted. Client animation is cosmetic.

12Bonus / VIP / gamification TIER 2 — OPTIONAL

Retention machinery — the main reason crypto players stay. It is tightly coupled to the ledger (locked balances), the anti-fraud engine (abuse), and the back-office (campaign builder). The surface is broad; vendor platforms ship all of it.

12.1 Bonus & reward taxonomy

• Deposit-linked: welcome / first-deposit match, reload (daily/periodic), no-deposit, deposit-fee cashback.
• Loss/volume-linked: rakeback (% of house edge, often instant per-rake), cashback / lossback, VIP weekly/monthly bonuses, level-up bonuses.
• Free rounds: free spins (incl. provider-native / “unified” free spins aggregated across studios), free bets (sportsbook), risk-free bet.
• Code/drop: promo / “bonus drop” codes, flash-drops / coin-drops in chat, redeemable links.
• Event: daily/weekly races + leaderboards, raffles, tournaments, quests/challenges, lucky-wheel/daily-spin, lootbox.

12.2 Accounting & wagering requirements

• Each needs wagering requirements, eligibility rules, schedules, budgets, and separate locked-balance accounting (bonus vs withdrawable) inside the ledger (§5). Restricted credits are wagered first.
• Real products expose detailed rollover semantics: contribution weighting by game/edge, max bet while wagering, expiry windows, restricted games, withdrawal/vault/tip restrictions while rollover is active, user-initiated cancellation/forfeiture, and special rules for free spins/free lottery prizes. These are product rules, but they become ledger and eligibility rules immediately.
• A unified bonus system spanning casino + sportsbook on one balance is the mature shape; an event-triggered bonus API lets an external CRM grant bonuses on arbitrary events without redeploying.

12.3 Gamification & loyalty

• VIP tiers (wager-volume / XP driven; Shuffle publishes 50+ levels; BC.Game exposes regular and SVIP reward tracks), spendable loyalty currency + a loyalty shop, missions/challenges, tournaments & leaderboards, mini-games (lucky wheel / prize engine), and bet-/time-triggered mystery & network jackpots.

12.4 Abuse — the coupled threat

• Vectors: multi-accounting to farm signup/no-deposit bonuses, bonus-then-withdraw, collusion via tips/rain to a clean account, arbitrage of wagering-requirement gaps.
• Serious platforms run a bonus-abuse guard (rules plus pattern detection wired into the PAM) alongside the anti-fraud engine (§15). Vendors may market this as AI, but the product requirement is concrete: detect multi-accounting, coordinated rollover abuse, arbitrage loops, abnormal bonus cancellation, and value movement to clean accounts.

13Accounts, identity & responsible gambling core TIER 0/1

The subsystem the original document scattered into a single 2FA bullet. It is its own product: registration, the account state machine, authentication, KYC, responsible-gambling enforcement, and geolocation. Most of it is mandatory to operate real money, and the public standards specify it in detail — presented here as engineering requirements (what the platform must do), not as a licensing position.

13.1 Account lifecycle & states

• Registration: capture the chosen baseline fields; mark fields required/optional; record acknowledgements (terms, privacy, monitoring consent, PII-accuracy) with timestamps. Age-gate on submitted DOB.
• Verification model split: regulated standards commonly require identity verification before real-money play; crypto/offshore products often use tiered verification where email/basic information unlocks basic use and ID/proof-of-address is triggered by withdrawal, volume, risk, bonus or source-of-funds thresholds. Pick the operating model deliberately and make it a state machine, not ad hoc checks. Government-ID numbers stored encrypted.
• One active account per player; store previous accounts + reason for deactivation (feeds dedup / linking).
• State machine: registered → active (after verification + acceptances) → {suspended, self-excluded, dormant, closed}. Dormant re-access requires additional identity verification; closure refunds the cleared balance (unless under a temporary exclusion); fraudulent accounts are suspended.

13.2 Authentication & access

• Failed login returns a generic error (no credential enumeration). Lockout on suspicious activity (default ~3 failed attempts / 30 min); unlock via MFA.
• MFA-gated sensitive actions: credential reset, and changes to credentials / registration info / financial account.
• Idle timeout (~30 min) forces re-authentication; even with biometric/PIN shortcuts, full re-auth at least every ~30 days.
• EFT-fraud throttle: temporarily block after ~5 consecutive failed funding attempts in 10 min; suspend after another ~5.
• Player-facing: 2FA/TOTP setup + recovery, active-session list + revoke, login history, withdrawal-address whitelist, and a last-login-time display so players can self-detect misuse (§4).

13.3 KYC / AML

• Tiered KYC (Shuffle/Stake-style): email verification → basic information (legal name, DOB, address, occupation) → government-ID / selfie liveness (Sumsub/Jumio) → proof-of-address / source-of-funds at larger volumes or higher-risk events. Which tier gates play vs withdrawal is an operator/product decision constrained by jurisdiction and provider requirements.
• AML: detect structuring (deposits/withdrawals split to dodge thresholds), screen deposits/withdrawals with chain-analysis (§15), and gate withdrawals through the authorization policy’s AML stage (§6.3).
• Funds handling rules that shape the schema: segregate player funds (no commingling); confirm/deny every financial transaction with a reason; restrict player-to-player value movement. If tips/rain/send are offered, treat them as a controlled social-transfer subsystem with 2FA, limits, abuse checks, AML/risk review, ledger entries and audit logs — not as arbitrary balance transfer.

13.4 Responsible gambling (enforcement, not just UI)

• Limit types: deposit, wager/turnover, loss, and session-duration limits; cool-off (“break in play”); self-exclusion. Enforced server-side in the ledger/session layer, never only in the client.
• Asymmetric changes: tightening a limit applies immediately; loosening (or removing) takes effect only after a delay (~24h). The stricter of operator- and player-set limits always wins.
• Self-exclusion: temporary (defined period) or indefinite; on order, immediately stop accepting new bets and deposits; still allow withdrawal of cleared funds; exclude the player from all marketing; define handling of undecided wagers at the exclusion point.
• Always reachable: an RG page/controls accessible from any play screen, with help-service links that are monitored — some standards require play to stop if those links are down.

13.5 Geolocation & eligibility

• Hard geo-block of prohibited jurisdictions is Tier 0 — at the edge (§15) and re-checked in the account/session layer.
• For licensed/regulated operation the standards go further: a location check before the first game after login, re-checks on IP change and at least every ~30 min, a confidence radius that must sit entirely inside the permitted boundary, plus VPN/proxy/VM detection and impossible-travel flagging. A crypto/offshore build won’t implement all of it, but the block-prohibited-geos core is non-negotiable.

14Operator back-office / admin panel core TIER 1 depth TIER 2

The largest piece of the platform players never see — commonly 15+ modules, and frequently as much code as the player-facing app. A minimal operations console is mandatory to run real money; the full CRM/bonus/affiliate/analytics suite is where a lot of the actual engineering goes and grows mandatory at scale. The module list below is triangulated across SOFTSWISS, EveryMatrix, and SoftGamings.

14.1 Typical modules

14.2 Engineering notes

• Every money-moving admin action (balance adjust, withdrawal approval, bonus grant) needs RBAC + an immutable audit trail + ideally maker-checker (second-person approval). Internal fraud is a real, primary threat — the admin panel can move funds.
• The analytics/reporting half is a data-warehouse problem — ETL from the transactional DB into an OLAP store / read replica, not queries run against the live ledger (§17.4).
• It is the single most under-scoped surface in “build a casino” estimates; budget for it like a second product.

15Security & anti-fraud

• Edge T0: Cloudflare (constant DDoS target), WAF, bot management, rate limiting.
• Account security: 2FA (TOTP), withdrawal whitelists, email/withdrawal/login locks, device/session tracking, generic-error + lockout login (§13.2).
• Anti-fraud / AML: multi-accounting detection (device fingerprint, IP clustering, deposit-graph analysis), chain analysis on deposits/withdrawals, velocity/exposure limits, anomaly + collusion detection, bonus-abuse guard. basic T1 / advanced T2
• The crypto wallet is the crown jewel — key compromise = total loss. MPC/HSM, withdrawal authorization policy (§6.3), hot-float minimization, alerting on every outflow, address whitelisting vs one-time-address split.
• Internal threat: admin tooling that can move money needs separation of duties, full audit logging, and second-person approval on money-moving actions (§14.2, §17.3).

16Compliance — as a technical constraint parts TIER 0

Even treated purely as engineering, these shape the schema and the money path, so they’re designed in, not appended. Most of the mechanics live in the sections cross-referenced below — this is the index:

• Licensing (Curaçao, Anjouan…) dictates KYC/AML obligations, RNG certification, responsible-gambling features, and geo-restrictions — hard-block prohibited jurisdictions at the edge + at the account layer (§13.5).
• KYC pipeline (ID + liveness) gated on withdrawal thresholds (§13.3).
• Responsible gambling: limits, self-exclusion, cool-off — enforced server-side (§13.4).
• Fairness / RNG certification (GLI/iTech Labs) for in-house games, plus the game-session integrity rules (§8).
• Records, logging & retention (§17) — the standards’ logging/reporting/retention chapters are effectively a spec for an auditable system.

17Logging, audit, reporting & retention TIER 1

Absent from the original document, and the part of the public standards that reads most like a system spec. You cannot resolve a dispute, reconcile a discrepancy, pass an audit, or prove fairness without a queryable, tamper-evident record of what happened. Treat this as a first-class subsystem, not logging-as-an-afterthought.

17.1 One clock

A single system clock is the time source for all time-stamping (transactions, game rounds, significant events) and the reporting reference; all components are time-synchronized, and a change to the master time is itself a logged event. Stamp everything UTC.

17.2 The log set

• Per-game / per-round log: date/time, stake (incl. bonus), final outcome, funds before/after, player choices, intermediate phases, rake/fees, jackpot contribution/award, status (in-progress / complete / interrupted / cancelled), and unique round id / session id / player id / paytable id. This is the §8.4 recall substrate.
• Player account record: identity (PII clear-scope; ID numbers/credentials/financial instruments encrypted), verification date/method, acceptances, balance incl. separated restricted/expiring credits, previous accounts + deactivation reason, exclusion/limit entries, and every account access (player or staff) with date/time + IP.
• Financial-transaction log: type, date/time, unique transaction id, amount, balance before/after, fees, handling user, status, method, and the deposit authorization number.
• Significant-events log: failed logins (with IP), program errors, critical-component unavailability, large wins/wagers (single + aggregate), config/parameter changes (game rules, payouts, rake, jackpot, incentive, security settings), balance adjustments, PII changes, account deactivations, negative balances, time changes.
• Staff access log: user, function set, create/disable dates, last access (with IP), last password change, group, status.

17.3 Tamper-evidence & immutability

Append-only; alterations to accounting/reporting/event data only via supervised controls and themselves logged with before-value, after-value, element, time, and user. Keep the audit store separated from the operational DB (WORM / hash-chaining is the common implementation). No mechanism may auto-clear data on error.

17.4 Reporting

Generate reports on demand, daily, and over MTD/YTD/LTD intervals; each report carries operator id, title, interval, generation time, a “no activity” indicator, and is exportable (CSV/XLS). The standards-named set: Game Performance (theoretical vs actual RTP, wagers/wins/voids, rake, funds held in interrupted games), Operator Liability (total held for players), Large Jackpot Payout, and Significant Events & Alterations (with before/after values). Build these off the warehouse (§14.2), not the live ledger.

17.5 Retention

• Core records / logs: ~5 years (GLI-19 baseline; some jurisdictions extend to 7).
• Player-facing transaction/game history: at least the past year on demand.
• Chat logs & player↔operator email: ~90 days.
• State the PII retention period in the privacy policy — and reconcile it against any right-to-erasure obligations.

17.6 System integrity & recovery

• Control-program self-verification of critical components at least every 24h and on demand (cryptographic hash, ≥128-bit digest); block gaming on failure.
• Daily backups to separate secured media; redundancy so no single failure loses audit data; on recovery, components re-sync with no lost or duplicated transactions; if a round can’t be fully recovered, void/refund it (§8.5).
• Change management: record every install/modification (what, who, authorizer, version, rollback plan); keep production logically + physically separated from dev/test.

18Operational flows / lifecycles

The seven end-to-end sequences that tie the sections together. Each names where idempotency, authorization, and logging live — the recurring failure points.

player requests deposit address
  → wallet derives per-user address (HD) / tag-memo  [§6]
on-chain tx arrives
  → indexer matches tx → user → asset
  → wait for confirmation threshold (reorg safety)   [§6 deposit]
  → on "cleared": atomic CREDIT ledger (idempotency_key = tx hash)  [§5]
  → notify player; tx visible in history             [§4, §17.2]
  → sweep address → omnibus (gas-station fuels fee)  [§6.1]

player requests withdrawal (address, network, amount, 2FA)  [§4, §13.2]
  → RG / limit / self-exclusion check                      [§13.4]
  → debit ledger to a pending/hold entry (idempotent)      [§5]
  → authorization policy: AML screen → amount rule →
        auto-approve | route to N-of-M manual review       [§6.3, §14]
  → sign (hot co-signer) → broadcast → confirm             [§6.2, §6.4]
  → on COMPLETED: settle hold; on FAILED/REJECTED: refund
  → watch COMPLETED_BUT_3RD_PARTY_FAILED (funds left!)     [§6.4]
  → log significant event if large / adjusted              [§17.2]

provider → POST /bet  (signed, transaction_uuid, round)     [§9.1–9.3]
  → verify signature over whole body + IP allowlist
  → dedupe: transaction_uuid (money) + request_uuid (HTTP)
  → balance check; insufficient → decline status (NO rollback)
  → atomic DEBIT; respond {status, balance} fast (≈ low-tens ms) [§9.4]
provider → POST /win (may be 0; round_closed=true)
  → dedupe → atomic CREDIT → respond balance
on void/timeout → provider POST /rollback (ref = original)
  → reverse referenced txn; rollback-of-unknown = no-op      [§9.2]
all callbacks recorded for reconciliation                    [§9.5]

grant bonus → credit LOCKED/bonus sub-balance              [§5, §12.2]
  → set wagering requirement + eligibility + expiry
play: restricted credits wagered first; track turnover     [§8.3]
  → on requirement met: convert bonus → withdrawable
  → on expiry / breach / cancel: void remaining bonus
abuse checks run throughout (multi-acct, collusion)        [§12.4, §15]

staff initiates balance adjust / correction in admin       [§14]
  → RBAC permission check
  → maker-checker: second admin approves (money-moving)
  → atomic ledger entry (type=adjustment, ref, reason)     [§5]
  → SIGNIFICANT EVENT logged: before/after, element, user  [§17.2–17.3]
  → player notified if required

daily: pull provider transactions/round list  [§9.5]
  → match against your recorded callbacks (per provider)
  → compute GGR/NGR per provider
  → reconcile vs provider invoice (monthly rev-share)
  → flag discrepancies → back-office queue     [§14]
parallel: prove sum(on-chain) ≥ sum(liabilities) daily — drift = P0  [§6.5]

player disputes a round / balance via support     [§4, §14]
  → pull game-round log + replay (seeds, nonce, outcome)  [§8.4, §17.2]
  → provably-fair: re-hash server seed = commitment? replay outcome  [§7]
  → pull financial-transaction + access log (with IP)     [§17.2]
  → reconstruct balance at timestamp from append-only ledger  [§5]
  → resolve; record correspondence (retain ~5y)            [§17.5]

19Representative tech stack

20Build vs buy — the three paths

Stake / Shuffle / BC.Game sit toward the custom/hybrid end: they own a substantial player product, wallet/ledger surface, rewards system and original-game surface, while still relying on integrated third-party content for much of the catalog. The highest-leverage parts to build yourself are the multi-asset double-entry ledger, the crypto wallet/custody service, the provably-fair originals, the player app, and the Crash-class real-time engine. Everything else is integration — but note that “integration” still means building the operator side of the seamless-wallet contract (§9), the account/identity/RG subsystem (§13), the logging/reporting layer (§17), and the player client (§4) correctly. Those are not vendor gifts in the hybrid path.

21Phased roadmap (from scratch)

1. Foundations — auth/identity + account state machine, the double-entry ledger, internal transfer primitive, observability, audit/significant-events log. Get money correctness provable before any game touches it.
2. Crypto wallet service — one chain end-to-end (e.g. a stablecoin on TRON/ETH): deposit detection → confirmations → credit → withdrawal signing → reconciliation. Then add chains, then custody hardening (MPC/HSM, authorization policy).
3. Player client + content, fast path — the wallet/lobby/launch/history client (§4) + integrate an aggregator (seamless wallet callbacks, §9) + the provider-settlement ledger (GGR/rev-share reconciliation). This alone is a launchable casino.
4. Back-office core — the moment real users exist: player lookup, withdrawal-approval queue, balance adjust, ban/lock, RBAC + audit log. Mandatory ops; don’t defer.
5. Accounts/RG/KYC + geo-block + chain analysis — KYC tiers, server-side limits + self-exclusion, geo-block, withdrawal AML gate. Gate withdrawals before you scale deposits.
6. Originals (optional) — provably-fair substrate + wager engine + game-session integrity (recovery/recall); ship Dice + Limbo first (stateless).
7. Real-time tier — only if doing originals: WS gateway + pub/sub, then Crash and Mines/Plinko.
8. Bonus/VIP/gamification + anti-fraud — built together (locked-balance accounting + abuse guard).
9. Reporting/warehouse — ETL to OLAP, the standards-named reports, retention windows.
10. Sportsbook — integrate a turnkey provider.
11. Hardening — MPC/HSM custody at scale, withdrawal pools, DDoS, pen-test, RNG certification, reconciliation automation, on-call/runbooks.

The order is deliberate: money correctness → custody → client + content → ops → identity/RG → fairness → real-time → retention → reporting → scale. Every later stage assumes the ledger underneath it is provably correct and every event is logged.

22Sources & standards map

What each cluster of claims was checked against. Standards are used as an engineering completeness checklist; numeric thresholds are representative defaults, frequently overridable by a specific jurisdiction or provider.