What Is Provably Fair? How Verification Works on Case Sites

Provably fair is a system where a gambling site commits to the outcome of a round before you play it, using cryptography, and then gives you everything you need to check afterward that it didn't cheat. The site generates a secret, shows you a fingerprint of that secret up front, and reveals the secret later. If the revealed secret matches the fingerprint and produces the rolls you actually got, the site couldn't have changed anything mid-round. That's the whole promise: not that the game is good for you, but that the result was locked in before you clicked the button.

Why it matters on case sites

Case opening, case battle, jackpot, and raffle sites live in a weird regulatory zone. A lot of them hold no gambling license at all, or hold one from a jurisdiction that mostly collects fees. You can't watch a physical wheel spin. You can't count the cards. The entire game happens on a server you'll never see, run by people you'll never meet, often registered in a country you couldn't point to on a map.

In that environment, provably fair is usually the only accountability mechanism you get. There's no gaming commission auditing these sites nightly, so the audit is crowdsourced to you. That's better than nothing, and when it's implemented properly it's genuinely strong. But be clear about its limits before you get too comfortable:

• It proves the outcome generation wasn't manipulated after commitment. Nothing more.
• It does not prove the site will pay you out when you win.
• It does not prove the odds are good, that a case is worth opening, or that the site is solvent.
• It does not prove the site owners aren't the ones winning the big jackpots (a real scandal pattern in this niche).

Think of it as a tamper-evident seal on the randomness, not a clean bill of health for the business.

The classic model, step by step

Nearly every provably fair implementation in this space is some flavor of the same recipe. Once you understand the four ingredients, you can verify rounds on most sites without trusting their interface at all.

1. The server seed (the commitment)

Before any bets happen, the site generates a secret random string called the server seed. It then shows you the SHA-256 hash of that seed. A hash is a one-way fingerprint: you can't recover the seed from the hash, but anyone who later learns the seed can recompute the hash and confirm it's the same string.

Why this exists: because the site publishes the hash before the round, it can't quietly swap in a different seed after seeing your bets. If it did, the reveal later wouldn't match the hash you saved. This is called a commitment, and it's the backbone of the whole system.

Try it yourself. Type anything below and watch its SHA-256 hash. This is exactly what a site shows you before a round starts:

2. The client seed (your input)

The client seed is your part of the equation. Every decent site lets you set it yourself, and you should. If the server seed were the only input, the site would know every outcome in advance and could time things against you. Mixing in a seed the site doesn't control means it can't precompute a sequence of results tuned to make you lose.

One warning: sites always fill in a default client seed for you, and lazy players never touch it. A default that everyone shares isn't automatically rigged (the server seed is still secret), but there's no reason to leave it. Change it before you play. It takes ten seconds.

3. The nonce (one result per bet)

The nonce is just a counter that goes up by one with every bet you place under the same seed pair. Without it, every bet with the same two seeds would produce the exact same result, which would be both useless and exploitable. Bet number 1 uses nonce 0 (or 1, depending on the site), bet number 2 uses the next one, and so on.

4. The outcome calculation

Now the site combines everything into a number. The most common construction is HMAC-SHA256, a keyed hash, computed like this:

HMAC-SHA256(key = server_seed, message = client_seed:nonce)

The result is a 64-character hex string. The site then takes some chunk of it and converts it into a float between 0 and 1 (never quite reaching 1). A widely used formula takes the first 13 hex characters (52 bits) and divides by 2^52:

float = parseInt(hmacHex.slice(0, 13), 16) / 0x10000000000000

That float is then mapped onto the game. For a 0 to 100 roll, a common mapping is roll = Math.floor(float * 10001) / 100, which gives results from 0.00 to 100.00. For a card draw, the float picks a position in a shuffled deck. For a raffle, it picks a winning ticket (more on that below).

The verifier below runs this exact pipeline in your browser. Paste in any seeds, tweak the nonce, and watch the roll change. Nothing leaves your machine:

One honest caveat: every site's exact formula differs slightly. Some use 8 hex characters instead of 13, some hash the message in a different order, some apply extra modulo steps to kill bias. The demo above is a representative version, not a universal one. When you verify a real round, always use the formula documented on that specific site's fairness page, or you'll compute the "wrong" answer and either panic for no reason or miss a real problem.

5. The reveal

Here's the clever part. When you're done playing, you rotate your seeds: you tell the site to generate a new server seed (and usually set a new client seed at the same time). The moment you do, the old server seed is retired and the site reveals it in plain text.

Now you can check two things. First, hash the revealed seed yourself and confirm it matches the hash the site showed you before you started. That proves the seed wasn't swapped. Second, re-run the outcome math for every bet you placed using the revealed seed, your client seed, and each nonce. Every roll should match what the site showed you. If even one doesn't, something is wrong.

Notice why rotation matters: the site only reveals the old seed once it stops being used. While a seed is active, revealing it would let you predict every future roll, so no honest site will do it. If a site makes rotation hard or never reveals old seeds, you have no way to verify anything, which defeats the entire point.

Different methods in the wild

The seed-pair model is the classic, but it's not the only thing you'll see advertised. Here's how the common variants stack up.

Seed-pair HMAC (the standard)

What we just walked through. Server seed, client seed, nonce, HMAC. Used by the majority of case sites and crypto casinos. Strengths: fully verifiable offline, no third parties, instant to check. Weakness: the site still chooses the server seed, so your client seed and the commitment step are doing all the protective work. If you skip those, you're trusting the site.

