The short version
- A usable check needs a commitment made before the outcome and the later revealed inputs.
- Reproducing a random number is only part of verifying a game's displayed result.
- Verification does not establish favorable odds, withdrawal performance or regulatory status.
A commitment gives you something to compare later
In a commitment-based system, the operator publishes a hash of a secret server seed before the relevant outcome. Later, the seed can be revealed and hashed again. Matching the earlier value checks whether the revealed seed corresponds to the commitment. A hash is a fingerprint for this purpose, not an encrypted message that a player can simply decrypt to predict the next result.
Stake's implementation documentation describes this pattern and says rotating the server seed reveals the previous one. That is an example of its documented design, not a requirement that every operator use the same procedure. The essential editorial question is when the commitment became available: a hash shown only after a disputed result cannot establish that it was committed beforehand.
Know which inputs belong to the recorded event
Stake documents a server seed, client seed, nonce and cursor as inputs to its HMAC-SHA256 generator. In that implementation, the nonce advances between bets, while the cursor helps produce additional event data where required.
For an existing record, preserve the identifiers exactly, including punctuation and the event number. Do not substitute a current seed for the one associated with an earlier event. If the service exposes only a success badge, ask where the inputs and algorithm can be inspected. A screenshot of the result without its associated inputs does not let another person reproduce it. This is a recordkeeping requirement, not a suggestion to place a wager to obtain evidence.
Follow the calculation all the way to the displayed outcome
A generator produces data, but a game needs something recognizable: a card, a tile, a number or a prize. Stake publishes a separate conversion stage that turns bytes into numerical values and then maps those values to events. This separation explains why checking only the initial hash does not verify the whole result.
A reviewer needs the relevant conversion rules as well as the inputs. For a case-style product, that includes the prize ranges or payout table in force for the recorded event. If the number matches but the applicable prize table is missing, report the narrower result: the generator was reproducible, while the prize assignment remains unverified. That description is more informative than a single pass label covering several unexamined stages.
[2] Stake: Provably Fair Conversions[3] Stake: Provably Fair Game Events
A reproducible outcome can still have unfavorable economics
Stake's game-event documentation describes its Cases result as a generated value mapped against a predefined payout table. The table determines what outcomes are available and how they are assigned. The cryptographic calculation does not, by itself, tell a reader whether the entry price is good value.
The Gambling Commission explains RTP as an average over many plays and describes house edge as the casino's average advantage. Neither is a personal repayment schedule. Our inference is straightforward: a result can follow its published calculation exactly while the game still costs participants money on average. Inspect stated probabilities and prices separately from the verification method. If complete probabilities or meaningful payout values are unavailable, do not fill the gap with an invented RTP.
[3] Stake: Provably Fair Game Events[4] Gambling Commission: Return to player: how much gaming machines payout
Check the scope of the claim and what is actually visible
An implementation document applies to the games and versions it describes. Its presence on an operator's website does not automatically establish the method used by every product, provider or multiplayer mode. Ask which record is being verified and whether its exact game rules are covered by the published calculation.
Public access can also be incomplete. During this research, CaseHug's fairness URL exposed a site shell and footer but no usable algorithm in the retrieved text. That establishes a research limitation, not proof that an algorithm does not exist or that results are manipulated. Related reviews should distinguish readable documentation, inaccessible controls and an independently reproduced result. These are different evidence levels; none should be silently substituted for another.
[3] Stake: Provably Fair Game Events[5] CaseHug: Provably Fair page
Describe a verification result without overstating it
A useful verification note names the recorded event, the commitment captured before it, the revealed inputs, the algorithm version and the comparison outcome. It also states which stages could not be checked. Someone else should be able to understand whether the work compared a seed hash, regenerated a number, or reproduced the final event mapping.
The conclusion must stay within that scope. A matching calculation does not establish identity-check practices, available withdrawal methods, operator solvency or how a payment dispute would be handled. Those questions require other evidence. If a verifier reports a mismatch, first check that the inputs and game version correspond to the same event, then preserve the discrepancy. Neither a match nor a mismatch is a reason to spend more.
[1] Stake: Provably Fair Implementation[2] Stake: Provably Fair Conversions
Questions & answers
Can changing a client seed guarantee a better result?
No. It changes an input in the documented calculation; it does not supply a guaranteed favorable outcome or reveal the hidden server input.
Is matching the server-seed hash enough?
It checks the commitment. Verifying the displayed game result also requires the generator inputs and the correct conversion or prize mapping.
[2] Stake: Provably Fair Conversions[3] Stake: Provably Fair Game Events
Does provably fair mean the site will pay withdrawals?
No. Reproducing a game calculation does not test a payment process. A fairness claim and evidence about completed withdrawals answer different questions.
Does RTP predict what I will get back in one session?
No. It describes an average across many plays, not the amount a particular person will recover during a session.
[4] Gambling Commission: Return to player: how much gaming machines payout
Sources & limits
Public documentation checked on 2026-09-10. Stake pages were readable; CaseHug's fairness page yielded only a shell and is registered solely as an access limitation. No game result was independently recalculated, no account was opened and no wager was placed. Limits of inference are editorial analysis, not a rating or certification of any related operator.
- Stake: Provably Fair ImplementationPublic official implementation documentation and sample code opened and read. · 10 Sept 2026 · Documentation review only; no seeds rotated, accounts accessed or results tested. Hashing is explained as a commitment rather than reversible encryption.
- Stake: Provably Fair ConversionsPublic official conversion documentation and sample code opened and read. · 10 Sept 2026 · Supports the distinction between generated bytes, numerical values and game-specific mapping; no independent code execution.
- Stake: Provably Fair Game EventsPublic official game-event documentation opened; Cases and game-specific mapping sections inspected. · 10 Sept 2026 · Examples describe Stake's documented system only and do not establish another operator's implementation.
- Gambling Commission: Return to player: how much gaming machines payoutPublic regulator guidance opened and read; page displays last updated 16 June 2021. · 10 Sept 2026 · Used for the statistical meaning of RTP and house edge, not to apply British gaming-machine rules to skin sites.
- CaseHug: Provably Fair pagePublic official URL opened, but extraction exposed only site shell, footer and placeholder counters. · 10 Sept 2026 · Algorithm and verifier unavailable in retrieved text. This source supports an access limitation only, not a fairness claim.
General information, not a promise about an individual account or transaction. How we research · Responsible play and support.
