🎰 The Casino (all seven games)

🤓 the nerd stuff

Contract HeadorBlazed at 0x63082d537E4bdf04cD22098fbC6B7f5409a080dA, verified on SonicScan. Flow is approve → flip: the player approves the game contract to spend BLAZE, then calls the flip function with a bet amount.

• Bet range: MIN_BET = 1 BLAZE, MAX_BET = 420 BLAZE.
• Payout: payoutMultiplier = 2 — a win pays 2× the bet.
• Loss: burnPercentage = 5000 basis points (50%) of the lost bet is burned; the remaining 50% stays in the game contract's balance to fund future payouts.
• Cooldown: COOLDOWN = 10 seconds between flips per player.
• Streak bonus: hit streakThreshold = 5 consecutive wins and the next qualifying win pays an extra bonus of bet × streakBonusMultiplier (5×), gated by a streakBonusCooldown = 24 hours per player.

🤓 the nerd stuff

Outcomes are derived from keccak256 over block data (a seed built from block/transaction context, hashed on-chain). This is miner/validator-influenceable — it is not a cryptographically secure source of randomness such as Chainlink VRF.

The contract's own NatSpec states it plainly: "Not secure for high-stakes use cases." That caveat is preserved here on purpose, not softened. Since 2026-08-31 BLAZE does have a market price, so "the stakes are zero" is no longer literally true — but the biggest bet this game takes is 420 BLAZE, which at that price is worth a few thousandths of a cent (📈 The Price). A validator able to influence this seed would be spending real gas to win a rounding error. The weakness is real and the incentive to exploit it is not, and we would rather write both sentences than only the flattering one. It is a limitation baked into the deployed bytecode: there is no upgrade path, so this randomness can never be swapped for a real VRF without deploying an entirely new game contract.

🤓 the nerd stuff

HeadorBlazed is owned by the deployer/treasury wallet (0xd500c0bd9c853d1a234d3c86420edac0331cf7a8) and is Pausable. The owner can call withdraw, emergencyWithdrawNative, and emergencyWithdrawERC20, and can adjust payoutMultiplier, burnPercentage, streakThreshold, streakBonusMultiplier and streakBonusCooldown via owner-only setters.

None of that is a defect — it's a normal, disclosed operator capability on a non-immutable contract. See Trust & Verify for the full picture across all nine BLAZE contracts.

This contract is audited by AI agents, not by a paid security firm. Treat it accordingly: it is a practice-token game, not financial infrastructure.

Check the numbers yourself: 🏛️ The House reads every figure in this paper straight off the chain — each table's free float, what it is holding for bets still in flight, the all-time wagered/paid/burned counters, the live bet limits and cooldowns, and whether the contract is paused right now. It needs no wallet and can send no transaction. Where this paper says "the free float is the ceiling", that page is where you watch the ceiling move.

🤓 the nerd stuff

Contract: 0xd33FF6d627293EC863813ECB5962DEecfb12D1Fc, verified on SonicScan and Sourcify. Commit–reveal: roll() escrows the stake and records the block; after 2 more blocks anyone may call resolve(), which derives the die from blockhash(commitBlock + 2) — a block that did not exist when the bet was placed, keccak-mixed with the roll id and player.

If a roll sits unresolved past 250 blocks the blockhash expires and reclaim() refunds the full stake — a stake can never strand, and pausing only blocks new rolls, never reveals or refunds.

One honest consequence we're not hiding: resolve() is deliberately permissionless, because a player who computes their outcome off-chain could otherwise reveal wins and let losses quietly expire into refunds. Anyone — including us — can settle an abandoned roll inside its ~4-minute window and lock the burn in.

For a token worth a rounding error, that's plenty; if dice volume ever gets serious, a tiny keeper bot closes the loophole entirely. Payouts come from a pre-funded house float, and the contract refuses any bet whose worst-case payout exceeds that float.

Same honesty caveat as the coin flip: blockhash randomness is validator-influenceable in theory — fine for a token worth a rounding error, not for real stakes. The contract also carries a PaintSwap VRF mode the owner can switch on or off live — the game page's Randomness line always shows which one is active right now; every roll records which resolver actually produced its number.

