How Provably Fair Mines Verification Works

Choose the correct protocol

This example concerns Stake’s documented Mines process. It is not a SPRIBE walkthrough or a universal method for every game called Mines.

Stake documents server and client seeds, a nonce identifying a round in the sequence, and a cursor used when generating bytes. The server-seed hash is available before play; the underlying seed becomes available after rotation. Reproducing the result requires the original seed, not just its hash. Stake’s implementation reference.

Save the evidence at the right time

For a real check, keep the pre-round server-seed hash, client seed, nonce, mine setting and result record. After the server seed is revealed, hash it and compare it with the earlier commitment. Then reproduce the game result with the protocol for that version.

A hash copied only after the result is known does not, on its own, demonstrate what was committed before play.

A synthetic one-mine example

The following inputs were invented for this explanation. They are not a casino account, a played round or an audit of Stake’s live service.

Hashing the server-seed text with SHA-256 gives:

afbc5f0cca7198f1b14ca26cf9b6dfcca1f827be1bae43e4f60ab0ca47bee56c

For the first byte block, use HMAC-SHA256 with the server-seed text as key and editorial-example-client:0:0 as the message. The digest is:

e52daa798ed2dc8b0f6d7c7beda965baf40fe5435032dba18df23ba17d09c5ed

The first four bytes are 229, 45, 170 and 121. Stake’s conversion combines four bytes as:

229/256 + 45/256² + 170/256³ + 121/256⁴ = 0.8952280564699322

This produces the first float. Stake’s byte-to-float conversion.

Multiply it by the initial 25 available positions and take the integer part: floor(0.8952280564699322 × 25) = 22. With zero-based positions counted left to right, then top to bottom, position 22 is row 5, column 3. In this synthetic one-mine example, that is the mine’s position. Stake’s Mines event mapping.

Separate Python and Node implementations produced the same hash, digest, float and first position. Using one mine keeps this example to the first event; a multi-mine check must also reproduce the documented process that prevents duplicate positions.

Compare with the recorded board

A real verification would compare the generated position with the saved result for the same seeds, nonce and setting. A mismatch first calls for checking the inputs, text encoding, indexing and protocol version. It is not enough to compare two screenshots with different settings.

This synthetic example has no live result record to compare. It demonstrates a calculation, not a verified casino payout.

Verification is not prediction

The calculation above uses the server seed. A client seed and a pre-round server hash alone do not supply that input. Reproducing a completed result after disclosure is therefore a different task from identifying a hidden cell before a round ends.

Is Mines rigged, legit or safe?

Those are different questions. A Mines provably fair check can test whether a recorded outcome matches a commitment and a documented procedure. It does not by itself prove that the procedure is unbiased, that an operator honours withdrawals or that an account is eligible in a particular location.

To verify a Mines round, first identify its exact protocol and save the records it requires. A successful seed check is evidence about that recorded outcome, not a guarantee about every operator using the Mines name. A fairness badge or an unexplained screenshot is insufficient to label a casino legitimate or fraudulent.

The casino directory separates operator and regional evidence, while the predictor method guide explains why checking a disclosed result is different from predicting a hidden one.