Provably fair casino games: how seeds, hashes and verification fit together

Short answer

Verify the commitment first, then reproduce the event

Provably fair is an after-the-fact verification method for supported games. Before a bet, the operator shows a cryptographic hash of a secret server seed. The player supplies or accepts a client seed, while a nonce identifies the round. After the active server seed is rotated and revealed, a verifier can check both the earlier commitment and the calculation that produced a displayed result.

The first test is exact: hash the revealed server seed with the documented hash function and compare the resulting text with the pre-bet hash. One changed character should produce a different digest. A match supports that the revealed value is the same value to which the operator committed; it does not by itself prove the displayed game event was calculated correctly.

The second test uses the operator’s published algorithm. Stake’s documented example feeds server seed, client seed, nonce and cursor into HMAC-SHA256, converts output bytes into numbers between zero and one, then maps those numbers to a game-specific event. A valid reproduction must use the exact historic inputs, settings and mapping, not a similar game or a current seed pair.

The scope stays narrow. A successful reproduction says nothing about whether the payout table offers positive value, whether funds are solvent or segregated, whether an account is allowed in New Zealand, or whether a withdrawal will be honoured. Those are different claims requiring different records.

Evidence boundary

What a provably fair check can—and cannot—establish

A commitment-and-reproduction check can support three related propositions: the operator committed to a hidden server input before the event; the revealed input matches that commitment; and the published algorithm converts the recorded inputs into the result stored in game history. Each proposition requires its own evidence.

It cannot demonstrate that the published algorithm is economically favourable. A deterministic mapping can be completely reproducible while reserving a house edge. It also cannot prove that every possible input is sampled with the claimed probability unless the generation and mapping have been analysed more broadly.

Verification does not make an operator trustworthy in every other respect. A site can expose a correct calculator and still have restrictive identity checks, unclear custody, slow or refused withdrawals, weak account security or territorial conflicts. Game-result evidence should never replace operator due diligence.

Nor does the label apply automatically to every game in a lobby. Stake says its Originals and supported Stake Engine games use its system, while third-party slots can rely on their own RNG and testing. Check the exact title and its history interface rather than treating the casino logo as universal proof.

Inputs

Server seed, client seed, nonce and cursor serve different jobs

The server seed is a secret value generated by the operator. Stake documents a random 64-character hexadecimal value and publishes a hash of it while the original remains hidden. Hiding the active value helps prevent a player from computing future events, while the public digest binds the operator to one specific value.

The client seed is the player-side input. A platform can create one in the browser, but a supported interface may allow the player to replace it. Control of this input means the result is not based solely on a secret chosen by the operator. It does not let the player choose a winning result because the active server seed remains unknown.

The nonce is an incrementing number used with the same seed pair. It changes for each bet or qualifying action, producing a different deterministic output without rotating seeds every time. An off-by-one nonce is enough to reproduce the wrong event, so the historic value must be copied exactly.

A cursor supplies additional output when one event needs more random values than one hash block conveniently provides. Card sequences, multi-tile boards and bonus rounds can consume several values. The cursor is an implementation detail that matters whenever the published verifier or algorithm requests it.

Before-the-bet evidence

A hash is a commitment, not an encrypted preview of the result

A cryptographic hash takes an input of arbitrary length and returns a fixed-length digest. It is designed so that recovering the original input from the digest is computationally impractical and small input changes produce different output. The pre-bet digest lets the operator commit without revealing the active server seed.

The word “encrypted” is sometimes used loosely in casino interfaces, but hashing and encryption are different. Encryption is intended to be reversed with a key; a secure hash is one-way. Verification does not decrypt the old digest. It hashes the later revealed seed and compares the two digests.

The commitment only has evidential value if it is preserved before the relevant bet. Saving a hash after the result is displayed does not prove that it existed earlier. Capture the pre-bet hash, client seed and starting nonce with a timestamp or export them from the game’s own history.

