Protocol - 2026 · HMAC-SHA256 verification routine

How we verify casino originals

Every brand-game audit on this site follows the same seven-step verification protocol. Any reader can reproduce it in 15 minutes on a laptop. The protocol is published below in full so the audit data is independently verifiable.

Seven steps · Same routine across all 66 brand-games

The verification protocol

  1. 1

    Capture commit hash before play

    Open the operator's published fairness panel. Capture the SHA-256 server-seed hash and the current nonce position before placing any bet. This is the pre-commitment the operator can no longer change.

  2. 2

    Place a controlled sample of 20-50 rounds

    Use a consistent configuration: same target multiplier, same mine count, same risk tier. Log per round: client seed, nonce, recorded outcome, recorded payout. Sample size 20-50 rounds.

  3. 3

    Rotate the server seed to reveal it

    In account settings, rotate the server seed. The operator reveals the raw seed value at this moment. The previously-captured commitment must match SHA-256 of the revealed seed.

  4. 4

    Reproduce HMAC-SHA256 locally per round

    For each logged round: compute HMAC-SHA256(server_seed, client_seed:nonce). Convert the hex output to a normalised float in [0,1) per the operator's published algorithm. Apply the game's outcome function (curve, threshold, grid pick) to derive the expected outcome.

  5. 5

    Compare reproduced vs recorded outcomes

    For each round, the reproduced outcome must equal the recorded outcome. Bit-for-bit match. If any round diverges, the operator's implementation differs from its published algorithm - that is a critical finding documented in the brand-game audit page.

  6. 6

    Cross-check RTP against operator-published figure

    Across the sample, compute the empirical RTP. The operator's published per-game RTP is the target. Empirical RTP within sampling variance is consistent. Persistent divergence at scale indicates either a marketing-claim gap or an implementation issue.

  7. 7

    Document timeline and observation in the trust file

    Every verified figure goes into data/casinos/{brand}-{game}.json with _verification_outcome (match | discrepancy | pending) and _verification_outcome_confirmed_at timestamp. Published content cites trust file by reference.

This page explains how casino-originals.com produces a review. Every published number, licence reference, and fairness claim across the site passes through the same workflow before it goes live. We document that workflow openly because verification only works when the routine itself is transparent.

The three-source rule

Every numerical, licensing, or product claim on a brand-game page passes through three independent references before publication:

1. Operator documentation - the figure pulled from the brand's own published help panel, RTP page, or in-game info screen. 2. Authority registry - for fairness and RTP, the Bitcoin.com gambling registry; for licence, the relevant regulator's public registry (Curaçao eGaming, Anjouan iGaming, Tobique Gaming Commission). 3. Community or developer record - a reproduction by an independent verifier on GitHub, a developer-built fairness replay, or a credible community post documenting a consistent sample.

When all three sources agree, the figure is recorded in our internal trust store and goes on the relevant brand-game page with all three references. When they disagree, we flag the discrepancy on the page and publish whichever has the strongest evidence chain.

The three-source rule does not apply to operator marketing copy, social-media announcements, or affiliate-network advertising. Those carry zero weight.

Fairness verification

every brand in our audit set uses HMAC-SHA256 as the cryptographic primitive behind their original games. The verification step is straightforward to reproduce:

  • We open a funded test account at each brand and place a sample of 50 to 100 bets per game.
  • Before each bet we capture the server-seed hash from the fairness panel (the brand commits the seed via SHA-256 hash up front).
  • We let each round resolve and record the outcome plus the nonce.
  • At the end of the sample we rotate the server seed. the brand reveals the raw seed.
  • We hash the revealed raw seed locally; the hash must match the original commitment.
  • We run HMAC-SHA256 over (revealed server seed, client seed, nonce) on our local script. The output must reproduce the recorded outcome bit-for-bit.
  • We check that the mean payout across the sample tracks the brand-published RTP target within statistical noise.

If the hash commitment does not match, the brand could have changed the seed after the bet - a fairness break. If the HMAC bytes do not reproduce the recorded outcome, the published mapping formula is wrong. In either case we flag the brand and downgrade the verdict. Across our last audit cycle every brand in our set passed both checks.

