We Recalculated a "Provably Fair" Casino by Hand — Here's What Real Verification Looks Like

“Provably fair” is a promise: that you can check any result yourself, with math, instead of taking the casino’s word for it. It is a good promise. But a promise that something can be verified is only worth anything if something actually is verifiable — and those two are not the same thing.

What follows is a documented case — one the casino, Winna, has since corrected — where the site carried the words “provably fair” for months while, by multiple independent accounts, none of it could actually be reproduced. We’ll walk through what was reported, and then we’ll do the part almost no review site bothers with: we recompute the numbers ourselves, from public values, so you can follow along on your own keyboard.

What “verifiable” actually requires

A real provably fair round has four moving parts, and you need every one of them:

1. The casino commits to a server seed before you bet, by publishing its hash.
2. After the round it reveals the server seed. You hash it yourself; it must match the hash shown earlier.
3. Your client seed and the nonce (the round counter) combine with the server seed.
4. A published formula turns that into the result.

If even one link is missing — no revealed seed, an unreproducible hash, no client seed of your own — there is nothing to check. The badge is still there. The proof is not.

The case: months of a badge that couldn’t be checked

Between late 2025 and early 2026, independent testers on Bitcointalk reported three concrete problems with Winna’s original games. We report these as their observations, not as our findings:

• The pre-round hash could not be reproduced from the later-revealed server seed. One tester ran it against roughly 45 common hashing methods; none produced a match.
• Players could not choose their own client seed — which is the single thing that stops the house from picking a seed it likes.
• Zero-value bets changed the result without advancing the nonce, implying the outcome drew on something outside the public commitment.

We are not claiming any bet was manipulated. The point is narrower, and in a way worse: for that period, you simply could not tell. A “provably fair” label on a system nobody outside the company can reproduce is decoration, not proof.

So we did the auditor’s part — we recomputed it

Winna later moved to a standard scheme: single-SHA-256 server seeds and user-selectable client seeds. We took a published seed pair from that corrected system and verified it ourselves. You can repeat every step.

Step 1 — check the commitment. The revealed server seed is the text string:

ed54303ccab80736f0be7cd109e7830edd150674a4dea9ca39daadc244a569bb

Take the SHA-256 of that string as text characters — not the hex decoded into bytes; the characters exactly as shown. You get:

28e1731d4e629c05ad1e93e4a7bea7783f906829ba5857f388353488f197363e

That is exactly the hash the site showed before the round. The envelope was sealed and untouched. One practical warning, because we tripped over it ourselves: make sure your tool hashes the 64 characters as text, with no trailing newline — the cursor must sit right after the last character. You should get 28e1731d…. If you get anything else, your tool appended a line break (a single invisible newline changes the entire hash) or converted the hex string into raw bytes. That is not the article being wrong; it is the exact trap this whole piece is about.

Step 2 — recompute the result. Inputs: the server seed above, client seed test1, nonce 1, round 0. Compute HMAC-SHA256(key = server seed, message = "test1:1:0"). It begins:

f531047f…

Take the first four bytes — f5 31 04 7f = 245, 49, 4, 127 — and turn them into a fraction between 0 and 1:

245/256 + 49/256² + 4/256³ + 127/256⁴ = 0.9577791986521…

This particular game applies a 1% house edge — the 0.99 factor below is that game’s own parameter, nothing more — so the multiplier is:

0.99 ÷ 0.9577791986521 = 1.033641…, rounded down to 1.03×

That is the whole loop. Every value is public; every step runs in a browser console or a free SHA-256 tool. That is what verifiable looks like — and it is exactly the check that returned nothing for months.

The fix is the point — not a footnote

Notice what we just demonstrated: the corrected system verifies. We say that plainly, up front, because a watchdog that publishes only the failure and buries the fix is running a grudge, not an audit. Winna had a real, documented problem; testers surfaced it; the casino changed its scheme; and now the math checks out — we confirmed it by hand.

But sit with the earlier state for a moment. For months the site carried the same two words it carries now. The badge never changed. What changed was whether the badge meant anything. That is the whole lesson: “provably fair” is not a property you can read off a logo. It is a property you — or an independent auditor — actually reproduce, or it isn’t there. We make the same argument, without the case, in why “provably fair” doesn’t mean fair and in why crash stats prove nothing.

What to actually do

Don’t read the badge. Read the math — or find someone who will. Take one revealed server seed, hash the text string, and see whether it matches what you were shown before the round. Then rebuild one result from the seeds and the nonce. If it all lines up, you have verifiability you can stand on. If it doesn’t — or if you can’t even get the pieces — then “provably fair” is just “trust us” with extra syllables. Our step-by-step walkthrough is in Provably Fair explained — how to verify a round yourself.

The badge is for the audience. The reproduction is the proof. Never confuse the two.