Verify a round

You can verify any finished round yourself from public on-chain data, with no account and no special access. There are three things to check: that the commitment hash was published before the round started, that the revealed secret hashes to that commitment, and that recomputing the public formula reproduces the result the round paid on. This walkthrough takes a finished Crash round and verifies it end to end: that the operator’s secret was committed before the round, and that the crash point is exactly what the public formula produces. You need no special access: everything comes from public on-chain data. A short section at the end covers Dice and Mines, which are verified from a single transaction each.

What you are proving

The commitment came first. The hash of the secret was on-chain before the round started, so the outcome could not have been picked after your bet.
The secret matches the commitment. sha256(secret) equals the committed hash.
The multiplier is honest. Recomputing the formula from the secret and the block hash yields exactly the crash point the round paid on.

Step 1: Open the round’s fairness data in the app

Open your bet history (or the round history) and click a finished round to open its details. Alongside the round’s result you will find:

Crashed at: the final multiplier to verify.
Game secret hash: the revealed 32-byte secret. It links to the commit transaction on a Solana explorer.
Block hash: the Solana slot hash used as chain entropy. It links to the round-start transaction.
“Is this game fair? Use fairness tool”: opens the fairness verification tool with this round pre-filled. The tool fetches the round’s three transaction signatures (commit, block hash, reveal) and the network, and recomputes everything below for you in one click.

The fairness tool is the convenient path. The rest of this page is the fully independent path, trusting nothing but the chain and your own computer.

Step 2: The three transactions of a round

Fairness data	On-chain instruction	What it publishes
Commit transaction	`start_new_round`	The commitment `sha256(secret)`, in the `CrashRoundPrepared` event, before betting opens
Block-hash transaction	`start_game`	The captured Solana slot hash, in the `CrashGameStarted` event; the outcome is fixed from this moment
Reveal transaction	`crash`	The revealed secret, the final crash point and the round’s house edge, in the `CrashRoundFinalized` event

Step 3: Read the values from a Solana explorer

Open each transaction on the explorer of your choice (Solscan, Solana Explorer, SolanaFM…), on the network the app runs on. On the transaction page, look for the decoded program events (sometimes under “Logs” or “Instruction data”; explorers that know the program’s IDL decode the event fields by name). Collect five values:

commit_hash: 32 bytes, from the commit transaction.
blockhash: 32 bytes, from the block-hash transaction.
local_e: the 32-byte secret, from the reveal transaction.
crash_point_bps: the final crash point in basis points, from the reveal transaction (30100 means 3.0100x).
edge_bps: the house edge the round was derived with, from the reveal transaction (100 means 1%). It is the round’s own value, fixed when the round started, so a later change to the house edge never affects it.

EncodingsExplorers display 32-byte values as hex, base58 or byte arrays depending on the site. The script below expects hex; convert if your explorer shows base58 (any base58 decoder works; the byte values are what matters, not the notation).

Step 4: Check the order

On the explorer, compare the slot (or block time) of the commit transaction and the block-hash transaction. The commit must be earlier. This is the heart of the scheme: the secret was sealed before the entropy it gets combined with existed.

Step 5: Recompute the crash point

Run this with Node.js (no dependencies), filling in the three hex strings from Step 3:

const { createHash } = require("node:crypto");
const sha256 = (buf) => createHash("sha256").update(buf).digest();

// ── Fill these in from the round's on-chain events (hex, 32 bytes each) ──
const commit = Buffer.from("<commit_hash hex>", "hex"); // from the commit tx
const blockhash = Buffer.from("<blockhash hex>", "hex"); // from the block-hash tx
const secret = Buffer.from("<local_e hex>", "hex"); // from the reveal tx
const edgeBps = BigInt("<edge_bps>"); // from the reveal tx: the house edge this round was derived with

// 1. The revealed secret must match the commitment
console.log("commitment ok:", sha256(secret).equals(commit));

// 2. Recompute the crash point: the same integer math the program runs
const hash = sha256(Buffer.concat([blockhash, secret])); // blockhash first, then secret
const X = BigInt(hash.readUInt32BE(0)); // first 4 bytes, big-endian
const TWO32 = 1n << 32n;
const cappedX = X < TWO32 - 1000n ? X : TWO32 - 1000n;
const raw = ((10000n - edgeBps) * TWO32) / (TWO32 - cappedX); // BigInt division floors
const crashBps = raw > 10000n ? raw : 10000n;

console.log("crash point:", `${Number(crashBps) / 10000}x`, `(${crashBps} bps)`);

Both checks must pass: commitment ok: true, and the printed crash point must equal the round’s Crashed at multiplier (and the crash_point_bps in the reveal event). If they do, you have proven, without trusting anyone, that this round’s outcome was locked in before it started and computed exactly by the public formula.

Dice and Mines

The instant games are verified the same way, from fewer transactions:

Dice: one transaction per bet. Its DiceBetSettled event contains every derivation input (slothash, user, nonce) plus the roll and payout. Recompute with the formula on Dice fairness.
Mines: two transactions per game. The start transaction publishes the board commitment and slot hash; the settlement transaction reveals the seed and the full board. Recompute with the formula on Mines fairness.

If something doesn’t match

First rule out the usual suspects: a base58 value pasted where hex was expected, the wrong transaction (each round has three), or a house edge not taken from the round’s own reveal event (the edge can change between rounds, so always use the edge_bps the round recorded). If you still get a genuine mismatch, that is exactly what this system exists to surface: the data is public and permanent, so anyone can re-run your check. Contact support with the round number, and note that no honest explanation exists for a real commitment or formula mismatch, which is precisely why the scheme makes them impossible to hide.

Welcome

Getting started

Games

Provably fair

Network

Rewards

Security & fairness

Reference

What you are proving

Step 1: Open the round’s fairness data in the app

Step 2: The three transactions of a round

Step 3: Read the values from a Solana explorer

Step 4: Check the order

Step 5: Recompute the crash point

Dice and Mines

If something doesn’t match

​What you are proving

​Step 1: Open the round’s fairness data in the app

​Step 2: The three transactions of a round

​Step 3: Read the values from a Solana explorer

​Step 4: Check the order

​Step 5: Recompute the crash point

​Dice and Mines

​If something doesn’t match

What you are proving

Step 1: Open the round’s fairness data in the app

Step 2: The three transactions of a round

Step 3: Read the values from a Solana explorer

Step 4: Check the order

Step 5: Recompute the crash point

Dice and Mines

If something doesn’t match