SSL Secured·Provably Fair·Rankings powered by real deposit volume data·Updated Jul 2026·18+ Gamble Responsibly
Hi-Lo Verification · 8 Min Read · Jun 2026

HOW TO VERIFY PROVABLY FAIR HI-LO

AM
Alex Mercer · ProvenlyFair.com Editorial Team
Updated Jul 20268 min read
In Hi-Lo you guess whether the next card is higher or lower than the one shown. A provably fair Hi-Lo game lets you prove that the card you were dealt was locked in before you placed your bet — not swapped afterwards to beat you. What follows is the byte-level recipe by which an HMAC-SHA256 digest becomes one specific card out of 52, a hand-computed example ending in the King of Diamonds that you can replicate independently, and the seed-collection steps that make our in-browser verifier usable on your own bet history.

Re-Deal Any Hand Yourself

Take the three values off your casino's fairness screen — revealed server seed, your client seed, the bet's nonce — and the tool re-deals the identical cards on your own machine. No account, no data leaves the page.

Re-Deal My Cards

The Inputs That Decide Which Card You See

Think of a Hi-Lo bet as a deterministic function of three arguments. Argument one, the server seed, is chosen by the house but pinned down publicly ahead of time through its SHA-256 fingerprint — a promise the house cannot rewrite. Argument two, the client seed, belongs to you and injects a value the house never picked. Argument three, the nonce, ticks upward per bet so identical seeds never repeat a deal.

In card terms the guarantee reads: whatever you were dealt was already implied by those three arguments before you chose higher or lower — there is no mechanism for the game to slide in a losing card after seeing your pick. Once the pair retires and the plain server seed is published, any hand on it can be re-dealt on your own hardware. (Cross-game fundamentals — commitments, rotation, why reveal comes last — live in the general verification guide.)

How the Hash Becomes a Card: The Real Algorithm

Hi-Lo on Stake — the operator that popularised this method and publishes the algorithm openly — derives each card directly from the bytes of an HMAC-SHA256 hash. The same logic is implemented in the widely used open-source reference verifier lucasholder/fair, which is explicitly built to match Stake's output. Here is the full chain, step by step:

  • 1
    Build the HMAC. The server seed is the HMAC key; the message is the string clientSeed:nonce:cursor. Computing HMAC_SHA256(serverSeed, "clientSeed:nonce:cursor") produces a 32-byte hash (64 hex characters). The cursor starts at 0.
  • 2
    Take 4 bytes, make a float. Each card uses 4 bytes. Those bytes are turned into a decimal between 0 and 1 with the formula byte₀/256¹ + byte₁/256² + byte₂/256³ + byte₃/256⁴. A 32-byte hash therefore yields 8 cards; if more are needed the cursor increments to 1, 2, … for a fresh hash.
  • 3
    Scale the float to a card index. Multiply the float by 52 and round down: index = floor(float × 52). This gives a whole number from 0 to 51 — one slot for every card in a standard deck.
  • 4
    Map the index to a rank and suit. On Stake's ordering, the rank is index ÷ 4 (integer division) and the suit is index % 4. Ranks run 2, 3, 4, 5, 6, 7, 8, 9, 10, J, Q, K, A (Ace high) and suits run Diamonds, Hearts, Spades, Clubs. So index 0 = 2♦, index 1 = 2♥, index 2 = 2♠, index 3 = 2♣, index 4 = 3♦, and so on up to index 51 = A♣.

One important detail unique to Hi-Lo: each card is drawn independently from a full 52-card deck, as if from an infinite shoe. Stake assigns a cursor of 13 to Hi-Lo so it can generate up to 52 cards per bet when needed, but every individual draw is still a fresh 1-in-52 pick — which is why the same card can legitimately appear twice in a row (a tie).

Bytes-to-Cards, Automated

If float expansions and modular suit maps are not your idea of fun, the verifier executes every stage of the derivation above and simply shows you the cards, computed client-side from whatever seeds and nonce you supply.

Derive the Cards For Me

Dealing a Card From a Hash, By Hand

Time to make it concrete. The inputs below are arbitrary but the outputs are exact — any standard HMAC-SHA256 implementation fed the same key and message will emit this digest, and the digest can only ever become one card.

