A fake provably fair claim is one you cannot test: the phrase appears on the page, but the values needed to check a result do not. Of the 17 platforms in our registry, 9 publish enough for an outsider to reproduce an outcome and 8 do not, and all 17 use the words. Six checks, each under a minute, tell you which kind you are looking at.
The six checks
Run them in order. The first one a site fails is usually where it stops being verifiable.
| # | Check | A real claim looks like | A decorative one looks like |
|---|---|---|---|
| 1 | Is there a formula? | The hash function, the exact input string and the conversion, all named | "Advanced cryptographic hashing" |
| 2 | Fingerprint before play | A hashed server seed shown in advance | Nothing shown until after the opening |
| 3 | Real value afterward | The unhashed server seed appears when you rotate | A hash that never gets opened |
| 4 | You control a client seed | Visible and editable at any time | Missing, fixed, or assigned with no edit |
| 5 | Item ranges published | Ticket ranges or per-item odds you can read | A formula with no item table beside it |
| 6 | Checkable from outside | The same answer in a tool unrelated to the site | Only the operator's own verify button |
The detail behind each row follows.
1. Is there a formula, or only a description?
Look at the fairness page. A description reads like "our system uses advanced cryptographic hashing to guarantee random outcomes." A formula tells you the hash function, the exact string being hashed, and how the digest becomes a result.
You are looking for something you could hand to a programmer who has never seen the site. "SHA-512 of clientSeed:serverSeed:nonce, digest modulo 1,000,000, plus one" is a formula. "Advanced cryptographic hashing" is not.
This is the single most common failure, and it is usually not deliberate. Writing the marketing page is easy; publishing the algorithm means committing to it.
For a sense of the bar, two sites clear it in different ways. PackDraw publishes the actual JavaScript its site runs, so there is nothing left to interpret: SHA-512 over clientSeed:serverSeed:nonce, the 128-character digest reduced to a ticket from 1 to 1,000,000. JemLit goes further and publishes a worked example, a set of seeds and the exact roll they produce, 22.0231, which lets anyone confirm their implementation before trusting it on a real result. Either approach is enough. A page that describes hashing without naming the function, the input string or the conversion is not.
2. Can you see a fingerprint before you play?
Before your first open, the site should show you a hashed server seed. That hash is the commitment: it locks in a secret value without revealing it, so the site cannot change its mind after seeing what you do.
No fingerprint shown in advance means no commitment. Anything revealed afterwards could have been chosen afterwards.
3. Can you get the real value afterwards?
A commitment you can never open is worthless. The site must eventually reveal the unhashed server seed, normally when you rotate to a new one.
If a site shows a hash but never reveals what it was a hash of, you have been shown a sealed envelope that never gets opened.
4. Do you control a client seed?
Your own seed has to be part of the calculation, and you have to be able to change it. That is what stops a site from generating a server seed chosen to produce a specific bad outcome for you specifically.
If the client seed is missing, fixed, or assigned by the site with no way to edit it, the outcome depends entirely on values the operator picked.
5. Are the item ranges published?
Reproducing a number is only half the check. To confirm the number maps to the item you actually received, you need the ticket ranges or per-item odds.
Some sites publish a formula but no ranges. That is partial: you can confirm the roll was fixed in advance, but not that it corresponds to what landed in your account.
6. Can anyone outside the company check it?
This is the one that matters most and the one most often quietly failed.
A site can present a verify button that takes your seeds, does something invisible, and prints "valid." That proves nothing at all. The operator is being asked to confirm its own honesty, and the check has no independent meaning.
A real claim survives being taken elsewhere. If you can carry the seeds to a tool with no relationship to the site and get the same answer, the claim holds. If verification only ever happens inside the operator's own widget, you are trusting them exactly as much as you were before.
One test worth running yourself
There is a quick check that catches a specific kind of broken implementation.
Note the hashed server seed your account is currently showing. Now change your client seed, without rotating the server seed if the interface lets you do that separately. The server seed fingerprint should not move. It was committed already.
If changing your own seed also changes the committed server seed hash, the commitment is not doing its job: the site is re-deriving the secret after seeing your input, which is the exact thing the commitment exists to prevent. It usually means a sloppy implementation rather than deliberate manipulation, but the effect on you is the same. The result is no longer provably anything.
How to actually run the check
The six questions above tell you whether a claim is testable. This is how you test it.
Once a server seed has been revealed, take it along with your client seed and the nonce for the result you want to check, and recompute the outcome yourself. The tool below does exactly that, on your own device, with no connection to the operator. Nothing you paste is sent anywhere, which you can confirm in your browser's network tab.
Step 1Where did you play?
Using Ripster box / upgrade: HMAC-SHA256 over clientSeed:noncedetails
HMAC-SHA256 keyed with the server seed over clientSeed:nonce. The first 8 hex characters become a 32-bit integer, divided by 2^32 and multiplied by 100 for a roll in [0, 100). Items are sorted by item ID and selected by cumulative probability: the first item whose cumulative probability is at least the roll wins.
Where to find your numbers on Ripster.gg:
- Before rolling, copy the Server Seed Hash from the Provably Fair modal (also recorded per roll in Account History).
- After the roll, open the Provably Fair modal to copy the Server Seed, Client Seed and Nonce.
- Change your Client Seed anytime in Account Settings; doing so reveals the current Server Seed so all past rolls become verifiable.
Source: Ripster.gg's own fairness page
Step 2Paste your numbers
Runs entirely on your device via your browser's built-in cryptography. Don't take our word for it: open DevTools → Network, click the button, and watch: zero requests.
Runs entirely in your browser. Nothing you paste is sent anywhere.
Three things a passing check confirms at once: the revealed server seed matches the fingerprint published before you played, the outcome recomputes to the number the site gave you, and on platforms that publish ticket ranges, that number lands on the item you actually received.
The output ranges differ by platform, which is why the tool needs to know where you played. PackDraw resolves to a ticket from 1 to 1,000,000, Skin.club to a roll from 1 to 100,000, Clash.gg to a ticket from 0 to 99,999, and JemLit to a roll between 0 and 100 carried to 4 decimal places. A verifier built for one of those returns a plausible, wrong answer on another.
If the numbers do not line up, work through the mismatch before assuming the worst. A seed-format difference is far more likely than manipulation, and the platform pages record the exact format each site uses.
What the field actually looks like
We keep a registry of every platform we cover, recording exactly what each one publishes. It is not encouraging.
Of 17 platforms, 9 publish enough for an outsider to reproduce a result, and we have confirmed each of those against a real outcome rather than trusting the documentation. The other 8 do not. The reasons vary: some publish a narrative with no formula, some publish a formula but keep a step private, some have no fairness page at all, and one puts its verification code behind a login so nobody outside can read it.
Every one of those eight still uses the words, somewhere on the site.
The full breakdown, with the hash function, seed format and source for each, is on our algorithms by platform page. It is the shortest way to see which claims survive contact with the six checks above.
Failing is not the same as cheating
Worth being clear, because it is easy to read a failed check as proof of dishonesty.
A site that does not publish its algorithm has not been caught doing anything. It has simply not given you the means to check. Plenty of operators run honest software and write vague fairness pages, usually because nobody internally owned the problem.
What you can say is narrower and more useful: you cannot tell. With a verifiable site you do not have to trust anyone, because you can confirm it yourself. With a non-verifiable one you are back to trusting a company's word, which is where you were before the phrase "provably fair" appeared on the page. The claim was supposed to remove that requirement. When it cannot be tested, it has not removed anything.
And what a passing check still does not settle
A site can pass all six checks and still be a bad place to spend money.
Verification confirms that a specific result came from values fixed before you played. It says nothing about whether the odds are worth taking, whether a withdrawal will arrive, or how support behaves when something goes wrong. Those are separate questions with separate evidence, and we keep what provably fair does not prove as a standing page because the distinction gets collapsed so often.
If you are working through whether a specific site is worth using, the fairness check is one input among several, not the answer.
If any part of this has stopped being fun, take a break and get support.
The bottom line
A fake provably fair claim is not usually a lie. It is a claim with nothing behind it: no published formula, no fingerprint before play, no revealed seed afterwards, or no way for anyone outside the company to run the check. Any one of those turns the phrase back into "trust us", which is what it existed to replace.
Run the six checks the next time a site advertises it. They take about 5 minutes, and the first one a site fails is where its claim stops meaning anything. If you want the answer without doing the work yourself, our algorithms by platform page already records it for all 17 sites we cover, 9 of which currently pass.