If you want to reproduce this yourself on a single round, the worked walkthrough is on how to verify a provably-fair roll. The deeper cryptographic explainer is in the HMAC-SHA256 post.

What the fairness check proves and does not prove

The cryptographic step is a strong mathematical guarantee about one specific thing: the brand cannot retroactively alter the outcome of a bet that was already placed. Tampering with the server seed after the fact would change the hash, and the player or auditor sees the mismatch.

It does not guarantee:

  • That the brand will pay your withdrawal without delay.
  • That the brand's licence remains valid through the next regulatory action.
  • That the published RTP will stay at the same value in a future build of the game.
  • That the customer-support response time on disputes is reasonable.
  • That a utility token (BFG, SHFL, TFS, RLB) will retain market value over the audit window.

We describe each boundary openly on the page where it matters.

Re-check cycle

Every brand-game page is re-verified on a 90-day cycle. The last audit date and the next scheduled date are printed at the bottom of every page. 90 days is the working balance - long enough that we are not chasing trivial menu changes, short enough that meaningful RTP shifts, licence changes, or fairness-pipeline updates are caught within a quarter.

We also run out-of-cycle checks when an operator announces a relevant change (within seven days of the announcement) or when a credible community report flags a discrepancy (within ten days of the report). Affiliate-network changes do not trigger a re-check; our verification is independent of commission status.

What each brand-game page documents

So that comparisons across brands stay apples-to-apples, every brand-game page records the same set of facts in the same format:

  • Verified RTP (with the audit date).
  • House edge (computed from RTP, not parsed from operator marketing).
  • Maximum multiplier (brand-published ceiling, three-source confirmed).
  • Mechanic class (drop-multiplier, multiplier-curve, grid-reveal, target-multiplier, tower-climb, etc.).
  • Fairness pipeline components (server seed, client seed, nonce, cursor where applicable).
  • Bet limits (minimum and maximum stake at the base tier).
  • Deposit minimum (operator-wide).
  • Withdrawal cadence (community-sampled median plus typical peak-hour outliers).
  • Affiliate disclosure (visible copy on every page that carries a button).
  • Verification chain (the three references behind each fact, dated).

Boundary of the verification scope

We are rigorous inside our scope and honest about what falls outside it:

  • We do not run operator solvency audits. We have no visibility into wallet balances, withdrawal queue depth, or treasury management.
  • We do not mediate withdrawal disputes. If your withdrawal is stuck, the brand's support channel is the right route.
  • We do not provide personal bankroll advice. The strategy posts describe expected-value math, not a plan for an individual reader.
  • We do not verify regulatory compliance beyond the licence record. A licensed by + regulator can still be operationally non-compliant.
  • We do not see KYC artefacts.
  • We do not predict token-economy returns.
  • We do not endorse any operator. We document the facts and let the reader decide.

Authority sources we cite

A handful of external resources support the three-source rule across the site. None of them sponsor casino-originals.com or pay for placement.

  • The Bitcoin.com gambling registry - cross-operator fairness verification on the original-games mechanic class.
  • GamCare and BeGambleAware - independent player-protection guides, cited across the audit set on responsible-play notes.
  • Public regulator registries (Curaçao eGaming, Anjouan iGaming, Tobique Gaming Commission) - queried per cycle for licence validity.

How the editorial team runs a cycle

In the most recent cycle Karssen Avelara opened funded test accounts on each of the ten brands. The fairness-replay step ran sample bets across Plinko, Crash, Mines, and Dice, with the seed-hash and HMAC verification confirmed locally. Every figure on every brand-game page was cross-checked against the brand documentation, the authority registry, and a developer or community record. The verification log is stored in the trust-data layer, dated to the audit. The cycle repeats every 90 days.

Changes

We update this page when the verification routine changes - a new authority source, a new fairness primitive at an audited operator, a different re-check cadence, or a change to the set of audited brand-games. The revision appears at this URL with a new "Last updated" date at the top.

Contact

Email: editor@casino-originals.com

Related editorial trust pages: terms of use, privacy policy, responsible gambling, about the editorial team.

Related from the audit cluster

For the full brand context behind this audit, open the Home.