Blockchain-hash outcomes (EOS and friends)

Some sites derive results from a future block hash on a public chain (EOS was the trendy choice for years, some use Bitcoin or others). The idea: the site commits to using, say, block 350,000,000 before it's mined. Nobody knows that block's hash in advance, not even the site, so nobody can pick a favorable one. Block hashes are public and timestamped, so anyone can look them up on a block explorer.

It's an appealing design, but read the fine print. The block hash is never the whole input. The site almost always mixes it with its own seed through its own formula, and you're trusting both. A block hash alone doesn't pick winners fairly if the site controls how it's combined with other data. So treat "we use EOS blocks" as a strong ingredient, not a complete meal. You still need the full formula and the seed reveal to verify a round.

random.org and third-party randomness

A few sites outsource randomness to random.org's API, which publishes signed responses you can (in theory) check. The catch is structural: this is a trusted third party, not a trustless system. You have to believe random.org itself is honest, and you have to believe the site actually used the response it shows you rather than shopping through a pile of responses for one it liked. Signed responses help with the second problem, but almost nobody verifies the signatures. I'd take a well-documented seed-pair system over this any day.

Red flags

Whatever the flavor, some claims are meaningless on arrival. Be skeptical when a site says "provably fair" but has no public verifier or documented formula, offers no way to change your client seed, never reveals old server seeds, or rotates seeds at odd moments (like right after a big loss). A fairness badge with no math behind it is just a sticker.

How ticket draws work

This one matters most for the games this site covers: raffles, jackpots, and case battles. Almost all of them pick winners with tickets, and the mechanic is simpler than it sounds.

Every player holds tickets in proportion to their stake. Say you deposit skins worth 70 coins into a jackpot, and one other player deposits 30 coins' worth. The pot has 100 tickets total. Tickets are assigned as ranges along a number line: you hold tickets 0 through 69.99..., and they hold 70 through 99.99...

To draw a winner, the site takes its provably fair float (the 0-to-1 number from before), multiplies it by the total ticket count, and floors it:

winning ticket = Math.floor(float * totalTickets)

Whoever's range contains that ticket wins the whole pot. So if the float comes out as 0.7342, the winning ticket is floor(0.7342 * 100) = 73, which lands in the other player's range. If it comes out 0.4108, the winning ticket is 41, and you win.

Why is this fair? Two reasons. First, your win chance is exactly your ticket share: holding 70 of 100 tickets means you win exactly 70% of the time, because 70% of all possible floats land in your range. Second, the float was committed before the draw, so nobody can aim it at a specific ticket after seeing who deposited what. The ranges could be rearranged in any order and the probabilities wouldn't change.

Good sites publish everything you need to recompute a round: the round ID, every participant's ticket range, the total, the float (or the seeds that produce it), and the winning ticket. If a site runs jackpot-style games but doesn't publish round data, you can't verify anything, full stop.

Play with the demo below to get a feel for it. Set the stakes, hit draw, or paste in a float from a real round to see where it lands:

How to verify a real round, step by step

Enough theory. Here's the actual routine, the same one I run on any site before I take it seriously:

1. Set your own client seed before you play anything. Make it random, don't reuse a password, and don't leave the default.
2. Save the hashed server seed the site shows you. Screenshot it or paste it into a notes file. This is the commitment you're going to hold them to.
3. Play. Keep a rough note of your results if you're checking individual rolls. For jackpots and battles, note the round IDs.
4. Rotate seeds when you're done. The site reveals the old server seed in plain text.
5. Hash the revealed seed (the first demo on this page does it) and compare it character by character with the hash you saved in step 2. Mismatch means the seed was swapped. Walk away and tell people.
6. Recompute the outcomes. Feed the revealed server seed, your client seed, and each nonce into the site's documented formula. Every roll, every ticket draw, every battle result should match what you were shown.

Most sites offer a built-in verifier page for step 6, and it's fine as a first pass. But remember that their verifier runs on their turf and could, in principle, lie to you. The stronger move is doing it yourself: the demos on this page, a browser console, or a ten-line script on your own machine. The math is simple enough that you never have to take the site's word for it. That's the whole point of the design.

Limitations and red flags, bluntly

• Solvency isn't covered. A site can run perfectly fair games and still refuse your withdrawal. Check payout reputation separately.
• Case contents aren't covered unless the site also commits to item odds. A fair roll that picks from a rigged prize table is still a rigged game. Look for published, committed odds per case.
• Default client seeds are a soft spot. Change yours. Always.
• Sites that won't reveal old seeds or that rotate them at strange times are telling you something. Listen.
• A verifier that only exists on the site's own domain, with no published formula, is decoration. The formula is the product. No formula, no trust.
• Fair randomness doesn't mean fair value. House edge, withdrawal fees, and lopsided case odds will drain you just as reliably as cheating, only slower and completely legally.

The bottom line

Provably fair is the best accountability tool players in this space have ever had, and when a site implements it properly you can verify every round yourself with nothing more than a browser. But it's a floor, not a ceiling. It answers one question: "was this outcome locked in before I played?" Everything else, whether the site pays, whether the odds are worth taking, whether you should be playing at all, is still on you. Verify the math, then judge the business.

← Back to the blog