How Provably Fair CS2 Sites Work, With a Real Example

Why this matters

Every CS2 gambling site you'll find on a top-10 list claims to be "provably fair." Most users see the badge, click "I trust this," and move on. The point of this post is to show you what's actually happening underneath that badge, and how to verify a roll yourself when you suspect a site cheated. It's not as hard as it sounds. The math is one HMAC call. Anyone can run it.

The reason provably fair exists is that the alternative, trusting the site, has a long, ugly history. Before the protocol was widely adopted around 2016, several CSGO sites were caught manipulating outcomes for streamers (the Tmartn / ProSyndicate "CSGO Lotto" scandal is the famous one). Provably fair was the industry's response: build the math into the system so that even a hostile operator can't change the result of a bet after seeing it.

What "provably fair" actually means

The term is shorthand for a specific cryptographic protocol with three properties:

1. Pre-commitment. The site commits to a secret value (the "server seed") before any betting happens, by publishing a hash of it. Once published, that hash can't be changed without producing a different hash, so the site is locked in.
2. User contribution. You contribute a value (the "client seed") that mixes into every roll. Because the site has already committed to its server seed, it can't choose a server seed that produces a bad result for your specific client seed, your seed wasn't known when the site committed.
3. Reveal. When the seed pair is "rotated" (you change client seed, or the site changes server seed), the site reveals the original raw server seed. You hash it yourself, compare against the previously-published hash, and re-compute every roll you made under that seed pair. The numbers either match or they don't.

If those three steps are honoured, the site cannot have manipulated any roll without you being able to detect it after the fact. That is the "proof" in provably fair.

The three values you need

Every provably-fair roll is determined by a deterministic function of three inputs. Different sites combine them slightly differently, but the values are always the same three:

Server seed

A long random string the site generates and keeps secret. Before you make your first bet under a new server seed, the site publishes its hash (typically SHA-256). The raw seed stays secret until the seed pair is rotated. This is the "commit" half of commit-reveal.

Client seed

A string under your control. Most sites auto-generate one for you, but you can edit it any time. When you change it, the site rolls over to a new server seed (and reveals the old one). Your influence here is what stops the site from picking a bad server seed for you specifically, your seed wasn't predictable at commit time.

Nonce

An incrementing counter, 1 for your first roll under this seed pair, 2 for the second, 3 for the third, and so on. Without the nonce, every roll under the same (server seed + client seed) pair would produce the same result. The nonce is what makes each roll different.

The math: HMAC-SHA256

The combination is hashed with HMAC-SHA256, a keyed cryptographic hash. The site uses the server seed as the HMAC key and a string of the form clientSeed:nonce as the message:

result_hex = HMAC_SHA256(key = serverSeed, message = clientSeed + ":" + nonce)

The output is a 64-character hexadecimal string. The site then takes the first few hex characters, converts them to an integer, and uses modular arithmetic to map them onto the game's outcome space, for example, "first 8 hex chars mod 10000" gives a number from 0 to 9999, which the site might then map to "roll percentage" (5417 → 54.17). For a case opening, the same integer maps onto a weighted table where rare skins occupy a thinner slice of the number line.

The exact mapping varies by site (CSGOEmpire uses a different scheme than CSGOroll), but the underlying HMAC is universal. As long as the site publishes its mapping function, you can re-derive any historical roll yourself.

A worked example you can verify

Here are real values. You can paste them into any HMAC-SHA256 calculator (or run them in Python, JavaScript, or any language with a crypto library) and confirm the result.

Inputs

• Server seed: skinsvault-demo-server-seed-2026-april-22
• Client seed: user-readme-client-seed-9f4e2a
• Nonce: 7

Step 1, server seed hash (the pre-commit)

Before play started, the site would have published only this hash:

SHA256("skinsvault-demo-server-seed-2026-april-22")
  = 5283b889a1d3e74dcd477a302c23aae601e8d964c4c9a5b657b1b7e53a70d3b1

