Mines fairness

​

What is committed, and when

1. Commits the operator’s contribution. The backend generates a random 32-byte server_seed and the transaction stores its SHA-256 hash, the commitment. The seed itself stays hidden until the game ends.
2. Captures chain entropy. The program reads the most recent slot hash from Solana’s SlotHashes sysvar and stores it in the game.
3. Freezes the terms. The house edge, the payout cap and the refund timeout are snapshotted into your game; nothing can reprice a board you are already playing.

​

How is the Mines board derived?

inputs
  server_seed  32 bytes   operator seed, committed as sha256(server_seed) at game start
  slothash     32 bytes   latest Solana slot hash when the start transaction executes
  user         32 bytes   the address of your on-chain user account
  nonce        8 bytes    your mines game counter, little-endian
  mines_count  1..24      the number of mines you chose

random stream: SHA-256 blocks consumed 4 bytes at a time
  block(k)   = sha256( server_seed ‖ slothash ‖ user ‖ nonce ‖ "mines" ‖ k )
               // "mines" = 5 ASCII bytes; k = block counter 0, 1, 2, … as 8 bytes little-endian
  next_u32() = next unread 4 bytes of the current block, big-endian;
               when a block is exhausted, move to block(k+1)

unbiased draw in 0..bound (rejection sampling, no modulo bias)
  draw(bound):
    zone = 4294967295 − (4294967295 mod bound)
    repeat v = next_u32() until v < zone
    return v mod bound

board: partial Fisher–Yates shuffle
  tiles = [0, 1, …, 24]
  mine_mask = 0
  for i in 0..mines_count:
      j = i + draw(25 − i)
      swap tiles[i] and tiles[j]
      mine_mask = mine_mask OR (1 << tiles[i])

• The hash input order is exactly: seed, slot hash, user account address, nonce (8 bytes little-endian), the ASCII tag "mines", then the block counter (8 bytes little-endian, starting at 0).
• Each 4-byte chunk is read big-endian. A block yields 8 draws at most; the stream refills with the next counter value as needed.
• The rejection-sampling loop makes every draw exactly uniform: the shuffle has no bias to argue about.

​

What payout formula does the program enforce?

                                 k−1
multiplier = (1 − edge) × product ( (25 − i) / (25 − M − i) )
                                 i=0

M = number of mines, k = number of safe tiles revealed

​

What the program enforces at settlement

• sha256(server_seed) must equal the commitment stored at game start; a different seed cannot settle the game.
• The board is re-derived from scratch with the formula above. Any revealed tile that is actually a mine is rejected; a claimed bust tile that is not a mine is rejected; a bust tile that was also claimed as revealed is rejected.
• The multiplier is computed on-chain from the snapshotted edge and your actual reveal count, so the payout cannot be misreported.
• The settlement event publishes the seed, the slot hash, the full mine mask, your revealed tiles and the outcome, permanently.

​

What is guaranteed, and what is not

• The board is fixed before your first pick, by the commitment plus the stored slot hash. Mines cannot move mid-game.
• At settlement, the operator cannot lie about the board: wrong seed, a mine claimed safe, or a fake bust all make the transaction fail.
• The terms you started with (edge, payout cap, timeout) apply to the end of the game.
• Your stake can never be locked: if the operator never settles, the cancel becomes callable by anyone after the game’s timeout, refunding your stake. In normal operation you never get there: an abandoned board is cashed out at its current multiplier before the timeout (see Mines), so you keep your winnings rather than just your stake. The permissionless cancel is the guarantee underneath, for the case where the operator is gone.

• The operator knows the board while you play. This is structural, not a flaw of this particular design: reveals are served instantly off-chain, and whoever serves them must know where the mines are. No randomness scheme removes this: even a VRF-generated board would be known to the operator the moment it serves your first reveal. What the commitment guarantees is that this knowledge cannot be used to change the board or to misreport the outcome.
• Start timing. The board depends on the slot hash captured when your game starts, and the start transaction is submitted by the backend, the same timing consideration as the other games. Knowing a board in advance only helps if your picks are predictable; varying where you click defeats timing-based board selection.
• Voids. The operator can cancel a game in progress (including, in principle, one you are winning). A cancel refunds the full stake (there is no confiscation path) and always emits a public event, so the void frequency is auditable on-chain by anyone.
• Each game must use a fresh seed: a revealed seed is public, and reusing it would make the next board publicly derivable. The program rejects back-to-back reuse on-chain, and the backend enforces global uniqueness.

​

How do you verify a Mines game?

1. Check the commitment: sha256(server_seed) must equal the commit_hash published in your game’s start transaction (MinesGameStarted event), proving the board was locked before your first pick.
2. Re-derive the mine mask with the formula above and compare it with the event’s mines_mask.
3. Check the outcome against the mask: every bit of revealed_mask must be a safe tile, and a bust tile must be a mine.
4. Check the multiplier with the payout formula.