🤓 the nerd stuff

Contract: 0x1081435848d8AC2a404d37497ec3D2053dBd3Bf6, verified on SonicScan. Commit–reveal, same two-phase architecture as BlazeDice: drop() escrows the stake and records the block; after 2 more blocks anyone may call resolve(), which derives the path from blockhash(commitBlock + 2) keccak-mixed with the drop id and player.

The physics are the interesting part. The seed's low 12 bits ARE the ball's path: bit r is row r+1's bounce, 0 left and 1 right, and bucket = popcount(pathBits).

Twelve independent fair bits produce the exact binomial a physical Galton board does — centre 924/4096, each edge exactly 1/4096. The contract stores and emits pathBits, so the animation on the site replays the bounces the chain actually computed rather than inventing a pretty fall and stapling the answer on the end. Anyone can recompute the bucket from the event.

The payout curves are immutable. Three 13-bucket tables declared constant, with no setter of any kind — the owner cannot re-price a bucket, for a live drop or a future one.

Gross expected return is 0.9934× (Low), 0.9979× (Medium), 0.9953× (High): a house edge under 1% on every board, and checkable, because getCurve() is a public pure function and the repo's test suite recomputes the EV from those very constants on every run.

Piggyback settlement is a safety net baked into drop() itself, not the advertised flow: it also tries to settle the caller's previous pending drop in the same transaction — but only if that drop is resolvable right now. Play the site's own ritual straight (Place Bet, then DROP, every ball) and you never trigger it.

But nothing on-chain stops a second drop() from landing while an older one is still open — a different tab, a direct contract call — and if that older drop happens to be resolvable right then, the piggyback catches it in the very same transaction, in one signature.

Not ready, still owned by the VRF oracle, already settled by someone else, or expired past the blockhash window, and the piggyback skips silently. It can never make a new drop revert, and it can never strand a stake either way.

If a drop sits unresolved past 250 blocks the blockhash expires and reclaim() refunds the full stake — a stake can never strand, and pausing only blocks new drops, never reveals or refunds. Payouts come from a pre-funded house float, and the contract refuses any drop whose worst case (the 80× edge on High) exceeds it.

Same honesty caveat as the other two: blockhash randomness is validator-influenceable in theory — fine for a token worth a rounding error, not for real stakes, and we will not call it "provably fair". The contract carries a PaintSwap VRF mode the owner can switch on or off live — the game page's Randomness line always shows which one is active right now; every drop records which resolver actually produced its path.

🤓 the nerd stuff

Contract: 0x3158C29ED5D31767186407853aE3A96bA4233E01, verified on SonicScan. Commit–reveal, same two-phase architecture as BlazeDice and BlazePlinko: spin() escrows the stake and records the block; after 2 more blocks anyone may call resolve(), which derives the seed from blockhash(commitBlock + 2) keccak-mixed with the spin id and player.

The wedge math is the interesting part. The 16 wedge weights sum to exactly 420, so seed % 420 maps every slot onto exactly one wedge — a wedge's probability is precisely its weight over 420. Honestly: 420 is not a power of two, so the modulo carries a residual bias of 420 / 2²⁵⁶ ≈ 2^-247 of the smallest slot's share — cryptographically negligible, and disclosed rather than glossed over.

The contract stores and emits the landed wedgeIndex, so the site's deceleration brakes onto the wedge the chain actually computed rather than a pretty spin with the answer stapled on. Anyone can recompute it from the event.

The wedge table is immutable. All 32 constants (getWheel() returns the lot), no setter of any kind. Gross expected return is 0.995238× — Σ weight×multiplier = 41,800 of a possible 42,000 — a house edge under 1%, checkable on SonicScan and recomputed from the deployed constants by the repo's test suite on every run.

