Provably fair

Every result is decided by a number the casino commits to before you bet, mixed with a number you control. After the fact you can recompute every roll yourself and check it against what we paid you. If we ever changed an outcome, the arithmetic would not match.

The problem this solves

An online casino generates the numbers and also holds the money. Nothing in a normal setup stops it from looking at your 100 USDT bet and picking a losing roll. You cannot audit a server you do not control, and "trust us" is not an answer.

The fix is to force the house to lock in its randomness in advance, in public, in a form that reveals nothing until later. That is a commitment.

Three inputs

Server seed

32 random bytes we generate and keep secret. We publish only its SHA-256 hash up front. A hash is one-way: it proves the seed existed and cannot change, while telling you nothing about it.

Client seed

Yours — by default a fresh random one for every bet, picked by your browser after it has seen our commitment. Because it feeds the result and we cannot know it in advance, we cannot pick a server seed that is good for us and bad for you.

Nonce

Always 0 now: every server seed decides exactly one bet. It stays in the formula because bets from when one seed decided many — each with its own nonce — still verify the same way.

The sequence

1. We commit. Before every bet we show you sha256(server seed) for the seed that will decide it. The seed itself stays sealed.
2. You pick. Your browser generates a fresh client seed for that bet — after it has seen the commitment — and sends it with the commitment it saw. If that is no longer our committed seed, the bet is refused.
3. We reveal. The moment the bet settles, its server seed is revealed in the result and in your history, and the next bet's commitment is published.
4. You verify. Hash the revealed seed and compare it to the commitment from step 1. Then recompute the roll. Both must match.

A seed is revealed only once it has decided its one bet. A seed that still had bets to decide could not be shown — you could compute them in advance and bet only on winners — so every seed decides exactly one, and is revealed the moment that is done.

Crash is committed differently

Dice gives you a private seed, because your roll is yours alone. Crash cannot work that way: every player in a round watches the same curve, so the outcome has to be one public number, and a seed only you control could not produce it.

So crash rounds run off a hash chain. We generate a secret seed and hash it repeatedly to build a chain of 100,000 links, then publish the last one — the head — before the first round. Rounds consume the chain backwards:

round 1 seed → sha256 → head                    (published before round 1)
round 2 seed → sha256 → round 1 seed
round 3 seed → sha256 → round 2 seed
   ⋮

Each round reveals its seed when it ends, and that seed must hash to the one revealed before it. Because hashing only runs one way, we could not have produced this chain without fixing every round in it first. We cannot re-roll a round, reorder rounds, or quietly skip one we do not like — any of those breaks a link you can check yourself, against a head published before the game started.

What it does not hide: we know the whole sequence from the moment we generate it, because we hold the seed it was built from. The commitment proves we cannot change the future, not that we cannot see it. Salting the chain with a public value nobody controls — a future block hash — is the standard way to close that gap, and it is not built here yet.

Mines is one bet, played slowly

A Mines game uses your own seed, exactly like a dice bet: the commitment is shown before you start, your browser picks the client seed after seeing it, and the mines are placed the moment the game starts. Turning tiles cannot move them. What differs is when the seed is revealed — at the end of the game, not the start, because until then it would show you where every mine is.

Having turned k safe tiles, the chance you survived that far is C(25 − mines, k) / C(25, k), and the multiplier is 0.99 divided by it. So cashing out after any number of tiles carries the same 1% edge. A game left untouched for an hour is cashed out for you at what it is worth.

The formula

bytes = HMAC_SHA256(key = serverSeed, message = "clientSeed:nonce:cursor")

float = bytes[0]/256 + bytes[1]/256² + bytes[2]/256³ + bytes[3]/256⁴   → 0 ≤ float < 1

That float becomes the result:

Dice    roll = floor(float × 10000) / 100          → 0.00 .. 99.99
        win if roll is under (or over) your target
        multiplier = 0.99 / (winning outcomes / 10000)

Crash   crashPoint = floor(99 / (1 - float)) / 100
        win if you cash out at or below the crash point
        multiplier = 100 × 2 ^ (seconds / 5)           ← the curve, doubling every 5s

Mines   one float per mine: mine i = floor(float × (25 − i))-th of the tiles still empty
        multiplier after k safe tiles = 0.99 × C(25, k) / C(25 − mines, k)

Cashing out at any multiplier m wins exactly when the crash point reaches m, which happens 0.99 / m of the time. So a cash out at 2× and one at 10× carry the same edge — it is a property of the draw, not of when you choose to stop.

The 0.99 is the house edge, stated plainly: a 1% edge, so a fair bet returns 99% of stake on average. It is the only thing tilted in our favour, and it is the same for every player and every bet size.

The edge is a published setting per game, and it can change. When it does, it applies to bets placed afterwards and to nothing else: every bet records the edge it was settled at, your bet history shows it, and the verifier takes it as an input. So a bet you placed last week still checks out against last week's number — changing the dial cannot retroactively make an old result "correct".

Verify a bet

Paste a revealed seed triple below. The recomputation runs entirely in your browser, from maths reimplemented independently in fair-verify.js. Save that file and it still works with this site offline.

One exception, and it changes nothing: Load a past round asks the server for a crash round's revealed seed, because you would otherwise have to copy it by hand. Everything it hands back is then checked here, against a commitment that was public before that round ran — so a doctored answer fails the check on your machine, not ours.

What this does and does not prove