Verify it yourself, with real digests
The method is short enough to run by hand in a terminal. This page uses actual values computed from a real server seed and a real client seed, so you can reproduce every line and see what a successful check looks like before you apply it to a result of your own.
- Before playsha256(server seed)published as the commitment
- You chooseclient seedunder your control, editable
- Per roundhmac_sha256(seed, client + nonce)one digest per bet
- Mappingdigest to a number in rangeimplementation specific
- After rotationserver seed revealedhash must match the commitment
The five steps
- 01
Collect the four pieces
The commitment that was published before play, the revealed server seed, your client seed as it stood at the time, and the nonce or bet identifier for the round you are checking. If the server seed has not been revealed, stop here: nothing can be verified yet.
- 02
Hash the revealed seed and compare
The hash of the revealed server seed must equal the commitment published earlier. A mismatch means the reveal is not the seed that was committed to, and everything downstream is moot.
- 03
Recompute the per-round digest
Apply the published recipe to the server seed, the client seed and the nonce. The common construction is an HMAC-SHA-256 digest keyed by the server seed over the client seed and nonce.
- 04
Map the digest into the game's range
Convert the published portion of the digest into a number in the game's outcome range. This step is implementation specific, so use the provider's recipe rather than this page's example.
- 05
Compare with what you were shown
The mapped value must match the result recorded for that round. If it does, the round was generated from the committed seed as claimed.
A worked example, with values you can reproduce
These are real digests, computed with Node's crypto module from the seeds printed below. Run the command, compare the output line by line, and you will have done the whole procedure once on known-good inputs before doing it on a result you care about.
node -e "
const c = require('node:crypto');
const serverSeed = '2b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7f80912';
const clientSeed = 'player-chosen-seed-01';
const nonce = '1';
console.log('commitment', c.createHash('sha256').update(serverSeed).digest('hex'));
console.log('digest', c.createHmac('sha256', serverSeed).update(clientSeed + ':' + nonce).digest('hex'));
"
Reading the digest into a number
The mapping step takes part of the digest and turns it into a value inside the game's range. In this worked example the first eight hex characters are read as a 32-bit integer and divided by the number of values that 32 bits can hold, which gives a fraction below one. Swap the digests and mapping for the provider's published version when you check a real round.
| Step | Value |
|---|---|
| first eight hex characters of the digest | c5550c8d |
| read as an unsigned 32-bit integer | 3310685325 |
| divided by 2 to the power 32 | 0.7708289951551706 |
| scaled to a range of 0 to 100 | 77.08 |
| scaled to a 1 to 10,000 roll | 7709 |
These are the outputs of the arithmetic. Nothing here is a game, a paytable or a payout, and the values are printed so you can check a mapping implementation against a known input.
A digest that checks out is not a nudge to keep playing
Verification tells you the round was generated as described. It does not improve the expectation of the next round, and it is not a reason to stake more. If checking hashes has become part of how a session is justified, the more useful tools are the operator's deposit, loss and session limits, or a cooling-off period.
Disclosure: this page carries an affiliate link to gamdom.com/r/csgo2026. If you open an account through it we may earn a commission. It costs you nothing extra and it does not change what we write. 18+. Gambling involves risk and can cause serious financial harm. Provably fair is a transparency property, not an advantage: a verifiable result can still lose, and the house margin still applies.