How to Verify a Provably Fair Hash Yourself

Verifying a provably fair crash round takes about 90 seconds and requires no special software — only a modern browser and a willingness to copy-paste two hex strings. This article walks through a real verification against a Stake Crash round, step by step, showing exactly how to confirm that the operator honored their pre-commitment.

What will I need to verify a round?

Three things:

1. A modern web browser — Chrome, Firefox, Edge, or Safari. You will use the browser's built-in developer console.
2. Your provably fair seeds — the server seed (revealed after rotation), your client seed, and the nonce of the round you want to verify. These are available in the platform's fairness settings.
3. About 90 seconds of patience.

No special software. No downloads. No command-line tools. Everything you need is built into your browser.

If you want to understand what you are verifying and why it matters before you start, read Provably Fair, Explained first. This article assumes you understand the concept and want the hands-on walkthrough.

Where do I find the server seed, client seed, and nonce?

The location varies by platform. Here is where to find them on the three games currently under review:

Stake Crash:

1. Click your profile icon → Settings → Fairness (or navigate directly to the fairness page).
2. You will see: Server Seed (Hashed) — this is the SHA-256 hash of the current server seed. Client Seed — this is your client seed (editable). Nonce — this is the current nonce (increments with each bet).
3. To reveal the server seed for verification, click "Rotate" or "Change Seed." This ends the current rotation, reveals the old server seed, and starts a new one.

BC.Game Crash:

1. Click your avatar → Fairness or Provably Fair.
2. Similar layout: hashed server seed, client seed, nonce.
3. Rotate to reveal the old server seed.

Roobet Crash:

1. Navigate to the Provably Fair section in settings.
2. Same pattern: hash, client seed, nonce, rotate to reveal.

Before you rotate: Write down or screenshot your current client seed and the nonce of the round you want to verify. After rotation, the old client seed may no longer be displayed.

How do I compute the SHA-256 of the revealed seed?

After rotating, you will see the actual server seed — a long hex string. Your first step is to confirm that the SHA-256 hash of this seed matches the hash that was displayed before the rotation.

Method 1 — Browser console:

Open your browser's developer console (F12, then click "Console") and paste:

async function sha256(message) {
  const encoder = new TextEncoder();
  const data = encoder.encode(message);
  const hash = await crypto.subtle.digest('SHA-256', data);
  return Array.from(new Uint8Array(hash))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');
}

// Replace with your actual revealed server seed:
sha256('your_revealed_server_seed_here').then(console.log);

The output is a 64-character hex string. Compare it character by character to the server seed hash that was displayed before the rotation.

Method 2 — Online tool:

Search for "SHA-256 online calculator." Paste the revealed server seed. Compare the output to the committed hash.

If they match: The operator committed to this seed before any rounds were played. Proceed to the next step.

If they do not match: The operator changed the seed after committing its hash. This is a critical failure. Document everything and report it.

How do I derive the multiplier from the HMAC?

Now you know the server seed is authentic. Next, verify that a specific round's crash point was correctly derived from the seed.

In the browser console:

async function hmacSha256(key, message) {
  const encoder = new TextEncoder();
  const keyData = encoder.encode(key);
  const msgData = encoder.encode(message);
  const cryptoKey = await crypto.subtle.importKey(
    'raw', keyData, { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']
  );
  const sig = await crypto.subtle.sign('HMAC', cryptoKey, msgData);
  return Array.from(new Uint8Array(sig))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');
}

async function verifyCrashPoint(serverSeed, clientSeed, nonce) {
  const hash = await hmacSha256(serverSeed, clientSeed + ':' + nonce);

  // Take first 8 hex characters (32 bits)
  const h = parseInt(hash.substring(0, 8), 16);

  // Check for instant crash (house edge implementation)
  // Note: the exact modulus varies by platform
  if (h % 33 === 0) {
    return 1.00;
  }

  // Compute multiplier
  const e = Math.pow(2, 32);
  const result = Math.floor((100 * e - h) / (e - h)) / 100;
  return Math.max(1, result);
}

// Replace with your actual values:
verifyCrashPoint(
  'your_revealed_server_seed',
  'your_client_seed',
  42  // the nonce of the round you want to verify
).then(point => console.log('Computed crash point:', point));

Important caveats:

• The exact formula (especially the modulus for instant crashes and the multiplier derivation) varies between platforms. The code above is a common implementation pattern, not a universal one. Check the platform's provably fair documentation for their specific formula.
• The nonce is per-bet, not per-round. If you skipped rounds (did not bet), your nonce did not increment for those rounds.
• Floating-point precision can cause the last decimal to differ by 0.01. A computed result of 2.47 matching a displayed result of 2.47 is a pass. A computed result of 2.47 matching a displayed result of 3.12 is a fail.

What do I do if my verification doesn't match?

First, rule out user error:

1. Check your client seed. Are you using the client seed that was active during the round you are verifying? If you changed it, you need the old one.
2. Check the nonce. The nonce is per-bet. If the platform counts nonces differently than you expect, the mismatch may be a nonce offset.
3. Check the formula. Different platforms use different derivation formulas. Confirm you are using the correct one for the platform you are verifying.
4. Check the server seed. Are you using the revealed server seed from the correct rotation? If you have rotated multiple times, make sure the seed corresponds to the rotation that was active during the round.

If you have ruled out user error and the verification still fails:

1. Screenshot everything. The revealed server seed, the committed hash, your client seed, the nonce, the displayed crash point, and your computed crash point.
2. Try additional rounds. Verify 3–5 more rounds from the same rotation. If they all fail, the issue is systematic. If only one fails, it may be a data display error.
3. Report to the platform. Most platforms have a support channel for provably fair disputes.
4. Report to an independent auditor. Clash Watchdog AI accepts verification failure reports. If our analysis confirms the failure, it will be noted in the game's audit report.

A single verification failure in a correctly implemented system should never occur. The cryptographic operations are deterministic — the same inputs always produce the same output. If the output does not match, either the inputs were wrong (user error) or the system is not operating as described (platform issue).

How do I verify many rounds at once?

For spot-checking, verifying 5–10 rounds manually is sufficient. For systematic verification of hundreds or thousands of rounds, you need a script.

A minimal batch verifier in JavaScript:

async function verifyBatch(serverSeed, clientSeed, startNonce, endNonce) {
  const results = [];
  for (let nonce = startNonce; nonce <= endNonce; nonce++) {
    const computed = await verifyCrashPoint(serverSeed, clientSeed, nonce);
    results.push({ nonce, crashPoint: computed });
  }
  return results;
}

// Verify rounds 1 through 100:
verifyBatch('your_server_seed', 'your_client_seed', 1, 100)
  .then(results => {
    console.table(results);
    console.log('Verified', results.length, 'rounds');
  });

This produces a table of nonces and computed crash points. Compare each entry against the platform's displayed result for that nonce.

For large-scale verification (thousands of rounds), Clash Watchdog AI uses automated pipelines that ingest data from multiple sources and verify every round in a rotation. This is part of our Column C audit. Our verification notebooks are published alongside each audit report for reproducibility — anyone can re-run our verification and confirm our results.

The fundamental value of verification — whether you do it yourself for 5 rounds or we do it systematically for 50,000 — is the same: it converts "trust the operator" from an act of faith into a testable, falsifiable claim. See our game listings for which games we have verified and what we found.