Matching lengths or prefixes are insufficient. The complete digest must match character for character under the documented encoding and algorithm. Uppercase versus lowercase hexadecimal may be display formatting, but hidden whitespace, character encoding and copied punctuation can change the underlying input.

Reveal stage

Seed rotation retires the active chain before disclosure

The operator cannot reveal an active server seed safely if that value would allow future outcomes to be calculated. Stake therefore reveals an old seed after the player rotates to a newly generated pair. The old chain becomes auditable while the new server seed remains hidden behind a new hash.

Rotation is not proof on its own. After rotating, save the revealed old server seed and confirm that the account interface associates it with the earlier hash. Then run the hash comparison. A seed shown without its pre-rotation commitment has lost the chronology required for the first test.

Do not expect changing a client seed or rotating a server seed to improve expected return. These actions create a new deterministic chain and verification record; they do not remove the payout mapping or house edge. Repeated rotation can also make records harder to organise.

A useful naming scheme records the retired hash, revealed seed, client seed, nonce range and date together. Keep the new active hash separate. Mixing values from two chains is the most common way to create an apparent verification failure that is actually a recordkeeping error.

Deterministic replay

The same complete inputs must reproduce the same bytes

Stake’s implementation uses HMAC-SHA256. Its documented byte generator treats the server seed as the HMAC key and updates the function with the client seed, nonce and current round derived from the cursor. The 32-byte output becomes the source material for one or more game values.

Deterministic means identical inputs under the same code produce identical output. This property makes after-the-fact checking possible. It does not mean the output was predictable before the secret server seed was disclosed.

Every input must match the historical record: server seed, client seed, nonce, cursor start, encoding and game-specific settings. Risk level, number of mines, deck rules or selected segment count can affect mapping even where the cryptographic bytes remain the same.

An operator calculator is convenient, but an independent implementation gives stronger evidence that the published formula itself reproduces the event. Use code from a source you can inspect, compare more than one implementation when practical, and never paste account credentials or wallet secrets into a verifier.

Conversion layer

Hash bytes become floats before they become game events

A raw HMAC digest is not yet a dice roll, card or mine location. Stake documents grouping four bytes at a time and converting each group into a number from zero up to, but not including, one. Each byte contributes decreasing fractional precision based on powers of 256.

The conversion formula must be reproduced exactly. Changing byte order, rounding too early or reading a hexadecimal pair incorrectly can produce a different float. A verifier should compare intermediate bytes and floats before concluding the final mapping is wrong.

When a game needs more values, the generator continues through the digest and advances the cursor or round as documented. Ignoring that continuation can make the first event match while later cards, tiles or bonus events diverge.

A float is still only a neutral random value. The next layer decides what it means for one game. This separation is important because a correct cryptographic generator and an incorrect game-event mapping can lead to different displayed outcomes.

Game-specific rules

The same float can map differently in Dice, Mines or cards

Stake’s event documentation multiplies a float by the number of possible outcomes for simple indexed events. European-style roulette uses 37 pockets; a card selection begins with 52 possibilities; Dice converts a float into its displayed numerical range. Each title has its own translation and rounding rules.

Games without replacement need extra handling. Stake documents Fisher–Yates-style selection for examples such as Mines, Keno and Video Poker so a tile or card is not selected twice in the same event. The pool shrinks after each choice, changing the multiplier used for the next float.

Risk settings and payout tables can be part of the mapping. A Wheel result needs the chosen segment count and risk table; a Mines result needs the board and mine count for the history entry. The cryptographic output alone cannot reconstruct a visible award without those rules.

Always use documentation for the version played. A later mapping change can leave older history governed by earlier code. If no versioned algorithm or verifier is available, record that limitation instead of claiming independent reproduction.

No real wager required

A safe practice run uses invented values and a toy mapping

Consider an educational example that does not touch a casino account. Write a fictional server seed such as “server-example-01”, a client seed such as “client-example-01” and nonce 0. Calculate a SHA-256 digest of the fictional server seed and save it as the prior commitment.

