Crash

Overview

Property	Value
Slug	crash
Round type	Single-step (per player)
RTP	100% − house_edge (configurable 1%–10%, default 3%)
Volatility	High
Devices	Desktop, Mobile
Provably Fair	Yes
Multiplayer	Yes — shared round, independent bets

Crash is a multiplayer game where a multiplier rises from 1.00x and can “crash” at any moment. Players place bets before the round starts and must cash out before the crash. The longer they wait, the higher the multiplier — but if the crash happens first, they lose their bet.

---

Game Mechanics

How It Works

1. Betting phase — players place bets (up to 2 bet slots per player per round) during a countdown
2. Running phase — the multiplier starts rising from 1.00x
3. Cashout — players can manually cash out at any time, locking in the current multiplier
4. Crash — at a random point (determined by provably fair algorithm), the multiplier crashes. All players who haven’t cashed out lose their bets

Multiplier & House Edge

The raw crash point is determined by a provably fair algorithm. Each operator has a configurable house edge (1%–10%) that reduces the effective multiplier:

effective_multiplier = raw_crash_point × (1 − house_edge)

Example (3% house edge):

• Raw crash point: 2.50x → Effective: 2.425x
• Raw crash point: 10.00x → Effective: 9.70x
• Raw crash point: 1.01x → Effective: 0.9797x (player loses)

Bet Slots

Each player can place up to 2 bets per round (slot 1 and slot 2), each with an independent amount and optional auto-cashout multiplier. Each bet gets its own round_id and is settled independently.

Auto-Cashout

Players can set an auto-cashout multiplier when placing a bet. If the rising multiplier reaches this threshold, the system automatically cashes out the bet.

---

Round Flow

Crash settles one round per player bet — each bet has its own round_id with one bet and optionally one win:

sequenceDiagram
    participant Player A
    participant Player B
    participant Game as Crash Game
    participant Beexar
    participant Wallet as Operator Wallet

    Note over Game: Betting Phase (countdown)
    Player A->>Game: Bet $10 (slot 1)
    Game->>Beexar: Place bet (round_id=ra-1)
    Beexar->>Wallet: POST /betwin (round_id=ra-1, bet=10, finished=false)
    Wallet-->>Beexar: { balance: "490.00", transactions }

    Player B->>Game: Bet $50 (slot 1)
    Game->>Beexar: Place bet (round_id=rb-1)
    Beexar->>Wallet: POST /betwin (round_id=rb-1, bet=50, finished=false)
    Wallet-->>Beexar: { balance: "950.00", transactions }

    Note over Game: Running Phase — multiplier rising
    Player A->>Game: Cash out at 2.40x
    Game->>Beexar: Win (round_id=ra-1)
    Beexar->>Wallet: POST /betwin (round_id=ra-1, win=24, finished=true)
    Wallet-->>Beexar: { balance: "514.00", transactions }

    Note over Game: CRASH at 3.50x
    Note over Game: Player B did not cash out — loses bet
    Beexar->>Wallet: POST /finish (round_id=rb-1)
    Wallet-->>Beexar: { balance: "950.00" }

Key Difference from Other Games

In crash, the round is shared among all players, but each player’s bets are independent:

• Each bet gets its own unique round_id
• Each bet generates its own /betwin (and /finish when the bet was not already closed by finished: true)
• The operator sees individual player rounds, not one massive shared round

---

Wallet Flow per Bet

Outcome	Wallet Calls
Player cashes out	/betwin (bet) → /betwin (win, finished=true)
Player loses (crash)	/betwin (bet) → /finish
Auto-cashout triggered	/betwin (bet) → /betwin (win, finished=true)
Bet error (wallet failure)	/betwin fails → bet voided, /rollback sent asynchronously

The request/response shape of these calls is the same for every game — see the Wallet API for full field references and examples.

---

Configuration Parameters

Operators configure crash games in the Beexar backoffice:

Parameter	Type	Default	Range	Description
house_edge	float	0.03	0.01–0.10	House edge (1%–10%)
bet_limits.min_bet	decimal	Configurable	—	Minimum bet amount
bet_limits.max_bet	decimal	Configurable	—	Maximum bet amount

Platform-Level Settings (Not Operator-Configurable)

Setting	Description
Betting phase duration	How long players have to place bets
Multiplier speed	How fast the multiplier rises
Max bets per round	Maximum bets per player per round (default: 2)

---

Provably Fair

Crash uses a provably fair algorithm to determine the crash point:

1. Before each round, a unique server seed (64 random hex bytes) is generated
2. The SHA-256 hash of the server seed is shared publicly before the round starts
3. Each player provides a client seed when placing a bet
4. The crash point is computed deterministically from the combined seeds

The derivation reads a keyed HMAC-SHA256 byte stream (server seed as the key, the mixed client seeds as the message), takes the first 52 bits as a uniform value u in [0, 1), and maps it to the multiplier:

raw          = max(1.00, floor(1 / (1 − u) × 100) / 100)
crash_point  = min(raw, max_multiplier)

max_multiplier is the per-round cap (platform default 10000x). It is part of the canonical formula, snapshotted onto the round at creation — not applied afterwards — so the ~1-in-10000 round whose uncapped raw exceeds the cap still verifies exactly. After the round ends, the server seed is revealed and the round-detail response exposes raw_crash_point, max_multiplier, and the final crash_point, so anyone can reproduce the draw and confirm crash_point == min(raw_crash_point, max_multiplier).

Note

Each round uses a unique server seed — there is no nonce system. This ensures maximum entropy per round. Client seed order never changes the outcome: the seeds are combined deterministically before hashing.

---

Visual Customization

Operators can customize crash game appearance via the backoffice:

Setting	Description
Game object image	Custom image for the rising element (rocket, plane, etc.)
Multiplier font size	small, medium, or large
Multiplier glow color	Hex color for the multiplier glow effect
Chat panel colors	Background, text, and border colors for the chat panel
Background & colors	Customizable via the visual design editor

---

Rollback Scenarios

Scenario	What Happens
Win wallet call fails	The win is rolled back asynchronously. The bet remains — player effectively loses.
Stale bet recovery	If a bet is stuck for too long (e.g., network issue), Beexar rolls it back asynchronously.
Bet wallet call fails	The bet is voided. No rollback is sent since the operator never confirmed the bet.

---

What the Operator Sees

From the operator’s perspective, crash behaves like any other single-step game — each bet generates independent wallet callbacks:

• Each player bet = its own round_id
• Each bet receives /betwin, and a /finish only when the round was not already closed by finished: true
• Multiple players in the same crash round produce separate round_id values — the operator does not need to know about the shared underlying round
• Reconciliation: net bet minus win for each round_id gives the operator’s revenue per bet