Bust economics: land a 0× wedge and the shortfall (your whole stake) splits 50/50 — half burns forever, half stays in the float so the next winner gets paid. Every spin books the 42× worst case as exposure, and the contract refuses any bet the free float can't cover. If a spin sits unresolved past 250 blocks, reclaim() refunds the full stake — nothing strands, and pausing only blocks new bets.

Same honesty caveat as the other three: blockhash randomness is validator-influenceable in theory — fine for a token worth a rounding error, and we will not call it "provably fair". The PaintSwap VRF mode is switchable on or off live — the game page's Randomness line always shows which one is active right now; every spin records which resolver actually produced its wedge.

🤓 the nerd stuff

Contract: 0xDb4396FF0f52e0b245c41736a12A45A62ba0dfbA, verified on SonicScan. Commit–reveal, same two-phase architecture as BlazeDice, BlazePlinko and BlazeWheel: launch(stake, targetX100) escrows the stake and the target together and records the block; after 2 more blocks anyone may call resolve(), which derives the seed from blockhash(commitBlock + 2) keccak-mixed with the launch id and player.

The formula is the interesting part. The seed's low 52 bits are the draw — a power-of-two draw, so unlike a modulo reduction there is zero draw bias. U = 2⁵² − r is uniform over [1, 2⁵²] and crashX100 = (20900 ≪ 52) / (210 · U) (20900 = 209 · 100).

Win at target T iff crashX100 ≥ T, which happens for exactly ⌊(20900 ≪ 52)/(210·T)⌋ of the 2⁵² draws — so P(win at m) = (209/210)/m to within ~2⁻⁵² (the floor's rounding, disclosed in the NatSpec), and EV = 209/210 = 0.995238 for every target — bustabit's distribution, translated to integer on-chain math.

The minimum crash point is 0.99× (an instant bust below every legal target, ~9.52%); the contract stores and emits crashX100, so the site's rocket replays the flight the chain actually computed. Anyone can recompute it from the event.

The formula is immutable. The EV constants, the 52-bit draw and the target bounds are constant with no setter of any kind — the owner cannot re-price the game, and the bust burn split is hard-capped at 50% by a require in its setter. The repo's test suite re-extracts these constants from the verified source on every run.

Solvency is per-launch: the contract books stake × target / 100 as exposure the moment you commit — your own target is your own worst case (a 420-BLAZE launch at 420× reserves 176,400 BLAZE) — and refuses any launch the free float can't already cover.

If a launch sits unresolved past 250 blocks the blockhash expires and reclaim() refunds the full stake — nothing strands, and pausing only blocks new launches, never reveals or refunds. Piggyback settlement (the same silent safety net as the other games) settles an abandoned launch inside the next bet when it can, and skips harmlessly when it can't.

Same honesty caveat as the other four: blockhash randomness is validator-influenceable in theory — fine for a token worth a rounding error, and we will not call it "provably fair". The PaintSwap VRF mode is switchable on or off live — the game page's Randomness line always shows which one is active right now; every launch records which resolver actually produced its crash point.

🤓 the nerd stuff

Contract: 0x85b264c8FE20C5691280e75A04a06578Bc0cd81C, verified on SonicScan, deployed 2026-08-17 block 77654448. BLAZE's first session game — every other game settles in one bet, this one keeps live state across an unbounded number of rungs until you cash out, bust, or a stale session gets force-settled.

The odds are the fair inverse of themselves, exactly. For the card on the table c, going higher has 14 − c winning ranks and going lower has c − 2, out of 12 non-tie ranks, and the multiplier is 12 / outs — so probability × multiplier = 1 for every card and both directions, before the house edge. c = 8 is a coinflip at 2.00×; c = 3 calling lower has exactly 1 out of 12 and pays the game's steepest single rung, 12.00×. The accumulated multiplier compounds in 1e18 fixed point across every rung won.

The house edge is 209/210 = 0.995238, charged ONCE, on the 0 → 1 transition — not per rung. Charging it every rung would punish long climbs (five rungs would cost 2.4% instead of 0.476%); charging it once means every session that plays at least one rung has the identical EV, however long it runs, and rung 0 (a plain cash-out with no call made) is strictly better — a full, un-edged refund. That is also why the site's FREE-rung detector is the exact general test payoutIfWin < bankedNow(), not "first rung is free": the one un-losable call at rung 0 fails that test and must never be labelled free.

THE DECLINE RULE — why an abandoned rung busts instead of refunding. Every card is drawn from blockhash(commitBlock + 2), a block that becomes public seconds after your call locks. That means a player can compute their own outcome off-chain before ever pressing resolve(). If an abandoned rung refunded, the rational move would be to resolve every win and abandon every loss — a free option, paid for entirely by the house. Settling an abandoned rung as a bust removes that option completely: bust and forfeit are the same outcome for the player, so there is never a reason to walk away instead of pressing the button.

This is a general rule, not a HiLo-specific quirk: a settlement a player can decline must cost them exactly what taking it costs, whenever the outcome is already knowable — and by commitBlock + 2 it is.

An honest player is protected four separate ways: resolve() is permissionless so anyone can settle anyone, the page itself fires it seconds after your call, reopening the page inside the window settles it automatically, and the rescue fee (below) gives a total stranger a reason to press the button for you.

The rescue fee is self-funded and symmetric. deal() escrows a small, owner-set, hard-capped fee on top of your stake. Finish your own session — resolve your own rungs and cash out yourself — and it comes back in full at cash-out, bust or reclaim. Leave a rung stale past its rescue delay, or leave an open session sitting past its idle window, and whoever clears it earns the fee instead of you. It pays the SAME amount whether the rung it settles won or lost, deliberately: a bounty that only paid on a loss would make "hunt losers, ignore winners" the profitable bot strategy, and a symmetric fee leaves nothing to hunt. A rescuer can never touch your money or bend a card — the card is already determined by a blockhash that already exists, and every payout still credits the session's own player, never the rescuer.

The per-session payout cap is a security control, not a house-edge knob. The "float is the ceiling" doctrine the five one-shot games use is unsafe here specifically because this game compounds: a one-shot game's worst case is bounded by its own multiplier (BlazeCrash's ceiling is a constant 176,400 BLAZE), but a validator who can see two blocks ahead can walk a HiLo ladder's exposure upward rung by rung, waiting between guesses until they're due to propose again.

