How provably fair works on Rust sites and how to check your rolls

All ten sites in our ranking list their games as provably fair. The phrase has a precise meaning, and the check behind it is something you can run yourself with a free hashing tool or a few lines of code. Very few players ever run it. This guide explains what the system proves, what it leaves out, and how to verify a roll from start to finish.

The short version: before you bet, the site locks in a secret value and shows you a fingerprint of it. You add an input of your own. After the bets, the site reveals the secret, and you can confirm that the fingerprint matches and that every result follows from the inputs. If the numbers line up, the site could not have changed an outcome after seeing your bet.

The problem provably fair solves

On a skin site, the server decides every result. When you open a case, flip a coin or wait for a crash multiplier, you are watching an animation of a number that was produced on a machine you cannot inspect. Without some form of proof, you are trusting that the operator is not quietly nudging rolls against you when your bet is large.

Licensed online casinos usually answer this with regulators and third-party audits of their random number generators. Most skin sites rely on a cryptographic approach instead. It has one big advantage for players: you do not need to trust an auditor, because you can repeat the calculation on your own computer.

The idea is called a commitment scheme. Picture the site writing its secret on a card, sealing the card in an envelope and handing you the envelope before the game starts. It cannot swap the card later without you noticing, and you cannot read the card early.

The three inputs: server seed, client seed and nonce

Almost every provably fair system on Rust sites uses the same ingredients. The labels vary a little between sites, but the roles stay the same.

Server seed

A long random string generated by the site. It stays secret while you play, because anyone who knew it could predict every result. What you see instead is its hash, usually produced with SHA-256. A hash is a one-way fingerprint. The same input always gives the same 64-character output, changing a single character of the input changes the output completely, and there is no practical way to work backwards from the hash to the seed.

Client seed

A string that comes from your side. Sites generate a default one for you, and most let you edit it in the fairness or settings panel. Its job is to stop the site from picking a server seed that is bad for you in particular. The site committed to its seed before it knew what you would type, so it had no way to tune one against the other.

Nonce

A counter that starts at 0 or 1 and goes up by one with every bet you place on the same seed pair. It lets you reuse one server seed and one client seed for hundreds of bets and still get a fresh result each time.

When you want to check your results, you ask the site to rotate the seed. It reveals the old server seed in plain text, shows you the hash of a new one, and resets the nonce. Everything you played on the old seed can now be verified.

How the inputs become a result

The most common recipe is HMAC-SHA256. HMAC is a standard way to combine a secret key with a message to produce a hash. On most Rust sites the server seed is the key, and the message is the client seed and the nonce joined together, often with a colon, like clientseed:nonce. Some sites add a round number or a game ID, so always read the exact formula on the site's own fairness page.

The output is a 64-character hexadecimal string. The site then turns part of that string into a number between 0 and 1. A typical method takes the first eight hex characters (32 bits), converts them to a whole number and divides by 4,294,967,296, which is 2 to the power of 32. That decimal is then mapped onto the game:

• Dice and upgrader: multiply by 100 to get a roll from 0.00 to 99.99, then compare it with the target.
• Roulette: multiply by the number of slots on the wheel and round down to pick a slot.
• Cases: multiply by the total number of tickets in the case, so a skin that owns 1% of the tickets wins on 1% of rolls.
• Crash: feed the number into a formula that turns it into a multiplier, with the house edge built in. Our crash strategy guide walks through that formula and what it means for cash-out targets.

A worked example you can reproduce

The seeds below are made up for this example, so you can check our arithmetic with any HMAC-SHA256 calculator.

1. Server seed: example-server-seed-01. Its SHA-256 hash begins a5275da7ccca3f73. That hash is what the site would show you before you play.
2. Client seed: my-own-client-seed. Nonce: 1. The message is therefore my-own-client-seed:1.
3. HMAC-SHA256 with the server seed as the key and that message as the input gives a result that starts with 4cdcf221.
4. Hex 4cdcf221 is 1,289,548,321 in decimal. Divided by 4,294,967,296, that is about 0.30025.
5. On a 0 to 100 dice scale, that is a roll of 30.02. On a 15-slot roulette wheel, 0.30025 times 15 is about 4.5, which rounds down to slot 4 (counting the first slot as 0).

Run the same seeds with nonce 2 and you get a completely different hash, starting 6486ccbd, which works out to about 0.3927. Nothing about the first roll tells you anything about the second. That independence is the whole point: there is no pattern in a bet history to read, because each result is a fresh hash.