You can verify this in any SHA-256 hash tool. The 64-char output is the commitment. If the site later reveals a different server seed than the one that produces this exact hash, you've caught them red-handed.

Step 2, HMAC the seed combination

Now compute the HMAC for nonce = 7:

HMAC_SHA256(
  key:     "skinsvault-demo-server-seed-2026-april-22",
  message: "user-readme-client-seed-9f4e2a:7"
)
  = 46a3e24951b677caa33ea2838c3ad82b95039da0d78b07d6b68e9a267ef0a45d

Same input, same output, every time. If you ran this in your terminal right now, you'd get the exact same 64 hex characters.

Step 3, derive the roll

Take the first 8 hex characters of the HMAC: 46a3e249. Convert to a decimal integer: 1,185,145,417. Modulo 10,000 (the most common range for "percentage rolls"): 5417.

That maps to a roll of 54.17%. On a coinflip site where "above 50.00 wins", you'd win this round. On a roulette where 0–9999 maps to a weighted skin table, the site looks up which skin occupies the slot at index 5417 and that's your drop.

What this proves

If the site published the hash 5283b88… before you played, and you played seven rolls, and the seventh one came up at 54.17%, the site cannot retroactively claim it was anything else. Anyone with a calculator can reproduce that 54.17%. The result is locked the moment the site committed to the server seed hash, and no operator-side intervention can change it without breaking the hash chain.

How to actually verify a real roll

When you suspect a site cheated you, here's the routine:

1. Find the roll's seed pair. Every provably-fair site has a "verify" or "fairness" page in your account settings. Open it. Find the roll you want to check, note its server seed, client seed, and nonce.
2. Confirm the server seed hashes correctly. The site will show both the raw server seed AND the hash it pre-committed. SHA-256 the raw seed yourself, compare to the published hash. If they don't match, you have proof of tampering, screenshot everything.
3. Re-compute the HMAC. Use the formula above. Most sites publish the exact mapping function on their fairness page so you can derive the outcome without guessing.
4. Compare to the actual outcome you saw. If they match, the roll was fair (you just lost). If they don't match, you have evidence of fraud, the kind of evidence that gets sites delisted from review platforms like ours and exposed on r/csgobetting.

This sounds like a lot of steps. In practice it's about 30 seconds of work in a Python REPL or any online HMAC calculator. The reason it matters isn't that you'll do it on every roll, it's that you could, and the site knows you could.

Site-by-site: who supports provably fair well

From our testing for the 2026 ranking, these are the sites with the cleanest provably-fair implementations, meaning they expose all three values, publish their mapping function, and let you change client seed and force a server-seed rotation at will:

