> ## Documentation Index > Fetch the complete documentation index at: https://docs.darkmatter.rdytobash.tech/llms.txt > Use this file to discover all available pages before exploring further. # Dark Matter Entropy provably fair Housecasino - Own a Share of the House > Crash and the four Entropy dice games (Mines, Limbo, Plinko, Keno): one money model, 99% RTP, provably fair verification, and house edge routed to the community. The Dark Matter Entropy house casino runs Crash ("Dust Runner") and four dice originals (Mines, Limbo, Plinko, Keno) on one shared chip ledger and one money model. Every game has a **99% RTP** and is provably fair, and the realized house edge does not stay with an operator: `routeEdge()` splits it 50/50 between the [Event Horizon](/pools/event-horizon) VIP pots and the LP treasury. Formula, round clock, bet bounds and money flow. Commit, play, reveal, and how to verify a round. Mines, Limbo, Plinko and Keno. ## Own a share of the house Every bet across Crash and the dice games feeds one bank. When rounds settle, the realized edge (stakes minus payouts) is booked per token and forwarded on-chain: ```solidity theme={null} CrashVault.routeEdge() // splits 50/50: // → rewardsPool (EventHorizonPool weekly pots) // → lpTreasury (token LP bootstrap) ``` The 50/50 split is fixed in the contract; a zero sink keeps its share as protocol revenue. This is the casino's engine feeding the VIP pots and LP treasury directly. ## Crash money model "Dust Runner" is the flagship Entropy game. Its economy is simple to state and exact: **RTP is exactly 99% for every cash-out target.** ### The crash formula ```js theme={null} // server/crash-engine.js + serverless/crash.js — verbatim model crash = round2( clamp( (1 − edge) / (1 − u), 1, 100 ) ) // edge = 0.01 (1% house edge), u = uniform(0,1) from the committed seed ``` Deriving the RTP for an arbitrary cash-out at multiplier `m`: ```text theme={null} P(crash ≥ m) = (1 − edge) / m = 0.99 / m EV(cash out at m) = m × P(crash ≥ m) = m × 0.99/m = 0.99 □ ``` The `(1 − edge)` numerator is what makes every target identical in expectation — there is no "good" or "bad" cash-out point, only variance. ### Round clock ```text theme={null} roundId = floor(t / 45s) [0s, 20s) betting window (fixed 20s) [20s, 42s) flight — ends at the round's crash point (variable length) [42s, 45s) results ``` Every server instance derives identical state from wall-clock time — no websockets, no round coordination. The next round rolls over automatically; a crashed round settles and moves on without rendering stale curves. ### Bet bounds | Token | Min | Max | Decimals | | - | - | - | - | | ETH | 0.0001 | 0.02 | 18 | | USDG | 0.5 | 100 | 6 | ```text theme={null} CRASH_MIN_BET_ETH / CRASH_MAX_BET_ETH / CRASH_MIN_BET_USDG / CRASH_MAX_BET_USDG ``` Both currencies move real `CrashVault` custody, so bounds stay conservative out of the box. DUST is deliberately **not** a bet currency — it is the non-transferable activity score (see [Stardust](/casino/stardust)). ### The money flow, end to end **1. Deposit (custody).** Player deposits into `CrashVault` themselves (ETH via `depositEth()`, USDG via `depositToken()`). The server sweeps `Deposited` events and credits the chip ledger **minus the 1% deposit fee**: ```text theme={null} player chips = custody − 1% fee dev chips = fee/2 (ceil) VIP chips = fee − dev (EventHorizonPool address) ``` The vault always custodies 100% of assets; fee rows are ledger claims settled through the same signature-gated withdrawal flow. See [The casino's own 1%](/reactor/waterfall#casino-fee). **2. Betting (ledger).** Bets debit chips at bet time; the round's stakes and payouts accrue per round row. A bet cashes out at `m` → payout = `amount × m` credited instantly in-ledger. **3. Settlement (the bank).** When a round settles, realized edge is booked per token: ```sql theme={null} crash_bank(token, stakes, payouts) -- stakes − payouts = realized edge ``` Realized edge **can be negative** — when players outperform, the bank absorbs the variance honestly. Long-run, the law of large numbers drives realized edge toward the 1% house edge. **4. Edge routing (on-chain).** Accumulated realized edge is forwarded by the relayer through `CrashVault.routeEdge()`, split 50/50 as described in [Own a share of the house](#own-a-share-of-the-house). ### Worked examples **Example A — 0.01 ETH bet, cash out at 2.00×:** * P(crash ≥ 2.00) = 0.99 / 2 = **49.5%** * Win: 0.02 ETH back (+0.01 profit). Lose: bet. * EV = 2 × 0.495 × 0.01 = **0.0099 ETH** → exactly 99% RTP. **Example B — 0.01 ETH bet, cash out at 10.00×:** * P(crash ≥ 10) = 0.099 → **9.9%** * EV = 10 × 0.099 × 0.01 = **0.0099 ETH** — identical. **Example C — a round's edge accounting:** 5 players stake 0.01 ETH each; three cash out at 1.5× (0.015 back), two bust. ```text theme={null} stakes = 0.05 ETH payouts = 0.045 ETH realized edge = 0.005 ETH → 50% (0.0025) to VIP pots, 50% to LP treasury on routeEdge() ``` ### Auth & session model Stateless wallet signature — the client signs once per day: ```text theme={null} DARK MATTER CRASH auth vault:0x… chain:46630 wallet:0x… window:12345 ``` The server recovers the signer and compares against the **current and previous 24h window**, so one signature a day suffices with no mid-game re-sign nag at boundaries. No sessions exist; every money-touching action carries the signature. ### Withdrawal Player signs `(player, token, amount, nonce)`; relayer submits `CrashVault.withdraw`. Gasless for the player, signature-enforced on-chain — the server cannot move player funds. See [Two Vaults & Custody](/architecture/vaults-custody). ## Crash provably fair Crash uses a **commit→reveal** model (the same shape the vfair-games engine uses): the outcome of every round is fixed and committed **before betting opens**, and the key needed to verify is published **at settlement**. ### 1. COMMIT — before betting opens ```js theme={null} seed = keccak(masterPepper : roundId) // pepper = server-only secret hash = sha256(seed) // stored in crash_rounds.seed_hash ``` The seed hash is committed to the database the moment the round's betting window opens. The seed itself stays secret until settlement. Because the seed derives from `roundId` and a stable pepper, every server instance derives the **same** seed — there is no room for per-instance discretion. ### 2. PLAY — the outcome is derived from the committed seed ```js theme={null} u = uniform(0,1) from keccak(seed : roundId) crash = round2(clamp(0.99 / (1 − u), 1, 100)) ``` The crash point is a pure function of committed data. Nothing about gameplay (bet volume, timing, winner count) can influence it. ### 3. REVEAL — at settlement The raw `seed` and `pepper` are published next to their hash. Anyone can verify: ```text theme={null} 1. sha256(seed) === seed_hash // the seed wasn't swapped 2. u = uniform(keccak(seed : roundId)) // re-derive 3. crash = round2(clamp(0.99 / (1 − u), 1, 100)) // matches the settled round ``` ### Where to verify * **In-app:** the Provably Fair popup on every game exposes the verification for the round/bet you're looking at — same optics as the vfair games' built-in verify. * **API:** `GET /api/crash?action=verify-seeds` publishes `(seed_hash, seed, pepper)` for the 12 most recently settled bet-bearing rounds. ```json theme={null} { "ok": true, "rounds": [ { "roundId": 481902, "seedHash": "9f2b…", "seed": "0x81aa…", "pepper": "0x5c1e…", "crash": 1.87 } ] } ``` ### Why the pepper can't cheat you The classic fear: "the operator sees my bet and picks a bad seed." Here that's impossible **by construction**: 1. The seed hash is committed **before betting opens** — before the operator knows who bets or how much. 2. The seed is a deterministic function of `(pepper, roundId)` — the operator cannot "reroll" a round without changing the pepper, which would break every future verification (and any hash comparison against previously published rounds). 3. After reveal, `sha256(seed) === seed_hash` is publicly checkable — swapping the seed post-hoc is detectable by anyone. ### Odds table (what the formula implies) | Cash-out target | Win probability | RTP | | - | - | - | | 1.50× | 66.0% | 99% | | 2.00× | 49.5% | 99% | | 5.00× | 19.8% | 99% | | 10.00× | 9.9% | 99% | | 50.00× | 1.98% | 99% | | 100.00× | 0.99% | 99% | Win probability for any target `x` is `0.99 / x`, so RTP is 99% at every cash-out target. The clamp at 100× caps the maximum multiplier; the clamp at 1.00× means \~1% of rounds crash instantly at 1.00 (the house edge rounds themselves). ## Dice originals The four Entropy dice games (Mines · Limbo · Plinko · Keno) share one money model with Crash: bets are crash chips (shared `crash_chips` ledger, ETH / USDG), debited at bet, credited at settle. Every bet draws a **fresh server seed**; `keccak(seed)` is stored alongside the result so any settled row can be audited — recompute the outcome from the stored seed, and the hash proves the row wasn't rewritten. ### Shared economics | Property | Value | | - | - | | Currencies | ETH (18dp) + USDG (6dp) | | ETH bet bounds | 0.00005 – 0.05 ETH | | USDG bet bounds | 0.01 – 500 USDG | | RTP | **≈ 99%** by construction for all four games | | House edge | 1% | | Fairness | per-bet server seed; `keccak(seed)` persisted with the result | Fee routing mirrors the crash side: realized edge accrues in the bank and flows to the same sinks (VIP pots + LP treasury) through `routeEdge()`. ### Mines — single pick, M mines on a 5×5 grid 25 tiles, M mines (1–24). One pick. The more mines on the board, the higher the payout multiplier — but the lower the win chance. All outcomes are verifiable from the stored seed. ### Limbo — target the multiplier Pick a target multiplier. If the result meets or exceeds it, you win. The result is capped at 1,000,000×. Higher targets pay more but win less often. ### Plinko — 16-row binomial drop 16 rows of pegs; the ball drops through and lands in one of 17 buckets. Edge buckets carry the highest multipliers (up to 170×/1000× on high risk); center buckets pay fractions of a stake. Three risk tables (low / medium / high) are available. ### Keno — pick up to 10 of 40 40 numbers, 10 drawn. Player picks k numbers (1–10). More picks = more chances to hit, but the paytable adjusts accordingly. Top multipliers are hit at extreme tails. ### Verification walkthrough For any settled bet: 1. Fetch the row (API exposes `seedHash`, `seed` after settle, plus full result meta). 2. Check `keccak(seed) === seedHash`. 3. Re-run the engine function on `(seed, bet params)` — pure, deterministic, and the same code path the settle used. 4. Confirm the payout matches the derived outcome × the paytable. The same popup used for Crash (shared vfair-verify component) runs this flow for all four games — one aligned theme, no white-page verification. Next: [Lootboxes](/casino/lootbox). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.