Stake's Provably Fair Engine: A Full Technical Breakdown

There's an uncomfortable reality at the heart of online gambling: you're sending money to a server you can't see, run by a company you've never met, to spin an RNG whose code you'll never read. You win or lose based entirely on outputs you have no way to audit. For most of the industry's history, "trust us" has been the only answer on offer, dressed up in licensing badges and third-party audit stamps that most players never actually look into.

Stake's Provably Fair system is built on the opposite premise. Instead of asking for your trust, it gives you the tools to make trust irrelevant. Every bet you place generates a cryptographic paper trail that you, or anyone, can follow from input to output and confirm that nothing was manipulated along the way. No black boxes. Just math. Here's how it works.

The Foundation: Locking in Outcomes Before They Happen

The whole system hinges on two concepts that work together: a commitment scheme and cryptographic hashing.

A commitment scheme is exactly what it sounds like, a way of locking in a value before it's used, so neither party can change it once the game is in motion. Cryptographic hashing takes a piece of data and converts it into a fixed-length fingerprint. It's a one-way process: you can verify that a fingerprint matches a given input, but you cannot work backwards from the fingerprint to reconstruct the original. That property is what makes it useful here.

Put them together and you get a system where Stake commits to its contribution before a single bet is placed, locked, hashed, handed to the player as proof, and the player contributes their own input on top. Neither side can rig the output without the other detecting it. 

The formula is blunt about it:

fair result = operator's input (hashed) + player's input

No hidden variables. No post-hoc adjustments. If the result doesn't match the inputs, the audit will show it.

Four Inputs, One Result

Every bet on Stake's provably fair games is generated from 4 distinct values: the server seed, the client seed, the nonce, and the cursor. Each one has a specific job, and removing any one of them would create an exploitable gap in the system.

Server Seed — The Casino's End of the Deal

Before your session begins, Stake generates a random 64-character hexadecimal string, the server seed. You never see the actual value while you're betting. What you get instead is its SHA-256 hash: a fingerprint that proves the seed exists and is already fixed, without revealing anything about what it is.

This is deliberate and important. If you saw the raw seed, you could theoretically calculate upcoming results. If Stake didn't show you the hash upfront, they could swap the seed after a losing bet and you'd have no way to catch it. The hash threads this needle, it's verifiable proof of commitment without being actionable information.

When you're ready to close a session and audit it, you rotate your server seed. That action reveals the original unhashed value. You then run it through SHA-256 yourself (or use Stake's built-in tool) and confirm it matches the hash you were given at the start. If it does, every result from that session was generated from a seed that was never changed. A new seed is generated for the next session, and the whole process resets.

Client Seed — Your Influence on the Outcome

The client seed is yours. It's the part of the formula that ensures Stake cannot unilaterally control what happens, your input is woven into every result, making it impossible for the casino to predetermine outcomes without your cooperation.

When you first register, your browser generates a client seed automatically so you don't have to think about it out of the gate. But you can, and should, replace it with something of your own choosing via the fairness modal. Think of it like cutting the deck before a hand of cards: a small action that meaningfully changes everything that follows, and that proves the deck wasn't stacked against you specifically.

You can change your client seed whenever you like. Each new seed starts a fresh chain of outcomes from that point forward.

Nonce — A Unique Result for Every Single Bet

The nonce is a simple counter that ticks up by one with every bet. Its power comes from a property of SHA-256: changing even a single character of the input produces a completely different output, with no predictable relationship between the two. Because the nonce increments each bet, each hash operation produces an entirely new result, no repetition, no patterns, all without touching the seeds.

This is what lets Stake honour its commitment to a fixed seed pair for an entire session while still generating something new and unpredictable every time you play.

Cursor — Scaling Up for Complex Games

SHA-256 outputs 32 bytes per operation. Stake uses 4 bytes to generate each individual game event, which means a single hash call covers up to 8 events. For a coin flip or a dice roll, that's overkill. For a game of Blackjack that might need 20+ cards, or Video Poker that requires a full shuffled 52-card deck, it's not nearly enough.