• Clash.gg, full implementation. Server seed hash visible at all times, raw seed revealed on rotation, mapping function documented. Read the full review.
• CSGOEmpire, provably fair across roulette, coinflip, and case opening. Help center includes a step-by-step verifier. Read the review.
• 500.Casino, provably fair on the original house games. Some third-party slots are not (they're licensed casino games using a different RNG). Read the review.
• CSGORoll, clean implementation, good docs.
• Howl.gg, supported on the in-house games.

Sites that claim provably fair but hide the mapping function or don't let you rotate seeds on demand are a red flag. We flag them in the individual reviews.

What provably fair does NOT protect against

Important distinction. Provably fair guarantees the integrity of each individual roll, but it does not guarantee:

• That the published odds match the real odds. If a site says "1 in 10,000 for the AWP Dragon Lore" but the actual weighted table has 0 slots assigned to that skin, no amount of HMAC verification catches that. Some sites publish the full odds; others publish only the mapping function. Read what's actually in the table.
• The site's solvency. Provably fair doesn't mean you'll get paid. The protocol verifies the bet outcome, not the withdrawal. We separately track payout speed in every review.
• That the site won't disable your account before you withdraw. If a site decides you've won "too much" and freezes your account, the math behind your last roll being legitimate doesn't help.
• Bot manipulation in PvP modes. In case battles or jackpot games against other "players," the other players might be the site's bots. Provably fair on the case opening doesn't prove the opponent is human.
• Manipulated client-side displays. The math is honest, but the spinning animation showing your "near miss" is theatre. The result was determined the instant the bet was placed; the animation is just dramatising it.

Provably fair is necessary but not sufficient. A reputable site has provably fair AND a real licence AND a clean withdrawal track record AND honest published odds. Missing any of those is a problem.

Frequently asked

Why HMAC-SHA256 specifically?

HMAC is a "keyed" hash, it requires both a secret key and a message. SHA-256 is the underlying hash function. Together, HMAC-SHA256 has the property that the output is unpredictable without knowing the key, but trivially verifiable once the key is revealed. That commit-now-reveal-later property is exactly what provably fair needs. Some sites use HMAC-SHA512 or other variants; the principle is identical.

Can the site be running TWO server seeds and choosing which one to reveal?

Theoretically possible if they pre-published two hashes and only revealed one. In practice, every reputable site publishes only the active hash, and it's visible to you for the entire duration you're playing under that seed. If they tried to swap mid-stream, you'd see the hash change and have a record. This is one of the things the user-side fairness page on a good site lets you screenshot.

What if I never look at the math?

Most users don't. The protection still works because the site has to assume someone will check. Streamers, journalists, Reddit cryptography hobbyists, there's always someone running the calculation on a suspicious-looking jackpot. The math being checkable is what makes the math get checked.

What about Stake-original or non-CS2 casinos?

The protocol is the same. Every "provably fair" crypto casino, Stake, Roobet, BC.Game, uses HMAC-SHA256 (or a close variant) with server seed, client seed, and nonce. The CS2 sites borrowed the pattern from the broader online crypto casino ecosystem.

What if I edit my client seed mid-roll?

You can't, in practice. Most sites lock the client seed for the duration of an active bet. To change your seed you have to wait until the previous roll resolves. When you do change it, the site rotates the server seed too, publishes a new hash and reveals the old one. This is the natural verification checkpoint for everything you played under the old seed.

Does provably fair mean the site can't go bankrupt and steal my balance?

No. Provably fair is about bet outcomes, not the operator's solvency or honesty in withdrawals. It's a check on cheating in the bet, not a check on the company being trustworthy overall. A site can be 100% provably fair and still collapse with your funds.

Is Steam's official case opening provably fair?

No, not in the cryptographic sense. Steam case opening uses Valve's server-side RNG without exposing seed-and-nonce verification to users. Steam isn't trying to pretend otherwise, they call it "random," not "provably fair." Whether you trust Valve's RNG is a separate trust question from whether you trust a third-party site's RNG; provably fair just means the third-party gives you the math to check.

What's the difference between provably fair and audited RNG?

Audited RNG is when an external firm (like iTech Labs or eCOGRA) tests a site's random number generator and certifies it as statistically uniform. It's a trust-the-auditor model. Provably fair is a trust-the-math model, you don't need an auditor because you can verify each roll yourself. Both can coexist; the best sites have both.

The bottom line

Provably fair is a real, working cryptographic protection, but only against the specific class of cheating where the site changes a roll's outcome after seeing your bet. It doesn't fix everything. The list of things it doesn't protect against (above) is longer than the list of things it does.

That said: any site that claims to be a CS2 gambling destination in 2026 and doesn't expose provably-fair verification is operating on borrowed time. Every reputable operator on our ranked list supports it, and most of them put the verifier directly in your account dashboard. If you've never checked a roll, do it once on a small bet, see the math work, then make a real decision about whether you trust the rest of the operation.

Sources

• HMAC-SHA256 specification (RFC 2104, RFC 6234)
• CSGOEmpire fairness documentation (help.csgoempire.com)
• CSGORoll provably fair page
• Skin.Club provably fair documentation
• ProvablySmart explainer on server/client seed/nonce

Last updated May 26, 2026 by the SkinsVault Editorial Team. The worked example values above are real and verifiable; run the SHA-256 and HMAC-SHA256 yourself to confirm.