Measured on paper against a 250M float: a 42,000 stake and four produced blocks alone would reach 86% of the treasury with no cap in place. The cap (default 2% of the float, owner-bounded between 0.1% and 20%) stops that same walk-up at rung 1. Honest play barely notices it — a full 553× ladder only brushes the cap on stakes that are already unusually large for this game.

Cash out any time, and the float is still the day-to-day ceiling below the cap. Every open session reserves the worst case it could still cost the house right now; a guess the free float can't cover simply reverts, and the only legal move from there is to cash out. reclaim() exists too, but only for the one moment nothing is at risk: the opening card never arriving at all — every other exit is cash-out or bust, on purpose, per the decline rule above.

Where the money lives. A busted rung burns 50% of the stake forever (hard-capped there, same as every game here) and the rest stays in the house float to fund future payouts. Payouts, refunds and the rescue fee all come out of that same float. withdraw() can never touch an escrowed stake, a booked worst-case payout, or a rescue fee owed back to a player — only the genuinely free remainder.

Pausing this game is narrower than the others, on purpose. Pausing blocks new deal()s only — guess, resolve, cashOut, reclaim and forceSettle all keep working, because a session game must never let a pause trap a player's bank mid-ladder. The rung multipliers and the 209/210 edge are constant, with no setter of any kind — the owner cannot re-price a ladder somebody is already climbing.

Why there is no VRF lane here, unlike the other five. An oracle lane was designed, built, and then removed (owner decision, after three separate attempts each found a different exploit) — because a session game needs an escape hatch for every rung, and an oracle can go silent through no fault of the player. On the blockhash lane, that escape is a bust, which no player ever prefers — so there's nothing to game. An oracle lane's escape has to be a push instead, since a silent oracle isn't the player's fault — and a push is exactly what a losing player wants. Two settlements with different values, one the player gets to pick, is a free option by construction, however it's disguised. So this game draws every card from blockhash(commitBlock + 2) only, and the site says so plainly rather than pretending it's the same caveat as a one-shot game: a one-shot grinder's take is capped by that game's own multiplier, but a ladder compounds, which is exactly what the payout cap above exists to bound.

