Skip to main content
A Dice roll uses no operator secret at all. It is derived on-chain from a Solana slot hash captured when your bet executes, your account address, and your personal bet counter, then settled in the same transaction that placed the bet. There is no seed the operator could choose, and nothing to reveal afterwards. This page gives the exact mechanism behind every Dice roll. Dice is the simplest case of the provably fair scheme: there is no operator secret at all. The roll is derived from public inputs and settled on-chain in the same transaction that places the bet.

​
Why is there no commit step for Dice?

Crash needs a committed secret because its result must be fixed but hidden while the round plays out. A dice roll has no such phase: the result is consumed in the same instruction that draws it. So instead of committing to a secret, the derivation simply uses no operator input whatsoever: there is nothing to commit, nothing to reveal, and no seed the operator could choose favourably. The entropy comes from the Solana network itself, mixed with values that identify your bet:
  • slothash: the most recent entry of Solana’s SlotHashes sysvar at the moment your bet transaction executes. This is network-produced entropy, not known when the transaction is built (the sender cannot know exactly which slot a transaction will land in).
  • user: the 32-byte address of your on-chain user account (an account the program derives from your wallet). This makes rolls independent across players: two bets landing in the same slot get different rolls.
  • nonce: your personal bet counter, stored on-chain and incremented by every play. This makes your own consecutive bets independent, even within the same slot, and doubles as double-submit protection.

​
What is the exact Dice roll formula?

Details that matter when you recompute it:
  • The hash input is the concatenation, in this exact order: the ASCII tag "dice", the slot hash, the user account address, then the nonce encoded as 8 bytes little-endian.
  • The sample is the first 16 bytes of the SHA-256 output read as a big-endian unsigned 128-bit integer, reduced modulo 10,000.
  • Reducing a 128-bit sample modulo 10,000 has a theoretical bias below 2⁻¹¹⁴, dozens of orders of magnitude smaller than the house edge, which is why it is documented rather than corrected.

​
Win condition and payout

The win chance you select must fall between 2% and 98%. At the current 1.5% edge (edge_bps = 150): The expected return is the same for every target: chance × multiplier ≈ 98.5% of the stake (floor rounding is in the house’s favour by at most one basis point). The current edge and limits are listed in Fees and limits.

​
What is guaranteed, and what is not

Enforced by the program:
  • The roll is derived and settled inside one on-chain instruction, from inputs the program reads itself. The backend does not supply the roll and cannot misreport it.
  • The operator contributes no input to the derivation: there is no server seed to grind for a favourable outcome.
  • Your nonce must be echoed exactly, so the same bet cannot be accidentally (or maliciously) played twice.
  • Every play publishes all derivation inputs and the outcome, so every roll in history can be recomputed by anyone.
The honest caveat: submission timing. Dice bets are gasless: MCC’s backend signs and submits the transaction for you, so the operator controls when it is submitted. The hash of slot N−1 becomes public at the start of slot N, so an operator with very low latency could estimate the roll a bet would get if it landed in the current slot, and delay submission to re-draw. The scheme accepts this rather than pretending otherwise (removing it would require a VRF oracle whose per-bet cost exceeds the house’s expected value on small bets). What bounds it:
  • Inclusion is not fully controllable: the network, not the sender, decides the exact slot a transaction lands in.
  • Every input is published, so submission-delay patterns and any deviation of aggregate win rates from the quoted chances are measurable by anyone from public data. Systematic abuse cannot stay hidden.

​
How do you verify a Dice roll?

Every play emits a DiceBetSettled event in the bet’s own transaction, carrying everything you need: slothash, user, nonce, target_bps, direction, win_chance_bps, roll, multiplier_bps and is_win, plus the full settlement breakdown. To verify:
  1. Open the bet’s transaction on a Solana explorer and read the event fields (the Dice screen in the app shows the fairness inputs of your session, and your bet history links to the transaction).
  2. Recompute sha256("dice" ‖ slothash ‖ user ‖ nonce), take the first 16 bytes big-endian modulo 10,000, and compare with the event’s roll.
  3. Check the win/lose call (roll < target for Under, roll > target for Over) and the multiplier against the formula above.
See Verify a round for general tips on reading event data from an explorer. For how the game itself is played, see the Dice game guide.