A provably fair verifier proves a result only when it reproduces the game’s published algorithm exactly, from the revealed inputs through the final outcome mapping. Checking that a revealed server seed matches its earlier hash is necessary, but it does not establish that the outcome itself was computed correctly. A verifier that rounds a float differently, pads a number that should not be padded, or reads bytes in the wrong order will report a different result even when the seed commitment checks out.
What a verifier has to reproduce
A common commit-reveal design works in three stages. The operator publishes a hash of a secret server seed before a draw. The secret is then combined with player-controlled input and a nonce to derive deterministic bytes. Afterward the operator reveals the secret, and an independent party can check the commitment and recompute the outcome. The verifier’s job is the last step, and that step has many places to go wrong.
As an Amazon Associate I earn from qualifying purchases.
The exact construction is not universal. Each game or library defines its own message format, hash function, byte handling, and mapping from bytes to a result. Provable Core, for example, documents a design in which HMAC-SHA256 produces 32-byte rounds from a message of the form clientSeed:N:round. Groups of four bytes are converted to floats, and its unbiased integer path reads big-endian unsigned 32-bit values and rejects any value in the biased tail of the range. These are details of that one library. They are not a description of every casino or protocol, and a reader checking another game must follow that game’s own rules.
Two separate checks: the commitment and the replay
Verification involves two checks that answer different questions. Keep them separate when you report a result.
#1 Best Overall
- Commitment check. Hash the revealed server seed with the hash function the operator names, and compare the output with the commitment published before the draw. A match shows that the seed was fixed before the bets were placed. It says nothing about how the outcome was derived.
- Outcome replay. Take the revealed seed, the client seed, the nonce, and any cursor or round values, build the message exactly as the protocol specifies, run the HMAC or hash, and apply the game’s mapping. Compare the computed result with the result the game displayed.
- Record the protocol version. Note the exact version of the algorithm used for the replay. Mappings can change between releases, and a replay against the wrong version will disagree with a correct record.
The API guide from Provable.io describes this same two-part pattern: check the saved commitment against the revealed server seed, then replay the numeric result locally. A verifier that performs only the first step has not verified the outcome.
Protocol details that change the result
Several details that look like formatting can change the output of a hash, and therefore the outcome. A verifier has to preserve each of them.
- Seed strings and separators. A message such as
clientSeed:N:rounddepends on the colon separators and on the order of the fields. Adding a space, changing the order, or joining the fields with a different character produces different bytes. - Number formatting. The nonce is usually written in decimal. Whether it is zero-padded matters. A protocol example from 155.io documentation states that decimal indices are not zero-padded, so
7and007produce different hashes. - Hex as text. The same 155.io documentation says lowercase hexadecimal text is hashed as text when it feeds the next link in the chain. Decoding it into raw bytes first, or uppercasing it, changes the result.
- Byte order. Reading four bytes as big-endian rather than little-endian gives a different integer. The Provable Core integer path reads big-endian unsigned 32-bit values.
- Cursor advancement. When one hash supplies several outcomes, the verifier must advance the cursor in the same way the server does, including when a value is rejected and the next value is taken.
- Rejection behavior. Some integer methods discard values from a biased part of the range and take the next value. A verifier that accepts those values will drift out of step with the server after the first rejection.
Floats, rounding, and integer mappings
Floating-point arithmetic stores most decimal values as approximations. Two implementations that apply the same formula in a different order, or at a different precision, can produce slightly different values. When the result sits close to a threshold, such as a boundary between two outcomes, that small difference decides the outcome. NASA technical work on provably correct floating-point implementations is useful background for why this reproduction matters. It does not show that every provably fair system uses floating point.
When the protocol uses a float path
If the protocol converts bytes to floats, the verifier must reproduce the specified conversion, the order of arithmetic operations, and the rounding and boundary behavior of the final mapping. Substituting a mathematically equivalent formula is not enough if the server’s code evaluates it differently.
When the protocol uses an integer mapping
If the protocol defines a direct integer rule, the verifier should implement that rule exactly. Provable Core’s unbiased integer path is an example: it rejects values from the biased tail rather than taking the remainder of a modulus over the whole range.
Legacy methods
The same library keeps a float-to-integer method for replaying older results. Its documentation notes that it can be slightly biased when the range size does not divide 2^32 evenly. This is why a verifier must reproduce the server’s chosen mapping for the version that produced the result, rather than substituting a newer or more convenient method. A “fixed” mapping will produce results that disagree with the historical record.
Troubleshooting a mismatch
When a replay disagrees with the displayed result, the cause usually sits in one of a few places. Check them in this order.
Recommended Free Tools
| Symptom | Likely cause | Check |
|---|---|---|
| The commitment check fails | Wrong hash function, or the seed was copied with extra whitespace or a changed case | Hash the exact revealed seed string and compare it with the published commitment character for character |
| The first outcome is wrong but the commitment matches | Message construction: separators, field order, or nonce formatting | Print the exact message string and the first hash output, then compare with the protocol’s specification |
| Early outcomes match and later ones drift | Cursor advancement or rejection handling | Log each round index and each rejected value, and compare the sequence with the server’s |
| Outcomes near a boundary differ | Float evaluation order, precision, or rounding | Reproduce the conversion and mapping exactly as specified, and inspect intermediate float values |
| Only older results disagree | A different protocol version or a legacy mapping | Confirm the version in force when the result was generated |
What a matching replay does and does not establish
A replay that reproduces the displayed result shows that the revealed inputs, run through the documented algorithm, yield that result. That is a narrow and useful claim. It shows the outcome is consistent with the published rules.
Best Value
It does not, by itself, establish every wider claim about a gambling operator. It does not show that the production code matches the documentation, that the operator selected seeds honestly beyond the commitment, or that the game has behaved the same way over time. Audit methodology described by ProvablyFair.org adds source review, independent implementation, and live data collection as separate activities, which is why replay verification is usually one part of a wider investigation. For the same reason, the phrase “the result reproduces from these revealed inputs under this documented algorithm” is more defensible than saying a local replay proves an operator is fair.
How to compare verifiers
Verifiers differ in how completely they handle the details above. These are the questions worth asking of any verifier before relying on it.
- Does it name the exact protocol version it implements?
- Does it preserve seed strings, separators, and number formatting exactly as specified?
- Does it implement the required hash or HMAC, and extract bytes in the documented order?
- Does it match the nonce, cursor, and rejection behavior of the protocol?
- Does it apply the game’s own mapping, rather than a generic one?
- Does it expose intermediate values, such as the message string, the hash output, and each float or integer, so a divergence can be located?
- For high-stakes or public assurance, is it independently implemented, and has its output been checked against the server’s own code or live data?
A verifier that meets only the first two or three items can confirm that a seed matches a commitment. It cannot confirm the outcome.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Sources used for this article are the Provable Core library documentation, the Provable.io API guide, 155.io protocol documentation, a client-side verifier repository that shows game-specific mapping differences, a NASA technical paper on provably correct floating-point implementations, and the ProvablyFair.org audit methodology. The examples here come from these documents and should be read as examples, not as the rules for any particular game.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