🤓 the nerd stuff

Contract: 0x9e3c8ddeBE9aCEB4aAabCFEA5b1D8AD130841d61, verified on SonicScan, deployed 2026-08-18 block 77701332. Built as a minimal diff on the BlazeHiLo session engine: same per-rung commit/reveal shape (one pick = one blockhash(commitBlock + 2) draw), same once-only 209/210 edge (applied at settlement; a dig cashed out with zero tiles dug settles un-edged, the full stake back), same self-funded symmetric rescue fee, same per-session payout cap (default 2% of the float, owner-bounded 0.1%–20%), same narrower pause.

The board cannot be pre-drawn, and that is a security property. deal() stores only two numbers — how many tiles are dug and how many are wet. Each pick() draws fresh: the seed's low bits are reduced against t (undug tiles), wet if the draw lands below m. Storing a full layout at deal time would mean one seed decides 25 tiles at once — one blockhash worth 25 answers is a far juicier validator target than one blockhash worth one answer. The per-pick hypergeometric draw is provably equivalent to a hidden fixed board (each sequence of picks has the identical joint distribution) with strictly less state at risk per block.

It also means the tile id you tap never enters the draw — the draw is keyed on tilesDug, the pick index — so the board the page draws at settlement (the Flood Reveal) is cosmetic by construction: your revealed picks are pinned where they really landed and the rest of the water is placed deterministically from the settlement's own entropy, because no honest "here's where the mines were" exists — the game never had a board.

Multiplier arithmetic is physics, not policy. nextAccMul(acc, dug, m) = acc × t / (t − m) with t = 25 − dug, in 1e18 fixed point, TILES = 25 a constant and the wet count locked at deal — there is no setter that can re-price a dig in flight. A full clear at m wet tiles works out to exactly C(25, m): 53,130× at m = 5 (or 20, by symmetry), peaking at 5,200,300× at m = 12/13 — which is why the payout cap, not the multiplier, is the real ceiling on summit boards, and why the page quotes the capped figure up front.

The full odds table, all 24 water counts — this lived on the game page at launch and moved here the same day (owner call: the page keeps the LIVE surfaces — your wet chance and exact payout before every pick — and the wall of numbers lives in the library). Generated from the same math mirror the page and the contract tests share; 🏆 marks the PERFECT DIG band (5–20 wet), where a full clear makes the hall of fame.

The decline rule, second implementation. A pick's outcome is knowable seconds after it locks, so an abandoned pick floods (via forceSettle) — refunding it would hand out the resolve-wins-abandon-losses free option. Unlike HiLo there is no reclaim() at all: HiLo needed one for the moment before its opening card existed, but deal() here opens the field directly — there is never a state where escrow is at risk with nothing decided, so the one honest use for a reclaim never occurs and the function was deleted rather than guarded. Exits are exactly: cash out, flood, or force-settle. FullClear is a dedicated event but pays no bonus — a flat bonus would be farmable at minimum stake on an m = 1 board (~0.12 BLAZE of edge per farmed clear); the reward for clearing the board is the board.

Solvency per pick, not per session. Every locked pick books its worst-case payout into outstandingExposure first; a pick the free float cannot cover reverts (quotePick() exposes the same affordable flag the page reads), and the only legal move from there is cashing out. withdraw() is capped at withdrawableBalance() — it can never touch escrowed stakes, booked exposure, or rescue fees owed back.

