Dicey
Cryptographic result checking
Dicey Provably Fair Games
Dicey Originals use a server seed, client seed, nonce, and HMAC-SHA256 so completed results can be recalculated after the server seed is revealed. The method provides a reproducible check on the round calculation. It does not predict future outcomes, remove variance, or change the published RTP of the game.
Provably fair makes the result calculation reproducible
Dicey applies its provably fair process to the ten listed Originals: Coinflip, Dice, Mines, Plinko, Blackjack, Limbo, Keno, Dig Dig, Throne Towers, and Space Draw. The core inputs are a server seed, a client seed, and a nonce. HMAC-SHA256 combines those values under the stated method to create deterministic cryptographic data that the game converts into its settled outcome.
The pre-play commitment
Dicey shows a hash of the server seed before that seed is revealed. Because changing the underlying seed would change its hash, the commitment gives the player a reference that can later be compared with the disclosed server seed.
The round inputs
The client seed and nonce help distinguish the data used for a particular result. Combined with the server seed, they form the inputs needed to reproduce the HMAC-SHA256 calculation for that round.
The revealed server seed
When the server seed is rotated, the old value becomes available for checking. The player can hash that revealed seed, compare it with the earlier commitment, and then use it to reproduce completed rounds from the session.
Provably fair therefore addresses one narrow question: whether a completed result follows the stated cryptographic process. The Dicey Originals guide covers game mechanics and published RTP separately, because fairness checking does not make the ten games mathematically identical.
HMAC-SHA256 turns the session inputs into a repeatable value
HMAC stands for hash-based message authentication code, and SHA-256 is the hash function used in the construction. Dicey describes the round calculation as HMAC-SHA256 with the server seed as the key and the client seed plus nonce as the message input. Once the server seed is revealed, the same values can be supplied again to reproduce the same cryptographic output.
Server seed
A secret session value committed through its hash before disclosure and revealed after the seed is rotated.
Client seed
A player-side input that forms part of the message used for the round calculation.
Nonce
A changing round counter that helps separate one result from the next under the same seed pair.
HMAC-SHA256 output
A deterministic cryptographic value that can be reproduced when the same server seed, client seed, nonce, and method are used.
The HMAC output is only part of the result path. Each game also needs a rule for turning cryptographic data into a card, number, grid, multiplier, path, or other outcome. That mapping belongs to the game’s own calculation.
The method is retrospective rather than predictive. The unrevealed server seed prevents the player from knowing the next HMAC result in advance, while later disclosure gives the information needed to reproduce results from the completed seed period.
A result check follows the round from seed commitment to recalculation
The practical sequence starts with the seed commitment shown during play and ends after the relevant server seed is revealed. A completed check uses the exact inputs for the round rather than a general label or a screenshot of the final result alone.
- Identify the completed round. Start with the exact Original and outcome you want to reproduce.
- Record the client seed and nonce. These values identify the message input associated with that result under the current seed period.
- Use the revealed server seed. After rotation, hash the disclosed seed and compare it with the server-seed hash that was committed beforehand.
- Recalculate HMAC-SHA256. Use the server seed with the client seed and nonce under Dicey’s stated formula to recreate the cryptographic value.
- Apply the game’s result mapping. Translate the reproduced data according to the Original’s rules and compare the resulting outcome with the settled round.
| Element | Role | What it tells you |
|---|---|---|
| Server-seed hash | Commits to the hidden server seed before disclosure | Lets the later revealed seed be compared with the earlier commitment |
| Client seed | Provides player-side input to the round calculation | Forms part of the data used to reproduce a specific result |
| Nonce | Changes between rounds under the same seed period | Separates one round calculation from another |
| HMAC-SHA256 | Produces deterministic cryptographic data from the stated inputs | Can be recalculated once the server seed is available |
| Game mapping | Turns cryptographic data into the game outcome | Connects the reproduced value with the result shown by the Original |
Payment-chain activity is a separate system. The Dicey payments guide covers BTC, ETH, SOL, USDC, ME, and USDT on their supported networks. Those blockchain transfers concern moving funds; the Dicey Originals fairness calculation uses session seeds, a nonce, and HMAC-SHA256.
The proof addresses result integrity, not gambling value
A reproducible result path can answer whether a completed round follows the stated calculation. It does not answer whether the game is financially favorable. Dicey publishes RTP separately: most Originals are stated at 99%, Blackjack at 99.43%, and Dig Dig at 97%, with separate lower figures for Blackjack side bets.
What the seed-based check can show
- The revealed server seed corresponds to the commitment shown before it was disclosed.
- The same server seed, client seed, nonce, and formula reproduce the same HMAC-SHA256 value.
- The reproduced data can be followed through the game’s mapping to the completed outcome.
What the check does not establish
- It does not predict the next round.
- It does not remove house edge or variance.
- It does not determine whether a stake is affordable.
- It does not protect a crypto bankroll from market-price movement.
A reproducible loss is still a loss. Cryptographic transparency can clarify how the outcome was produced, but it does not alter the casino mathematics or make cryptocurrency transfers reversible.
This distinction matters most when rounds are fast. A technical checking feature can create a sense of control over the calculation, while financial exposure still depends on the wager size, the game’s published math, session length, and the number of repeated rounds.
Use result checking selectively and keep bankroll controls separate
A player does not need to reproduce every round to understand the feature. The important parts are knowing where the seed information appears, understanding when the server seed becomes available, and being able to follow one completed example through the HMAC-SHA256 and game-mapping steps.
- Locate the server-seed hash, client seed, and nonce before relying on the provably fair feature.
- After the server seed is rotated, compare the revealed value with the commitment from the completed seed period.
- Recalculate a sample round when you want to understand how the HMAC output maps to that game’s outcome.
- Keep RTP, house edge, and volatility separate from the cryptographic check; they describe the game’s long-run and short-run risk rather than the integrity of one calculation.
- Set spending and session limits before play rather than changing them in response to a streak.
The Dicey games overview separates provider games, live-dealer content, and the ten in-house Originals. The Dicey review adds account access, token networks, withdrawals, and other product details that remain independent of the provably fair calculation.
Questions about Dicey provably fair games
What inputs does Dicey use for provably fair Originals?
The method uses a server seed, a client seed, a nonce, and HMAC-SHA256. The server seed is committed through a hash and becomes available after rotation.
What does HMAC-SHA256 do in a Dicey round?
It deterministically combines the server seed with the client-seed and nonce input so the same values can reproduce the same cryptographic output later.
Can provably fair data predict the next Dicey result?
No. The hidden server seed prevents the feature from acting as a preview of future outcomes. The disclosed data is used to reproduce completed results.
Does provably fair mean there is no house edge?
No. Result integrity and game math are separate. Dicey publishes RTP figures for the Originals, and those figures still imply a house advantage over the long run.
Which Dicey games use the in-house fairness system?
The listed Originals are Coinflip, Dice, Mines, Plinko, Blackjack, Limbo, Keno, Dig Dig, Throne Towers, and Space Draw.
Read next
Dicey’s provably fair layer makes completed Original rounds reproducible
The flow is based on a server-seed commitment, a client seed, a nonce, and HMAC-SHA256. Once the server seed is rotated and revealed, a player can compare it with the earlier hash, reproduce the HMAC value for a round, and follow the game’s mapping from that value to the settled outcome.
That technical check has a defined boundary. It cannot forecast the next result, remove house edge, reduce variance, or protect the value of a cryptocurrency bankroll. Dicey’s published RTP figures and each game’s rules describe the gambling mathematics; the seed-based process describes how a completed result can be recalculated.
Written by the editors at Dicey.