Next, use a local HMAC-SHA256 tool with the server seed as key and the text “client-example-01:0:0” as message, following Stake’s documented structure. Record the first four output bytes and convert them to a float using the published powers-of-256 calculation.

For a toy coin mapping only, define values below 0.5 as tails and values at or above 0.5 as heads. The resulting side should be reproduced every time the inputs and code remain identical. Incrementing the nonce to 1 should create another deterministic result.

This exercise teaches commitment, secrecy, reproduction and mapping without a stake. It is not a verification of Stake or any other operator because the invented values were never committed by that operator and the toy coin rule may not match a real game.

Audit trail

Save the values needed to distinguish a mismatch from a copying error

A complete event record includes operator and domain, game name, game version where shown, event or round ID, UTC time, server-seed hash, client seed, nonce, cursor if relevant, selected risk settings, displayed outcome and stake. After rotation, add the revealed server seed.

Screenshots are helpful but text export is better for long seeds and hashes because images invite transcription mistakes. Preserve both when possible: the screenshot proves context while the copied values support exact calculation.

Record the algorithm page and date. A generic statement that a game is “provably fair” is not enough to reproduce it. The hash function, input order, delimiters, byte conversion and event mapping all matter.

Do not publish active server seeds, account identifiers or sensitive history indiscriminately. Verification values are not supposed to be wallet private keys, but an account screenshot can still expose balances, email addresses or transaction data. Redact unrelated personal information.

Diagnosis

Different failures point to different parts of the chain

If the revealed server seed does not hash to the saved commitment, first check whitespace, encoding, copied characters and whether the values belong to the same rotation. After those checks, a genuine mismatch undermines the commitment and should be preserved for escalation.

If the commitment matches but HMAC bytes differ, inspect the key/message order, separators, nonce and cursor. A calculator that silently normalises text may not reproduce the documented implementation.

If bytes and floats match but the visible event differs, the likely issue sits in the game mapping or settings. Confirm risk mode, board size, payout table, event index and version. This is why a generic seed checker is not sufficient for every title.

If the event matches but the credited amount differs, the question may be paytable application, stake denomination or account settlement rather than randomness. Preserve the complete round and use the operator’s dispute route. Do not place another bet in an attempt to “test” the missing credit.

Mathematical limit

Reproducible randomness can still carry negative expectation

Provably fair verifies how an outcome was selected under published inputs. It does not remove zero-value sectors, payout deductions or other design choices that create a house edge. Stake’s event documentation itself shows mappings in which payout tables incorporate a stated edge.

RTP and house edge describe the probability-weighted average over the full model. Verifying ten losing events does not show that the RTP is false, and verifying one large win does not show that the game is profitable. A result proof is not a sample-size proof.

The client seed cannot steer value when the server seed remains secret. Searching client seeds after seeing a revealed old chain does not predict a different active chain. Claims that a “lucky seed” guarantees wins confuse deterministic replay with advance knowledge.

Use the site’s RTP and house-edge guide for the long-run distinction and the independent outcomes guide for sequence myths. Provably fair adds an audit trail; it does not reverse either principle.

Cryptographic limit

A strong hash cannot rescue weak operations or undisclosed code

SHA-256 and HMAC-SHA256 are established primitives, but system quality depends on more than naming them. Server seeds need sufficient entropy, secret handling must prevent premature disclosure, input parsing must be unambiguous and the implementation must match the code shown to users.

A public verifier can contain a mistake or omit a game-specific step. Open source improves inspectability but does not automatically prove deployed servers use identical code. Independent testing, version records and repeated reproduction add confidence.

Browser extensions and downloadable “seed crackers” are a security risk. A legitimate verifier needs seeds and game parameters, not a wallet private key, recovery phrase, password or remote access. Never disclose those credentials.

Hash commitments prevent changing the committed server value unnoticed after the fact. They do not prove the original seed was generated without bias unless the generation process is also trustworthy and the client input meaningfully enters the calculation.