Where the money lives. A flood burns 50% of the stake forever (the setter is hard-capped at 50%, same as every other BLAZE game) and the rest stays in the float. Launch float: 20,000,000 BLAZE sent → 19,991,600 arrived (8,400 burned in transit by the token's own 0.042% transfer tax), measured at deploy. The float is a consumable and the page live-reads it — treat any static number here as launch-day history.

🤓 the nerd stuff

Contract: 0xBC113d6a0200f2fF1cea6bAFE128636aaAe2E678, verified on SonicScan, deployed 2026-08-27 block 78251136. Prize collections: Blaze Numbers 0xC77815AB9c5ADbeD9759e211249bB23eB6592F1E (block 78250857 — the tokenId IS an 8-digit number, 00000000–99999999, rendered as an on-chain SVG card) and Sacred Flames 0xaa619b3A4AB9958e4Cc2f74Ed165cf9412815B3E (block 78251014 — a generative, fully on-chain flame). Both are win-only ERC-721s whose only minter is the Altar (write-once, locked 2026-08-27), both carrying a 4.2% EIP-2981 royalty to the treasury — the rate is a constant with no setter; only the receiver address is settable.

The ticket rule. Every 420 BLAZE in a sacrifice is one ticket, and each ticket is an independent 1% win chance — one roll can win MANY prizes. Expected prizes are exactly linear through the exact lane: up to 420 tickets (176,400 BLAZE), every ticket is drawn individually. Above that, a published deterministic normal approximation takes over, with a disclosed deviation of about +0.3% at the 421-ticket boundary that shrinks as rolls grow. Said plainly: splitting a ticket-lane sacrifice is exactly neutral — ten rolls of 420 and one roll of 4,200 buy identical expected prizes — while splitting a sub-420 sacrifice is strictly worse (see the anchors below).

Below 420 BLAZE: ONE long-shot draw. The whole sacrifice becomes a single draw whose win chance runs piecewise linear between these anchors, approaching one full ticket at 420:

What a win IS depends on how big you burned. Each win rolls its prize class from the band your whole sacrifice sits in:

The clamps and the empty-lane rule. The Rat lane opens at 4,200 BLAZE, and a hard clamp allows at most 5 Rats per roll, however many tickets hit. An empty lane cannot hit: when a prize class has nothing left to give (all Numbers won, all Flames won, vault out of Rats), its share becomes Nothing — and the Altar page shows the live effective odds, so you see the real table before you burn, not the launch-day one.

The Sacred Flames are generative, and the fire remembers. Seven palettes: Classic 50%, Crimson 20%, Golden 15%, Emerald 8%, Azure 5%, Void 1.9%, Prismatic 0.1%. The flame's size band comes from the sacrifice, its embers from the epoch's ash, its scars from the losing streak — because every sacrifice feeds an on-chain Ash Chronicle epoch (ash, pilgrims, attempts, nothing-streak), updated at oracle-fulfilment time, and a Flame win fossilizes the whole epoch it captured into its art and resets it for the next era.

Drain economics, documented. At one expected win per 42,000 BLAZE, winning all 17,336 launch prizes (9,999 Numbers + 6,666 Flames + 671 Rats) works out to ≈ 728M BLAZE burned — about 17.3% of the 4.2B supply. The Altar is the biggest burn sink BLAZE has ever shipped, and that is its entire job.

Control & honesty — same rules as every table above. Owner powers, exhaustively: pause NEW sacrifices only (VRF fulfilment and prize claims can never pause), cooldown settable 4–60s, a capped VRF callback gas limit, vault deposit and withdrawal of unreserved tokens (the vault is collection-agnostic — any plain ERC-721; that withdrawal is the generosity lever, and we name it), and rescue of non-vault strays; anyone at all can call burnStrayBlaze(). NO odds setter, NO burn-split setter, NO way to withdraw BLAZE — and a reserved or won prize is provably out of every owner's reach. The honest framing: immutable odds, owner-curated vault, prizes beyond anyone's reach once won. Designed against the same decline rule as the session games and triple-reviewed before deploy — two adversarial audits — never a paid security firm — plus a structured security review, every finding fixed pre-deploy, Foundry EVM tests, and the odds math shipped as a published twin (altar-math.js). Still not professionally audited — it's a meme-priced practice token, same as everything else here. See Trust & Verify for the full contract table.