Provably fair explained: check a revealed seed's hash

A commitment is a fingerprint of data that is initially hidden. For a SHA-256 server-seed commitment, the operator publishes the hash and later discloses the seed. Your earlier record matters: a newly supplied seed and hash can always agree with each other without showing what was published before the result.

A cryptographic hash is not an encrypted seed that you decrypt. To perform this comparison, you need the actual revealed input. The calculator below does not recover an unrevealed seed or predict a future game.

1. 1

   Record the commitment

   Save the hash and the relevant game or session identifier before the result. Keep the time and provenance of that record separate from the later reveal.

2. 2

   Obtain the disclosed input

   Follow that game's reveal procedure. Use the seed for the same recorded session and check how its documentation encodes it.

3. 3

   Recompute and compare

   Apply the documented hash calculation. A hash match checks the commitment; reproducing the outcome still requires the rest of the game's calculation.

This utility hashes the seed text in the input field as UTF-8 and compares the result with the 64-character hexadecimal commitment you enter. Browser text fields normalize pasted line endings to LF. It supports only schemes in which that text alone is the SHA-256 commitment input. Raw-byte inputs or a scheme that depends on CRLF line endings need their own verifier. It does not implement a casino's complete verifier.

The public test string abc produces the SHA-256 digest displayed in the checker's example above. Load that educational example and compare. Then add a space after abc and compare again: the input bytes changed, so the original commitment no longer matches. The checker preserves spaces rather than silently correcting them.

Now consider provenance. If someone gives you abc and its hash today, the two match. That does not show that this hash existed before yesterday's game. The missing evidence is the earlier commitment record, not another hash calculation.

The three-letter example is intentionally easy to reproduce. It is not a secure random server seed. A real system also needs appropriate seed generation and an implementation whose exact rules you can inspect.

Stake's implementation documents a server seed, client seed, nonce and cursor. Its published HMAC-SHA256 byte generation uses the server seed as the key and a message containing the client seed, nonce and round. The commitment comparison is separate from those generated bytes and their conversion into game events.

BGaming documents a different commitment based on result-and-secret data. Reproducing that scheme requires its specified data structure and game-specific steps. Pasting only a server seed into this guide's checker would test a different input.

Use the exact game's original documentation. Check whether a hex-looking seed is text or decoded bytes, how fields are joined, which hash or HMAC is used, and how random bytes become the displayed result. A nonce or cursor from another round cannot establish your round's result.

Follow the verification process for that particular game. If the documentation or required inputs are missing, leave the outcome unverified. A commitment match cannot fill those gaps. A cryptocurrency payment or blockchain transaction does not by itself establish how a game result was calculated.

• The earlier commitment and a record tying it to the correct game or session.
• The revealed inputs and their exact encoding, including the client seed where used.
• The applicable nonce, round or cursor values and the game's documented algorithm version.
• The result-conversion rules, including ranges, rounding or selection rules.
• The recorded result to compare with your independently reproduced calculation.

Result verification and payout economics answer different questions. A reproducible result can coexist with a house edge, fees or losses. For an illustrative C$100 of total stakes at a stated 97% theoretical return to player, the long-run average loss implied by that assumption is C$3. That is an expectation under the stated model, not a forecast for a C$100 session or proof that a game's advertised percentage is accurate.

This checker does not assess account restrictions, withdrawal handling, operator reliability or whether you should gamble. Those decisions require separate evidence. You can use the explanation and example here without making a commercial choice.

If your next question is which casino makes verification records available, NEXT LEVEL’s separate comparison describes casino verification evidence and its limits. It covers provider choices rather than the calculation taught here. Gambling can cause financial loss; a verifiable result does not remove that risk.