Commercial limit

Fair-result evidence does not establish custody or withdrawals

A player may verify every game event and still face account risks. The operator controls deposits, balances, identity review, bonus restrictions, account closure and withdrawals under its terms. Provably fair code does not prove that liabilities are fully funded.

Check the contracting company, licence claims, restricted countries, KYC powers, supported assets and networks, withdrawal limits and complaint route separately. The NZ crypto-casino evaluation checklist keeps those operator questions distinct.

Do not treat a successful hash match as an endorsement of the casino. It is one positive result about one technical claim. The most reliable review preserves both what was verified and everything the test could not reach.

The two sponsored buttons on this article lead through the site’s existing separate-offer route. They are not labelled as access to Stake or to a provably fair verifier, and they do not establish eligibility for the operator used as the technical example.

Related but different

Provably fair and certified RNG answer different trust questions

A conventional remote game can use a tested random number generator without exposing seeds to each player. Confidence comes from software controls, test-house review and regulatory requirements. The player normally cannot reproduce an individual result from public inputs.

A provably fair system exposes an event-level verification trail. It lets the player reproduce supported outcomes, but its quality still depends on the published implementation, mapping and secure commitment process. Neither category is automatically honest merely because of a label.

The two approaches can coexist. Stake describes RNG processes alongside its commitment scheme. The useful comparison is not “cryptocurrency versus regulation”; it is which claims are independently checkable, which are externally tested and what remains under operator control.

Never call an external provider slot provably fair just because it appears beside an Original. Look for the exact game’s fairness modal, historic values and reproducible mapping.

Calculator hygiene

Use the operator tool for convenience and an independent tool for confirmation

Stake’s calculator asks for the game, client seed, server seed and nonce, with more settings required where the mapping needs them. It is a convenient first pass and reduces copying complexity.

An operator-hosted result alone is not fully independent because the same party supplies the game and checker. Reproducing the documented calculation locally or in a separately maintained open-source verifier provides an additional comparison.

Inspect the tool before entering data. Confirm the URL, code availability, supported game and version. A generic hash page can check the seed commitment but cannot necessarily recreate floats, shuffles and payouts.

Test with public or invented values before real history. That confirms formatting without exposing account data. If two tools disagree, compare intermediate hash, bytes and floats rather than choosing the answer you prefer.

Local context

New Zealand eligibility remains an operator-level question

This technical guide does not establish that Stake or another crypto casino may accept a particular New Zealand resident. Country restrictions, identity, age, location and the changing New Zealand regulatory transition must be checked at the point of use.

A reachable website, an NZ flag or a working fairness calculator is not a contractual permission signal. Read the current terms for the exact domain and contracting entity, then compare them with the site’s dated New Zealand legal-status guide.

Do not make a deposit merely to obtain a sample. The worked method can be learned using invented inputs, published examples or a free demo when permitted. Real-money testing creates financial exposure without improving the logic of the verification.

If gambling stops being recreational, use the contacts in the responsible gambling guide. Technical curiosity should never become a reason to chase losses or keep an account open.

Practical workflow

Provably fair verification checklist

1. Confirm the exact game exposes a supported provably fair history.
2. Save the server-seed hash before the event.
3. Save the client seed, nonce, cursor and game settings.
4. Record the round ID, time, stake and displayed result.
5. Rotate only when ready to retire and reveal the active server seed.
6. Hash the revealed seed and compare the complete earlier commitment.
7. Run the documented HMAC and compare intermediate bytes.
8. Convert bytes to floats without premature rounding.
9. Apply the exact game-version mapping and settings.
10. Compare the reproduced event and settlement with history.
11. Diagnose mismatches by layer and preserve evidence.
12. Keep house edge, custody, withdrawals and NZ eligibility as separate checks.

A reliable conclusion is specific: “the recorded event reproduced under the documented inputs” or “the commitment could not be matched after formatting checks.” Avoid broader claims such as “the casino is safe” or “all games are fair.”