How to Verify a Stake Bet in Minutes
Yes, you can verify a Stake bet yourself. Every Stake Original round is built on a provably fair system, which means you can re-compute the HMAC-SHA256 hash from the server seed, your client seed, and the nonce, then check that the math matches what the game showed you.
You need three things pulled straight from the bet you're checking:
- The revealed server seed for that session
- Your client seed
- The nonce (round number) for that specific bet
If you want the fastest path, skip manual hashing and run the numbers through Stakestats' Stake Originals Analyzer, which does the computation client-side in seconds.
Key Takeaways
Verifying a Stake bet comes down to three inputs, one HMAC calculation, and a game-specific conversion rule you can reproduce yourself in minutes.
| Point | Details |
|---|---|
| Three required inputs | Collect the raw server seed, your client seed, and the exact nonce before running any check. |
| Hash versus seed | The server-seed hash is a commitment; you need the raw seed, revealed only after rotation. |
| Same math, different outputs | Dice, Crash, Mines, Plinko, and Keno each apply a different rule to the same converted number. |
| Client-side checks protect privacy | Tools that compute HMAC in your browser never send your seed data to a server. |
| Fastest verifier for Stake Originals | Stakestats' Stake Originals Analyzer runs the full check client-side without manual coding. |
Table of Contents
- What You Need to Verify Stake Wager Outcomes
- How Stake Bet Verification Actually Works
- A Step-by-Step Example: Verifying a Dice Bet
- What Verifiers Can't Do, and Where They Go Wrong
- Which Verifier Should You Actually Use?
- Why We Built This Verification Guide
- Run Your Own Verification Check Right Now
- Frequently Asked Questions
- Sources
What You Need to Verify Stake Wager Outcomes
Before you open any verifier, gather these fields from Stake's bet history and provably fair panel:
- Unhashed server seed: the raw seed, only visible after you rotate to a new seed pair
- Server-seed hash: the commitment shown before and during play
- Client seed: the string you set (or the default one Stake assigned you)
- Nonce: the integer counting which bet this was in the sequence
- Game ID: identifies which title and ruleset produced the round
- Displayed outcome: the result Stake showed you on screen
A common trip-up: pasting the hash instead of the seed. The server-seed hash you see mid-session is a commitment, a locked-in promise of what the seed will be. It's not the value the HMAC function actually uses. You only get the real, unhashed server seed after a seed rotation, so if you're trying to check a bet from an active session, you'll need to rotate first.
How Stake Bet Verification Actually Works
The math behind stake bet verification isn't complicated once you see it laid out. Stake computes HMACSHA256(serverseed, client_seed + nonce), takes the resulting bytes, converts them into a number, then applies a game-specific rule to turn that number into your outcome. That's the entire pipeline: hash, bytes, number, result.
The hashed server seed you see before betting exists specifically to stop cheating. Because the hash is published upfront, Stake can't change the server seed after seeing your bet without the hash no longer matching. When you finally get the raw seed, your verifier re-hashes it and confirms it matches that original commitment. If it doesn't match, something's wrong.
Where this gets interesting is how different games turn that same number into wildly different outcomes:
- Dice: the number is scaled directly into a 0.00 to 100.00 range and compared to your target
- Crash: the value determines the multiplier at which the round busts
- Mines: bytes get mapped into tile positions using a Fisher-Yates style shuffle to place mines without bias
- Plinko: the number determines which path the ball takes down the pegs
- Keno: multiple numbers get drawn from the same byte stream to fill the drawn-number set
Most verifiers, including open-source ones on GitHub, lean on established crypto libraries like digitalbazaar/forge to handle the HMAC computation and byte conversion, rather than writing that logic from scratch.
Pro Tip: If two verifiers give you different results for the same bet, check which byte-to-number conversion each one uses first. Mismatched conversion routines, not fake data, are the number one reason two "correct" tools disagree.
A Step-by-Step Example: Verifying a Dice Bet
Here's how to confirm betting stake fairness on an actual Dice round, using placeholder values you'd swap for your own:
- Copy your inputs. Server seed:
a1b2c3...(revealed post-rotation). Client seed:myseed123. Nonce:47. - Compute the HMAC. Run HMAC_SHA256 with the server seed as the key and
myseed123:47as the message. - Convert bytes to an integer. Take the first few bytes of the resulting hash and convert them into a whole number.
- Scale to the Dice range. Divide and format that number into the 0.00 to 100.00 range Dice uses.
- Compare. Check your computed result against the number Stake displayed for that round.
If your numbers don't line up, check three things first: did you use the hashed seed instead of the raw one, is the nonce off by one, and did you type the client seed exactly, including capitalization.
Pro Tip: Copy-paste every field instead of retyping it. A single mistyped character in a client seed produces a completely different hash, and you'll waste twenty minutes hunting for a bug that was really just a typo.
What Verifiers Can't Do, and Where They Go Wrong
Provably fair tools are precise, but they have real limits. Provably fair verification only applies to Stake Originals; third-party studio games run on entirely different systems and can't be checked the same way.
The most frequent failure modes:
- Using the hashed server seed instead of the revealed raw seed
- Grabbing the wrong nonce for a fast-moving betting session
- Trying to run a Stake Originals check against a slot or live-dealer title
Pro Tip: Run verification tools that compute everything in your browser rather than sending your seeds to someone else's server. Client-side computation means your seed data never leaves your device.
One more limit worth knowing: a verifier can confirm the math matches the commitment. It can't tell you anything about intent beyond that cryptographic reconstruction, and a rotated seed closes that session's window for good.
Which Verifier Should You Actually Use?
You've got three real options, and they serve slightly different needs.
Stake's own calculation page works fine as a sanity check since it lives right where you're already playing, and Stake explicitly points players toward independent verifiers for cross-checking results.
Independent open-source verifiers, like the RGBKey stake-verifier project on GitHub, let you inspect the actual code doing the hashing. Many are built with frameworks like Vue.js, which run entirely in your browser, meaning no seed data ever touches a remote server.
Stakestats' Stake Originals Analyzer is built for players who want speed without opening a code editor. It handles the HMAC computation, byte conversion, and game-specific math client-side, and it's the option we'd point you to first for a quick check on any Stake Original round.
Pro Tip: Bookmark whichever verifier you trust most and re-run it periodically on old bets, not just disputed ones. Spot-checking builds a feel for what normal output looks like, so a real anomaly actually stands out.
Why We Built This Verification Guide
Stakestats exists to give Stake Engine players real transparency, not marketing copy about fairness. We built the Stake Originals Analyzer and our provably fair explainer because too many players trust "provably fair" as a slogan instead of something they can actually check.
Run Your Own Verification Check Right Now
Stakestats gives you a faster route to the same answer you'd get from manually hashing seeds in a code editor: paste your inputs into the Stake Originals Analyzer and get your result in seconds, computed entirely on your device.
Nothing you enter gets sent to an outside server, since the computation runs client-side in your browser the same way the open-source projects do. If you're new to the underlying concepts, the provably fair explanation page walks through hashes, commitments, and seed rotation in plain language before you dive into the numbers. Pull up your last few bets and run them through the analyzer now. Seeing your own hash match your own outcome is the fastest way to trust the system instead of just hoping it works.
Frequently Asked Questions
Can I verify a bet from an active session that hasn't ended? No. The raw server seed stays hidden until you rotate to a new seed pair. You'll only see the hash during active play, which isn't enough to reconstruct the outcome yourself.
Why does my computed result not match what Stake displayed? The most common cause is using the hashed seed instead of the revealed raw seed. Wrong nonce values and mistyped client seeds cause most of the rest.
Does this work for slots or live dealer games? No. Provably fair verification through server seed, client seed, and nonce applies specifically to Stake Original titles. Third-party studio games use different fairness systems entirely.
Is it safe to paste my server seed into a third-party verifier? Prefer tools that compute everything client-side, meaning the calculation happens in your browser and your seed never gets transmitted anywhere. Open-source projects and the Stake Originals Analyzer both work this way.
What's the difference between the server-seed hash and the server seed itself? The hash is a commitment Stake publishes before you bet, proving the seed won't change mid-session. The actual seed used in the HMAC calculation only becomes visible after rotation.