How to Verify a Provably Fair Result: A Step-by-Step Walkthrough

To verify a provably fair result: record the hashed server seed and your client seed before you play, note the nonce for each bet, and after the round use the operator’s built-in verifier — or a third-party tool — to confirm the hash of the revealed server seed matches your recorded hash and that rerunning the algorithm with those values produces the same outcome you saw.

That is the whole process. The sections below walk through each step with enough detail to actually do it, not just understand it in principle.

Gambling carries real financial risk. Play only where it is legal for your country of residence, and only with money you can afford to lose. 18+ only.

What You Are Actually Checking

Before getting into the steps, it helps to understand what provably fair accomplishes — and what it does not. For a fuller conceptual overview, see Provably Fair explained.

The short version: the casino commits to a server seed by publishing its SHA-256 hash before any bet is placed. Once a hash is published, the only way to change the seed undetected is to find another string that produces an identical hash — computationally infeasible with SHA-256. Your client seed and a nonce (a counter for each successive bet) are combined with the server seed to derive the game result. When you verify, you are confirming two things:

1. The server seed was not swapped after your bet (hash check).
2. The result recomputes correctly from those three inputs (outcome check).

Provably fair does not remove the house edge, does not guarantee withdrawals, and typically covers in-house “originals” only — not third-party slots. Those limits are real and worth knowing before you treat a green tick as a complete safety signal.

Step 1 — Before You Bet: Record the Hashed Server Seed

When you open a provably fair game, the interface shows a hashed server seed — a long hexadecimal string, usually 64 characters for SHA-256. This is the casino’s commitment.

Copy it somewhere you control: a text file, a note, a screenshot. The key point is that this string must have been recorded before the result was determined, so you have a fixed reference to compare against later.

Most operators also show your client seed on the same screen. You can leave it as the auto-generated value or replace it with any string you choose. Because you contributed to the input, the casino cannot have pre-computed a result that ignores your seed. Note the client seed you used.

Step 2 — During Play: Track the Nonce

Every bet increments the nonce — a simple counter usually visible in the fairness panel, starting at 0 or 1 depending on the operator. If you are verifying a specific bet from your history (say, round 47 of a session), you need the nonce value for that round, not just the latest one.

Most fairness panels display the nonce per bet in the game log. Some operators let you download a full bet history with nonce values. Find it for the round you want to verify.

Step 3 — After Play: Reveal the Server Seed

After you finish playing with a given server seed pair (by rotating seeds, which is the typical trigger), the casino reveals the unhashed server seed. This is the original string whose hash you recorded in Step 1.

Navigate to the fairness or verification panel — usually accessible via a shield icon or a “Fairness” link in the game UI — and click the option to reveal or rotate the server seed. The revealed seed appears there.

Step 4 — Hash Check: Confirm the Commitment

Take the revealed server seed from Step 3 and run it through SHA-256. The output must exactly match the hashed server seed you copied in Step 1.

Using the operator’s built-in verifier: paste the revealed seed into the verifier input field; most casinos do this automatically when you rotate.

Using CyberChef (third-party, runs locally): open CyberChef, drag “SHA2” into the recipe, select 256-bit output, paste the revealed seed, and read the digest. Compare it character-by-character against your Step 1 record.

Using a terminal: echo -n "your_revealed_seed" | shasum -a 256 (macOS/Linux). The -n flag suppresses a trailing newline that would change the hash.

If the hashes match, the server seed was not changed after your bet. If they do not match, see the FAQ at the bottom of this page.

Step 5 — Outcome Check: Recompute the Result

With seed integrity confirmed, the final step is to verify the game result was derived correctly from the three inputs.

Using the built-in verifier: paste or confirm the server seed, client seed, and nonce, then run the verifier. The panel should reproduce the raw random value and the game result (a dice roll number, a crash multiplier, a card draw, etc.).

Using a third-party verifier: operators like Stake and BC.GAME publish the derivation algorithm in their fairness documentation. The typical pattern is HMAC-SHA256 keyed on the server seed with the message clientSeed:nonce, then the first four bytes of the output are converted to an integer, which is reduced modulo the game’s range. The whitepaper or fairness page specifies the exact conversion.

Recomputing manually (Dice as an example):

1. Compute HMAC-SHA256(key=serverSeed, message="clientSeed:nonce").
2. Read the first 8 hex characters of the result as a 32-bit unsigned integer.
3. Divide by 2³² (4,294,967,296) to get a float between 0 and 1.
4. Multiply by the maximum dice value (often 10,000 or 100) and floor to get the result.

Each casino’s derivation may differ slightly in the message format or how many bytes it uses — always follow the operator’s published specification, not a generic formula. Operators like Cloudbet and Bitcasino publish fairness whitepapers linked from the game or help centre.

Reading the Table: Interpreting the Verifier Output

Verifier output	What it means
Hash matched, result recomputed correctly	Round was honest — seed was fixed before your bet and result derived legitimately
Hash matched, result does NOT recompute	Possible bug in the verifier tool, or wrong nonce used — re-check inputs before concluding tampering
Hash does NOT match	Server seed was changed after the fact — potential tampering; document and escalate
Verifier tool unavailable or crashes	Not evidence of fraud on its own; use CyberChef or a script against the published algorithm

A Note on What “Verified” Does and Does Not Mean

A green result from the verifier is meaningful and worth checking. But keep two caveats in mind.

First, a verified result still carries the built-in house edge. Provably fair and RNG both operate under the house’s mathematical advantage — fairness of the draw does not offset that. A crash game verified to be fair still pays less than true odds in expectation.

Second, provably fair applies to the game’s “originals” library. Third-party slots from game studios use external RNG systems and independent audits, not the casino’s seed scheme. If you want to verify a slot result, you need the studio’s audit documentation, not this process.

Bottom Line

Verification takes about 90 seconds once you know what to look for. Copy the hashed server seed before you play, note the nonce and client seed, then after rotating seeds confirm the hash and recompute the outcome. For any result that raises a question, the operator verifier is the first stop — CyberChef or a one-line terminal command is a reliable backstop if the built-in tool is unavailable or you want an independent check.

The process works. The caveat is that you must actually use it, and you must understand that a verified draw still has a house edge and a counterparty risk no algorithm can remove. Pair verification with a well-licensed operator and reasonable session limits, and you have done everything within your control.