Keno Draws and Hash Chains: A Step-by-Step Verification Walkthrough

profile avatar

the author

ProvablySmart Research Desk

date post

Aug 28, 2026

Share

facebook twitter

This walkthrough explains how to verify a keno draw when the casino uses a hash chain commitment scheme. It assumes you have basic familiarity with provably fair guides. The steps are technical but repeatable; you should be able to audit any listed draw with a local script or a web tool that the operator provides. As of 2026, most verified crypto casinos use this method for keno.

How the Hash Chain Is Structured

A hash chain commitment protects the server seed before a round. The casino generates a list of server seeds. For each round, it publishes the hash of the server seed that will be used in that round. After the round, the actual server seed is revealed, and you can check that its hash equals the previously published value. The next round then uses the next revealed hash from the same chain.

What to Collect

To verify a keno draw you need the following data. Most casinos expose all of these on the same round detail page.

  • The server seed (revealed after the draw).
  • The pre-round commitment hash (visible before the draw).
  • The client seed.
  • The round nonce (often called draw number).
  • The number of keno picks.
  • The official keno outcome.

Step-by-Step Verification

Step 1 – Record the Commitment

Before the round is executed, the casino displays a string such as sha256 = a94a8fe5ccb19ba61c4c0873d391e987982fbbd3.... Save that exact value along with the round ID. If the page reloads or changes before the draw, do not trust that round.

Step 2 – Reveal the Server Seed

After the round, the server seed is shown. Use any SHA-256 tool to hash it. If the result matches the pre-round commitment, the seed was fixed before the round. If it does not match, the casino has either revealed the wrong seed or is not following the documented chain.

Step 3 – Compute the Keno Numbers

Most operators use HMAC-SHA256 with the server seed as the key and a message containing the client seed, nonce, and pick count. The exact format varies, so check the operator’s documentation. A common format is clientSeed:nounce:pickCount.

Then derive the keno numbers from the 1–80 range. The standard method is rejection sampling: take the bytes of the HMAC output, divide by 80, reject values above 80, and skip duplicates until you have the required number of distinct picks.

Step 4 – Compare the Outcome

Compare the derived numbers against the official draw. Also check that the official draw matches the number of picks and the keno board range. A single-number mismatch means the hash function, the message order, or the sampling method is different from your assumption.

Step 5 – Verify Chain Continuity

After the round, the casino discloses the next pre-round commitment. A consistent chain will show that the new commitment hashes to the server seed revealed in the next round. This ensures the chain was not reseeded without disclosure.

Verification StepInputExpected Result
Hash server seedServer seedMatches pre-round commitment
HMAC-SHA256Server seed, client seed, nonce, pick count64-byte output
Rejection sampleHMAC bytesDistinct keno numbers in 1–80
Outcome compareDerived numbers vs official drawExact match

For a concrete illustration, suppose the server seed begins eff0d..., the client seed is c3d4..., and the nonce is 217. Rejection sampling from the HMAC output might yield numbers such as 12, 15, 33, 41, 47, 52, 58, 63, 70, and 78. These are entirely dependent on the exact seed strings; do not reuse them.

Critical Checks

  • Only trust the draw if the commitment was visible in a channel you could screenshot before the round, such as a live seed page, a signed message, or an on-chain note.
  • Verify the exact HMAC message format from the casino’s own documentation. A mismatch in the nonce separator or the order of client seed and server seed will produce different numbers.
  • Check that the nonce increments by 1 for each draw. If it seems reset or manually adjusted, you cannot verify chain continuity.
  • Check whether the casino permits a client-seed change mid-chain. If you change your seed, the nonce typically resets to 0; confirm this is consistent with the site’s rules.
  • For any casino review that claims a high RTP, include a sample of past keno draws in your verification to confirm the RTP estimate is plausible.

Limits of the Method

Verification works only if the pre-round commitment is recorded before the draw. If the operator presents only a post-round seed with no prior commitment, the game is not provably fair. The seed reveal must also be immediate; any delay that allows reseeding after the outcome breaks the chain. Finally, this method verifies a single draw, not the underlying game distribution. To check the keno house edge, you must aggregate hundreds of draws, which is a separate statistical audit.

You should also factor fair verification into your bankroll management. Even a provably fair keno game has a negative expected value; verifying the draw does not change the house edge.

FAQ

What if the derived keno numbers contain duplicates?

Use rejection sampling without replacement. Each byte sequence is tested; values above 80 are skipped. Duplicates are discarded until the required pick count is reached. The algorithm must be deterministic and published in the casino’s documentation.

Is a hash of the server seed enough to prove fairness?

Only if the hash was visible before the round. A hash shown after the round is meaningless because the operator could generate the seed to produce the desired outcome after the fact. The commitment needs a timestamp or a published location outside the casino’s control.

Do all casinos use the same hash chain format?

No. The basic commitment schema is the same, but the HMAC message format, seed encoding, and outcome derivation differ. Always read the operator’s provably fair documentation. For a list of operators whose documentation is auditable, see our news coverage.

More News

Commit-Reveal Schemes: The Cryptographic Contract Behind Every Fair Bet

Read more

Bonus Contribution Rates: Why Not All Games Clear Wagering Equally

Read more

XRP Casino Payouts: Speed and Cost Data for Players

Read more