Provably-Fair Verifier
Recompute a round from its seed triple, in your browser, against the operator's published result.
This checks that a round's server seed matches what was committed to beforehand, and that the seed triple reproduces a result under a named, documented scheme. It cannot check a scheme this page does not implement, and it says nothing about whether the game's odds are fair to play.
The round
Verification
Both checks verify
The server seed matches what was committed to beforehand, and the round result follows from the seed triple you entered.
Commitment verified
computed sha256
7b3d979ca8330a94fa7e9e1b466d8b99e0bcdea1ec90596c0dcc8d7ef6b4300c
published
7b3d979ca8330a94fa7e9e1b466d8b99e0bcdea1ec90596c0dcc8d7ef6b4300c
Outcome verified
Computed roll
85.86
float 0.858575Float chain scheme
Every calculation above runs in your browser using the Web Crypto API. Nothing you type here is sent anywhere, logged, or kept once you leave the page. A verified result means this round was not tampered with; it says nothing about whether the game itself is worth playing.
Written and reviewed by Alexander Korsager · last reviewed October 8, 2026 · corrections
The idea
What this tool shows
Provably fair is a mechanic most crypto-friendly casinos use to let a player check that a round was not altered after the fact. Before you play, the operator publishes a hash of a server seed it has not shown you yet. After the round, it reveals the server seed. If the seed hashes to the value it published beforehand, it could not have been swapped once your client seed was known, and if the seed and the client seed and the round's nonce produce the result you were shown, the round itself was not tampered with.
Both of those are checks this page can run entirely in your browser: an HMAC-SHA256 and a SHA-256 are ordinary arithmetic, not a lookup against anyone's server.Nothing you paste here is sent anywhere, logged, or kept after you close the tab.
What a green result proves is narrower than it sounds, and worth stating plainly: it proves this round's outcome follows from these seeds, and that the server seed matches what was committed to beforehand. It says nothing about whether the game's odds are fair. A verified round on a game with a 30% house edge is still a 30% house edge; provably fair is about tampering, not about value.
Implementations disagree on exactly how the seed triple becomes a game result, so this tool asks you to pick the scheme your operator documents rather than guessing at one. Pick wrong and a perfectly honest round can look like a mismatch, which is the opposite of what a fairness check should tell you; see the FAQ below before reading a mismatch as evidence of anything.
FAQ
Questions players ask
What does a green result actually prove?
Two separate things, and only these two. The commitment check proves the server seed you were given matches the hash the operator published before the round, so it was not swapped after your client seed was known. The outcome check proves the round result follows from the seed triple under the scheme you selected. Neither says anything about whether the game's underlying odds are fair to play. A provably-fair coin flip can still be a 48/52 coin flip; the mechanic verifies that the coin was not switched mid-flip, not that it is unweighted.
The commitment check passed but the outcome check did not. What does that mean?
Almost always, the wrong scheme is selected, the wrong nonce was entered, or a value was copied with extra whitespace or a missing character, rather than anything about the operator. The commitment check passing tells you the server seed itself is genuine, which is the harder thing to fake; a scheme or nonce mismatch is a much more common explanation for a failed outcome check than tampering. Re-check the scheme your operator documents, the exact nonce for that specific round, and that every field was pasted in full before concluding anything.
The commitment check failed. Does that mean the casino cheated?
It means the server seed you have does not hash to what was published beforehand, which is a serious mismatch and much harder to explain innocently than a scheme mix-up. Before concluding anything, check that you copied the published hash from the same round the seed came from, and that neither value picked up a stray character. If both check out, ask the operator in writing for the seed triple for that specific round; a genuine mismatch is something to raise with them directly, not something this page can adjudicate further.
Is anything I type here sent anywhere?
No. Every calculation on this page runs in your browser using the Web Crypto API, the same cryptography built into the browser itself. Nothing you paste is sent to actfap, logged, stored, or included in any analytics event. You can verify this yourself: disconnect from the network after the page has loaded and the tool keeps working.
Why does the tool need me to pick a scheme?
Every provably-fair implementation agrees on using HMAC-SHA256 to turn the seeds into a result, and disagrees on exactly how the output bytes become a game outcome. Applying the wrong construction to a genuine seed triple produces a different number from the right one, which would read as a failed outcome check on an honest round. This tool implements two named, documented constructions rather than one presented as universal; check which one your operator's own fairness page documents before relying on a mismatch here.
Methodology
How this is calculated
Two independent checks, both pure local arithmetic. The commitment check hashes the server seed with SHA-256 and compares it to the hash you say was published before the round.
The outcome check runs HMAC-SHA256 keyed by the server seed over the client seed and nonce (and, under the float-chain scheme, a cursor), then reads the resulting bytes as a float in [0, 1). Two schemes are implemented because implementations disagree on the byte-to-outcome step, and on how that float becomes the displayed roll: float-chain reads four bytes of the HMAC digest as b0/256 + b1/256^2 + b2/256^3 + b3/256^4, the construction Stake documents and many other operators reuse, and its roll is floor(float x 10001) / 100, not the float scaled by 100 and rounded, because 0.00 to 100.00 inclusive is 10,001 distinct two-decimal outcomes rather than a continuous value; single-draw reads the first 52 bits of the HMAC's hex digest as an integer, divides by 2^52, and has no equivalently documented display step, so its roll is that float scaled by 100. Both are named on the page next to the result they produced, so a reader can tell which one ran.
Common misreadings3
- A verified round is not evidence the game is worth playing. It rules out retroactive tampering with this specific round; it says nothing about the house edge, the volatility, or whether the odds published elsewhere on the operator's site are the odds actually in effect.
- A failed outcome check with a passed commitment check is much more often a wrong scheme or a wrong nonce than evidence of cheating, per the FAQ above. Read a mismatch as a prompt to re-check your inputs before reading it as a finding about the operator.
- A failed commitment check is a real discrepancy and a more serious one, but it is still not this page's place to adjudicate. Confirm the hash and seed are from the same round before raising it, and raise it with the operator directly.
Assumptions4
- The hash you enter is the one the operator actually published before the round, not one you are recalling or that was shown to you after the fact. The commitment check can only compare against what you provide it.
- The nonce is the exact per-round counter your operator uses, usually starting at 0 or 1 and incrementing once per bet on the same seed pair. A one-off error here changes the entire result, and looks identical to a genuine mismatch.
- The scheme you select matches the one your operator's own fairness documentation describes. This page cannot detect that the wrong scheme was picked; a wrong scheme and a tampered round both fail the outcome check identically.
- The float-chain scheme reads the first float from cursor 0. A game that draws more than one value per round, such as a card shuffle or a grid of independent tiles, consumes further floats from the same HMAC output or hashes again at a later cursor; this tool checks only the first draw.
Limits5
- This is not a general-purpose provably-fair suite. It implements two named constructions and reports which one it used; a third, undocumented construction is out of scope rather than silently approximated. If your operator's documentation describes something else, this tool cannot check it.
- The outcome check verifies the underlying random draw (a float and a Dice-style roll), not a specific game's rendered result. Whether that draw is a 47 on a roulette wheel or a specific card requires knowing the operator's own mapping from draw to game outcome, which this page does not attempt to model for every game.
- A roll is compared to a published value within 0.005. For float-chain this tolerance is mostly headroom, since floor(float x 10001) / 100 already lands on the same two-decimal value a real client displays; for single-draw, which has no equivalently documented display step, it absorbs the rounding a two-decimal on-screen display would have applied before you copied the figure.
- Nothing here can verify that the client seed itself was genuinely yours, only that the arithmetic connecting the three inputs to a result is correct. Some implementations let the operator supply part of the client seed too; this tool has no way to know whether that happened.
- The two schemes are not equally well checked, and it is worth knowing which one you are on. Float-chain is pinned against reference values published by an independent open-source verifier, so its float and its Dice roll are known to match what a third party's code produces for the same seeds. Single-draw has no equivalent published vector we could find, so it is checked only against a hand derivation of the same construction. A single-draw mismatch is correspondingly weaker evidence about the operator than a float-chain one.
Evidence
sha256Hex, hmacSha256Hex and computeOutcome in math.ts implement SHA-256 and HMAC-SHA256 via the Web Crypto API, and math.test.ts pins every one of them against an independent computation using Node's own node:crypto module (createHash/createHmac), a completely separate implementation, rather than checking the code against itself.
The SHA-256 of the empty string is additionally checked against the published FIPS 180-4 test vector.
The float-chain and single-draw byte-to-float formulas are each independently derived by hand from the raw HMAC output in the test file before being compared to what math.ts returns. float-chain's floor(float x 10001) / 100 roll formula is corroborated by two independently published technical write-ups of Stake's Dice implementation (a byte-level breakdown at https://news.tapiwa.me/provably-fair-dice-mines/, retrieved 2026-09-13, and a dedicated roll-formula explainer referenced from the same search at https://provenlyfair.com/blog/verify-provably-fair-dice/, retrieved 2026-09-13 by title and summary only; Stake's own implementation page returned an HTTP 403 to this tool's fetch and could not be read directly).
This was a real, live defect until 2026-09-14: math.ts previously computed every scheme's roll as the float scaled by 100, and a brute-force comparison in math.test.ts across 2,000 nonces on one seed pair shows the two formulas disagreeing by more than the page's own 0.005 tolerance on roughly a quarter of them, which would have read as a false outcome mismatch on an honestly unaltered round.
Re-checked 2026-09-14: Stake's page and the more specific of the two secondary write-ups (provenlyfair.com) both still returned HTTP 403 to a direct fetch, and news.tapiwa.me's own worked example was an unfilled placeholder with no seed values or resulting roll, so that pass closed with checked: false rather than guessing at a reference.
Since 2026-09-15 the float-chain scheme is checked end to end against reference values published by a genuine third party instead: lucasholder/fair (MIT, https://github.com/lucasholder/fair, retrieved 2026-09-15), an open-source verifier written by someone unconnected to this site and stating that its results reproduce Stake.com's.
Its committed test values for the float chain (server seed "some server seed", client seed "some client seed", nonce 1, first float 0.5919261889066547) and for two Dice rolls (server seed "server seed", client seed "client seed", rolls of 74.67 at nonce 1 and 53.86 at nonce 2) are reproduced exactly by this tool, and its published hash of that server seed is reproduced by the commitment check.
That matters because every other check here compares our arithmetic to a second derivation we wrote ourselves, which agrees perfectly when both derive the same misreading of the scheme.
A passing test means this page's arithmetic matches an independent implementation of the documented schemes; it cannot prove that any specific operator implements the scheme you selected. The single-draw scheme still has no comparable third-party reference vector and remains checked against a hand derivation only.
Gambling can cause serious harm. The National Problem Gambling Helpline is free, confidential and open 24/7, call or text 1-800-MY-RESET (1-800-697-3738), or chat at ncpgambling.org/chat.
Related tools