InputValue
Server seedserverSeed123
Client seedclientSeed456
Nonce3
Cursor0
  • 1
    Compute the HMAC. HMAC_SHA256("serverSeed123", "clientSeed456:3:0") =
    daeed0d0ff5ea59c83572c351983da4718595f610eb00c416f068d282f1faecf
  • 2
    Read the first 4 bytes. The leading hex pairs are da ee d0 d0, i.e. the decimal bytes 218, 238, 208, 208.
  • 2
    Convert to a float. 218÷256 + 238÷256² + 208÷256³ + 208÷256⁴ = 0.85520654.
  • 3
    Scale to a card index. floor(0.85520654 × 52) = floor(44.47) = 44.
  • 4
    Map to a card. Rank = 44 ÷ 4 = 11 → the 12th rank in the list (0-indexed) = King. Suit = 44 % 4 = 0 → Diamonds. The dealt card is the King of Diamonds.

Result: these seeds at nonce 3 deal the King of Diamonds — every single time, on any machine. If the casino had shown you a different card for these exact inputs, the verification would fail and you would know the result had been altered. That reproducibility is the entire point.

Gathering Seeds From the Fairness Screens

Everything above assumed you hold the plain server seed — and casinos disclose that value only when a seed pair is retired through rotation. Per operator:

CasinoHow to Find Your Seeds
StakeThe Fairness tab inside account settings holds the active hash and client seed; triggering a seed change discloses the outgoing server seed, and each bet's popup lists the nonce it consumed.
BC.GameIts Provably Fair page (via your avatar) tracks both the live pair and retired ones — retired entries show the seed unhashed; nonces sit in the bet log.
Roobet & othersLocate the bet in your history and expand its fairness details; the plain seed appears there once you have cycled the pair from the account's fairness menu.

What a Matching Card Does — and Doesn't — Tell You

When your re-deal agrees with the game, two conclusions follow and two temptations should be resisted:

  • ✓Conclusion: the deal predated your decision. The card was a fixed consequence of committed inputs — picking "higher" did not summon a lower card.
  • ✓Conclusion: the commitment held. The revealed seed reproduces both the pre-published fingerprint and the exact cards from your history — the two checks that together constitute proof.
  • ✗Temptation: reading fairness as value. Hi-Lo pays a shade under the true probability of each guess; that gap is the house's margin and it survives every successful verification intact.
  • ✗Temptation: extending trust beyond the deal. Honest cards say nothing about cashier behaviour, account handling or licensing — vet operators separately via our ranked provably fair casinos.

Key Takeaways

Provably fair Hi-Lo derives each card from HMAC-SHA256(serverSeed, clientSeed:nonce:cursor): the first 4 bytes become a float, the float scales to an index via floor(float × 52), and the index maps to a rank and suit. Our worked example (serverSeed123 / clientSeed456 / nonce 3) deals the King of Diamonds, reproducibly. Check your own hands with our Provably Fair Verifier in seconds.

Frequently Asked Questions

Each card is decided by HMAC-SHA256(serverSeed, clientSeed:nonce:cursor). The first four bytes of that hash are turned into a decimal between 0 and 1, then multiplied by 52 and rounded down to give a card index from 0 to 51. On Stake's deck order the index maps to a rank (2 through Ace) and a suit (Diamonds, Hearts, Spades, Clubs), so the same seeds always produce the same card. You can confirm this with our verifier tool.
It proves the card you were dealt was fixed by the server seed before you placed the bet, and was not swapped after you chose higher or lower. Because the server seed's hash was published in advance, the casino cannot retroactively change which card appears. It does not remove the house edge built into the payout odds, and it cannot force a casino to honour a withdrawal.
One HMAC-SHA256 hash is 32 bytes and each card consumes 4 bytes, so a single hash yields 8 cards. When a round needs more than 8 cards the cursor increments from 0 to 1, 2 and so on, generating a fresh 32-byte hash each time. The nonce identifies the bet; the cursor walks through extra bytes within that same bet.
Yes. Stake's Hi-Lo draws each card independently from a full 52-card deck, as if from an infinite shoe, so every draw has a 1-in-52 chance of any specific card regardless of what came before. That is why you can occasionally see the same card appear consecutively, which counts as a tie under the game rules.
Stake popularised this exact HMAC-SHA256 card-derivation method and publishes the algorithm openly, and several other crypto casinos use the same or a near-identical scheme. Our free Provably Fair Verifier reproduces the card derivation in your browser so you can check any Hi-Lo bet without trusting the casino's own checker.
AM
Alex Mercer
Alex covers crypto casinos and provably fair gaming for the ProvenlyFair.com Editorial Team. Specialising in cryptographic verification systems and transparency in online gambling.
Free Tool — Verify Any Hi-Lo Hand
Verify Now