WOYALE. Verify a bet
Fair play

How one HMAC result becomes a dice roll, a multiplier or a shuffled deck

A receiver reaches for the ball under stadium lights
Short answer

Most provably fair games turn one HMAC-SHA256 output into decimals between 0 and 1, then apply a game rule: scale for dice, compare to a threshold for a coin flip, or divide for a multiplier. The rule differs by operator, so the site's own fairness page is the authority.

Common startHMAC-SHA256 bytes to a 0-1 float
Floats per HMAC8 (at 4 bytes each)
AuthorityThe site's own fairness page

Updated October 23, 2026 · 5 min read

Every provably fair game starts the same way and ends differently. The start is a keyed hash of your seeds. The end is a rule that turns the hash into a roll, a multiplier, a card or a spin. This page covers the shared first half and shows examples of the second, so you can read any site’s fairness page.

There is no standard. Each operator picks its own message format, byte order, scaling and house-edge factor. The mappings below are illustrative: they show how such rules are built, using the same demo seeds as how to verify a bet. They are not any site’s documented formula. To check a real bet, use the formula on that site’s own fairness page. Where this page and the site disagree, the site wins.

Step one: bytes to a float

HMAC-SHA256 returns 32 bytes. Games usually want a decimal between 0 (included) and 1 (excluded), because a decimal can be scaled to any range. The common method reads bytes in groups of four:

f = b0/256 + b1/256² + b2/256³ + b3/256⁴

Four bytes give one float. Two details matter:

  • Four bytes give about 4.3 billion possible values. That is plenty for a roll to two decimal places, and thin for a deck of cards.
  • Each byte is equally likely to be any value from 0 to 255, so f is spread evenly across 0 to 1. Every mapping below depends on that.

The Woyale dice verifier uses this method with the message client:nonce:0. It also shows the raw HMAC hex and the float, so you can apply a different rule yourself.

Step two: more bytes through a cursor

One HMAC holds 32 bytes, which is enough for eight floats. A coin flip needs one. A shuffled deck needs many. Games that need more values add a counter to the message, often called a cursor or round: client:nonce:0 gives the first 32 bytes, client:nonce:1 the next 32, and so on. The seeds and nonce stay fixed; only the last number changes.

For the demo seeds with nonce 1, the first HMAC begins 40e6f393 3984464b .... Its eight floats, to four places, are:

FloatBytes usedValue
f11 to 40.2535
f25 to 80.2247
f39 to 120.0024
f413 to 160.0977
f517 to 200.0142
f621 to 240.3915
f725 to 280.6199
f829 to 320.3006

Asking for a ninth float means computing a second HMAC with cursor 1. A site that skips this step, or reuses bytes, is doing something its fairness page should explain.

Step three: the game rule

Here is how f1 = 0.2535 becomes a result under typical rules.

GameRule (illustrative)Result for f1 = 0.2535
Dicefloor(f × 10001) ÷ 10025.35
Coin flipf below 0.5 is heads, otherwise tailsHeads
Roulette-style wheelfloor(f × 37), for slots 0 to 36Slot 9
Limbo or crash-style multiplier0.99 ÷ (1 − f), rounded down to two decimals1.32x

Dice

Scaling by 10,001 gives 10,001 outcomes, 0.00 to 100.00 in steps of 0.01. This is the rule the Woyale verifier uses.

Coin flip and wheels

These are the simplest: cut the 0 to 1 range into equal slices. A fair coin has two slices of 0.5. A 37-slot wheel has 37 slices of about 0.027 each, and f1 lands in the tenth slice, which is slot 9 counting from 0.

Multipliers

A limbo-style game lets you pick a target multiplier, and you win if the result reaches it. The mapping 0.99 ÷ (1 − f) makes the chance of reaching a target m equal to 0.99 ÷ m. A 2x target wins 49.5% of the time, and a 10x target wins 9.9%. The 0.99 is the house edge written into the formula, here 1%. Some sites use a different factor, and a 4% edge uses 0.96. A matching result proves the site followed its own rule. It says nothing about how generous that rule is.

Crash games follow the same logic with one twist: the multiplier is the point where the round ends, and every player in a round often shares one result.

Card shuffles

A shuffle needs one float per card, so the method uses the cursor. A common design is the Fisher-Yates shuffle: for each draw, scale a float to the number of cards left, take that card out, and repeat. With the demo floats and a 52-card deck numbered 1 to 52, drawing five cards gives 14, 12, 1, 6 and 2. The first draw is floor(0.2535 × 52) + 1 = 14. The second is floor(0.2247 × 51) + 1 = 12 from the remaining deck.

A shuffle goes wrong easily: if a site scales in a different order, numbers cards from 0, or draws from the other end of the deck, every card changes. This is why shuffles are the hardest games to verify by hand.

What to check on a site’s own page

Before you recompute anything, find these on the fairness page:

  1. The exact message format and separators, and whether the nonce starts at 0 or 1.
  2. How bytes become a float, and how many bytes per float.
  3. How the cursor works when a game needs more than eight floats.
  4. The mapping for the specific game, including any house-edge factor.
  5. Whether the page offers open code or a test vector you can match.

A site that publishes a test vector (inputs and the expected output) makes this easy. Reproduce its vector first. If you match it, your tool is reading the method correctly, and a mismatch on a real bet becomes meaningful.

Common questions

Why does my result not match the Woyale verifier for another site’s game?

The verifier does dice with one specific method. Other games and other sites use different messages, scaling or edge factors. Use the verifier’s raw HMAC and float output with the formula from the site’s fairness page, and read how to verify a bet for what to check first.

Does a different formula mean a site is cheating?

No. Different formulas are normal. What matters is that the formula is published before you play, that the seed commitment checks out, and that the result follows from the documented rule. See what provably fair doesn’t prove.

Can the house edge hide in the formula?

Yes, and it usually does, in plain sight. The edge is a constant such as 0.99 or a payout table. Provably fair confirms the rule was applied. It does not confirm the rule is generous. Offshore sites are unlicensed in the US, so no state regulator audits them: see are offshore sportsbooks legal.

Sources

  1. IETF RFC 2104: HMAC, Keyed-Hashing for Message Authentication
  2. NIST FIPS 180-4: Secure Hash Standard (SHA-256)

Checked October 23, 2026. Laws, fees and tax rules change; confirm anything you act on with the source. Information, not legal or tax advice.