The cursor handles this by tracking how many 32-byte blocks have been consumed. When the current block runs out, the cursor increments, a new hash operation runs using an updated round number, and the flow continues, same seeds, same nonce, just an extended result chain.

Most simple games, Dice, Limbo, Roulette, Wheel, Baccarat, run on a single cursor value of 0. Games with more complex event requirements use multiple increments:

The Engine: HMAC_SHA256 and the Byte Generator

The actual number crunching is done by a function built around HMAC_SHA256, a keyed variant of SHA-256 that's been a cornerstone of cryptographic security for decades. It's used to sign API requests, verify software integrity, and authenticate secure communications. Its presence here isn't decorative; it was chosen because it's deterministic (identical inputs always produce identical outputs), unpredictable from the outside, and computationally infeasible to reverse.

The byte generator feeds the server seed in as the cryptographic key, and uses the client seed, nonce, and current cursor round as the message. Out comes a 32-byte buffer that looks like noise, but is entirely reproducible if you know the inputs. The function walks through this buffer byte by byte, yielding values until the game has what it needs.

Those bytes are then grouped into sets of four by the generateFloats function, which converts each group into a decimal number between 0 and 1. The reason for four bytes instead of one: a single byte produces only 256 possible values, while four bytes together yield over four billion. That precision matters when you're generating outcomes across games with highly varied probability structures.

The resulting floats, one or more, depending on the game, are what every game on the platform uses to determine what actually happens.

READ MORE:

• Find Out How The Stake Engine Works
• KYC In Online Casinos: A Complete Guide
• What Is Stake's WinSAFE Bet Insurance?

Turning Numbers Into Game Events

A float between 0 and 1 doesn't mean anything by itself. The last step is translating it into something game-specific: a card rank, a mine position, a roulette pocket, a plinko path.

The core method is simple: multiply the float by the number of possible outcomes, take the floor of the result, and use that integer to look up the corresponding event in a predefined index. For a 52-card deck: Math.floor(float * 52) returns a number from 0 to 51, each mapping to a specific card.

For games where outcomes can't repeat, card games using a single deck, mine placement on a board, keno hits on a grid, Stake uses the Fisher-Yates shuffle algorithm to enforce uniqueness. Each time an event is generated, that outcome is removed from the pool. The next float is multiplied by one fewer possible value, and so on. It's the same logic as dealing from a physical deck: once a card is on the table, it can't come up again until the deck is reshuffled.

How Each Game Uses the System

Every game on Stake draws from the same cryptographic source, but the rules for turning floats into outcomes vary depending on what's being played. Here's how the system plays out across different game types.

Card Games: Blackjack, Baccarat, Hilo & Video Poker

All four types of games use a 52-card index running from the 2 of Diamonds to the Ace of Clubs. Blackjack, Hilo, and Baccarat treat each draw as coming from an unlimited supply of decks, every card always has a 1-in-52 probability, regardless of what's already been dealt. Video Poker works differently: it uses a single finite deck, and the Fisher-Yates shuffle ensures no card appears twice. The first draw multiplies by 52; the second by 51; and so on until the hand is complete.

Grid and Board Games: Mines, Keno, Moles & Dragon Tower

These are where the multi-event generation earns its keep. Mines generates 24 separate floats to place every mine across the board, with Fisher-Yates guaranteeing no two mines share a tile. Keno selects 10 hit positions from a 40-square grid using the same non-repeat logic. Moles shuffles positions across 7 holes for each round, generating fresh placements every time. Dragon Tower produces 9 level events, the number of eggs and the tile layout per level shift depending on the difficulty setting chosen.

Crash-Style Games: Limbo, Drill, Pump & Chicken