How to verify a roll yourself, step by step

The first full check takes a while. After that it is a few minutes of copying and pasting. Do it on a small balance first, so you know the process before a result actually matters to you.

1. Open the fairness panel before you bet. It is usually linked from the game screen, the footer or your profile settings. Save the hashed server seed somewhere outside the site, such as a note on your phone or a screenshot.
2. Set your own client seed. Replace the default with something you typed yourself. Mash the keyboard. It does not need to be memorable.
3. Play, and note the bets you care about. Write down the nonce shown on each bet, or find it later in your bet history.
4. Rotate the seed. The site reveals the old server seed. Copy it.
5. Check the commitment. Run the revealed server seed through any SHA-256 tool. The output must match the hash you saved in step 1, character for character.
6. Recompute the roll. Use HMAC-SHA256 with the revealed server seed, your client seed and the nonce, then apply the conversion the site publishes. In PHP that is a single call to hash_hmac, and Python's hmac module does the same in a couple of lines.
7. Compare. The number you calculate must produce the outcome recorded in your history.

Most sites also offer a built-in verifier where you paste the seeds. It is handy, but it runs on the operator's own code. For a check that does not depend on the site at all, use an independent tool or your own script at least once.

Shared games work a little differently

Single-player modes such as dice, upgrader and solo case openings can run on your personal seed pair. Games where many players share one result, such as jackpot, coinflip, case battles, roulette rounds and crash, cannot let one player's client seed decide everybody's outcome. Sites handle this in a few common ways.

• A hash chain. Common in crash. The site generates a long chain of hashes in advance, where each round's hash is the SHA-256 of the following round's. It publishes the last hash of the chain before the first round is played, and you can check that each revealed round hashes back into the one before it. Every result in the chain was fixed before anyone placed a bet.
• A public seed from outside the site. The site commits to its server seed, then mixes in a value nobody could know in advance, such as the hash of a future block on a public blockchain. Because that block did not exist when the site committed, the site could not tune its seed to it.
• Per-round commitments. In jackpot and coinflip, the round's hashed seed appears when the round opens, and the plain seed plus the winning ticket are shown when it ends.

The verification idea is the same in each case. Find the commitment that was public before the round, confirm the revealed value matches it, then recompute the result. For how a winning ticket becomes a winner in a shared pot, see our guide to coinflip and jackpot odds. Case battles mix both approaches, which we cover in case battles explained.

What provably fair does not prove

A verified roll proves one narrow thing: the result came from inputs the site committed to before you bet. That is useful, but players often read far more into the badge than it supports.

• It says nothing about the house edge. A crash game with a large edge can be perfectly provably fair. The edge sits inside the published formula that turns the random number into a multiplier or a win chance. Fair means the site followed its own rules, and those rules still favor the site over time.
• It does not check prices. If a case lists a skin at a value well above what it would sell for on the Steam Community Market, the roll can be fair while the case is still poor value. Our upgrader guide shows how item pricing quietly shifts the real odds.
• It does not cover withdrawals. A site can run flawless seeds and still delay payouts, freeze accounts or rewrite its terms. That is why fairness is only one input in how we rate sites, alongside payout speed and trust.
• It only works if someone checks. A commitment nobody compares is just a string of characters on a page.

Red flags on a fairness page

Verifying seeds is a routine step when we test a site. These are the things that make us suspicious, roughly from mild to serious.

If you ever hit the last row, keep your evidence: the saved hash, the revealed seed, the bet IDs and the time of each bet. A single mismatch can be a display bug, but it is exactly the kind of credible player report that makes us re-check a site.

A sensible routine for normal players

You do not need to verify every bet. A light routine catches most problems without turning a session into homework.

• Set a fresh client seed whenever you start playing on a new site.
• Screenshot the hashed server seed before you play.
• Rotate after the session and check the commitment, which is one SHA-256 calculation.
• Recompute the one or two results that mattered most, such as a big upgrader loss or a battle you were sure you should have won.
• Every so often, repeat the full check with an independent tool instead of the site's verifier.

A clean verification means the losses you take are the ones the published maths predicts, and no more. The edge is still there on every roll. The practical next step is to decide in advance how much of those expected losses you are willing to pay for the entertainment; our responsible gambling page covers simple limits and the tools that help you stick to them.