These games skip index lookups entirely and use mathematical formulas instead. Limbo divides a maximum multiplier by the float, adjusted for house edge, to create a crash point. The distribution is intentional: low multipliers are common, high ones become exponentially rarer as you climb. Drill applies a similar inverse formula independently across three separate events. Pump and Chicken both generate sequences of up to 24 events to determine when the pop or death occurs, with Fisher-Yates preventing any round from repeating.

Number and Wheel Games: Dice, Roulette, Plinko & Wheel

Dice stretches across 10,001 possible outcomes to produce rolls between 00.00 and 100.00. Roulette uses the European wheel, 37 pockets, 0 through 36, with the float multiplied accordingly. Plinko resolves one float per level of descent, with each float deciding left or right, building the ball's complete path from the top row down to the payout slot. The Wheel game selects a multiplier from a payout index determined by the chosen segment count (10 through 50) and risk level.

Specialty Games: Tarot, Packs, Darts, Flip & Others

Tarot draws three separate arcana cards using three floats, with the Minor and Major Arcana each operating on their own probability mapping. Packs opens five cards from a pool of 240 unique items, each float independently selects from the full table, meaning duplicates within a single pack are possible. Darts uses one float for board rotation and another for distance from center, with distance normalized via a square root formula that concentrates results naturally toward the middle. Flip runs 20 coin flips in sequence, each resolved simply by whether its float falls above or below 0.5.

Verifying a Bet Yourself

Stake's fairness modal is the starting point for any verification. The workflow is straightforward:

1. Before betting — record the hashed server seed shown to you. This is your anchor point.
2. Set your client seed — use the auto-generated one or enter your own. Either way, note it.
3. Place bets — the nonce tracks how many you've placed on this seed pair.
4. Rotate your server seed — this closes the session and reveals the original unhashed seed.
5. Hash the revealed seed yourself — if it matches what you were given at step one, the seed was never touched.

From there, any individual bet can be fully reconstructed: take the server seed, client seed, and the nonce value for that specific bet, run them through the same HMAC_SHA256 function, and you'll reproduce the exact float sequence, which will translate into the exact same game result. A mismatch anywhere in that chain is proof of tampering.

This is also why high-profile wins on Stake Originals aren't just claims. When Roshtein hit $25 million on Hex Appeal, the bet slip came with it — server seed, client seed, nonce and all. Anyone can run it through the same function and land on the same outcome. The win is verifiable, not just watchable.

For anyone who'd rather verify through a completely independent source, all Stake Originals can be audited via third-party tools like provablyfair.me, which has open-sourced its own implementation of the verification process. Running your bet data through an external tool that arrives at the same result as Stake's own system is about as airtight a confirmation as you can get.

The Crypto Gambling Foundation

Stake holds verified operator status on the Crypto Gambling Foundation network, an independent body that defines and enforces standards for provably fair gambling across the industry. Getting on that list requires more than self-certification; it means Stake's implementation has been assessed against established cryptographic and transparency criteria by an external party.

For players, it's a meaningful extra layer. It means the system described in this article has been reviewed by people with no stake in how it turns out.

The Point of All of It

Provably fair gambling works because it removes the need to take anyone's word for anything. Stake's implementation, built on HMAC_SHA256, four-input seed generation, and game-specific float translation, creates a complete, auditable chain from the moment a bet is placed to the moment a result appears.

The server seed hash is locked in before you wager a cent. Your client seed gives you direct influence over the outcome. The nonce ensures every bet is unique. And the entire chain, for any bet you've ever placed, can be reconstructed and verified by you, independently, at any time.

There's also something worth appreciating about the architecture itself: no single component does all the work. The server seed alone could be manipulated by the casino. The client seed alone could be gamed by the player. The nonce alone would produce predictable sequences. But the four of them together, each one constraining what the others can do, create a system where cheating would require breaking both parties' commitments simultaneously while also defeating SHA-256. That's not a theoretical safeguard. It's a practical one.

In an industry that has spent decades asking players to simply believe the numbers, the ability to verify them yourself isn't just a feature. It's a fundamentally different relationship between a casino and the people playing at it.