What the Transparency Scorecard Covers

Mathematical Audit Benchmark

How Does This Compare to 0% House Edge Protocols?

Audited 100% RTP

Instead of standard 1.00% to 4.00% casino house margins, compare with mathematically verified 100% RTP Originals (0.00% House Edge) on Duel Casino:

Explore Zero House Edge on Duel
→

Casino Transparency Scorecard: 12 Metrics You Can Measure Yourself

Transparency is not a marketing word; it is a set of observable facts. A scorecard gives you a repeatable way to check whether a casino publishes enough data to audit its own behavior. This page defines 12 metrics you can measure yourself using public documents, game logs, on-chain records, and licensing registers. The first six cover game integrity: pre-commit hashes, server-seed rotation, client-seed reuse, RNG documentation, house-edge math, and observed return distributions. The next six cover operations: withdrawal latency, wallet balances, license status, auditor reports, and external certifications. For each metric we state what to collect, which transformation to apply, and the red flag to record. You can complete the audit with no proprietary software: a terminal, a block explorer, and a PDF reader are enough. If you want to reuse the definitions later, see our glossary entry on provably fair games. When comparing operators, our casino reviews show which documents each site publishes.

Game Integrity Metrics (1–6): Audit Before You Bet

Game integrity metrics are the only ones you can check before a round even finishes, because the casino has to publish a commitment before the outcome is known. In a genuine provably fair system, the server seed is hashed and shown in advance; once the round is closed, the casino reveals the seed and you recalculate the hash. Your own client seed and the nonce complete the HMAC input.

Metrics 1–3: Seed commitment, seed reveal, and nonce

• Metric 1 — Pre-reveal hash commitment. The casino publishes a hash of the server seed before the round. You save it and compare it with the SHA-256 hash of the revealed seed after the round.
• Metric 2 — Seed reveal and verification. After the round, you take the server seed, client seed, and nonce, apply the documented HMAC-SHA256 derivation, and check that the resulting number matches the game result.
• Metric 3 — Nonce and rotation counter. Every player bet increments the nonce. A missing nonce, reused nonce, or hidden server-seed rotation reset breaks the audit trail.

Metrics 4–6: RNG documentation, RTP math, and observed returns

• Metric 4 — RNG source and whitepaper. The site should state whether the result is derived from the hash, a hardware random source, or a chain-based value. If it does not, the output cannot be replicated.
• Metric 5 — House edge from the paytable. Calculate the expected return from the paytable yourself. For example, a 2x payout with 49.5% probability returns 99% RTP; the house edge is 1% if the published probability matches the hash distribution.
• Metric 6 — Observed return sample. Using the past rounds from the API or block explorer, run a chi-square or binomial test on the number of wins. A 10,000-round sample should be within sampling error of the stated RTP; if not, treat the deviation as a material red flag.

For a step-by-step replay of hash-derived games, see our guide to verifying crash and dice results. The same commands are used for most provably fair casinos.

Operational and Financial Transparency Metrics (7–12): Verify the Entity Behind the Casino

Game integrity proves only that the game logic is fair in theory. The other six metrics test whether the casino is solvent, licensed, and willing to let outsiders confirm its claims. These checks are worth more when the casino already passed metrics 1–6, because you then know the games are not the main variable in the audit.

Metrics 7–9: Withdrawals, wallet balances, and on-chain flow

• Metric 7 — Withdrawal confirmation latency. A transparent casino publishes expected withdrawal windows or shows the transaction ID for every payout. You measure the time from request to on-chain confirmation; consistent delays beyond the published window are a signal that the house may be managing cash flow, not liquidity.
• Metric 8 — Hot wallet balance and exposure. Check the hot wallet used for automatic payouts. If the balance is consistently smaller than average daily withdrawals, manual intervention is required; in an emergency this becomes default risk.
• Metric 9 — Cold wallet reserve and proof-of-liability style data. Some casinos publish signed messages from cold wallets or merkle-tree style snapshots of player balances. You can verify a Merkle root if the leaves are disclosed; if only a total is shown, you cannot validate it.

Metrics 10–12: License, disclosures, and independent audit

• Metric 10 — License register lookup. Go directly to the regulator’s register and search the operator name, not just the brand. Confirm the license number, domain, and expiry date. For Curaçao, check the master license holder and sub-license; for Malta, check the MGA register for the exact gaming service type.
• Metric 11 — Auditor and financial statement availability. Publicly listed operators file annual reports; private ones rarely do. At minimum, the casino should disclose ownership, country of registration, and a governing law clause. If these are absent, the entity behind the casino is unverifiable.
• Metric 12 — Third-party game certification. Look for a certification report from a recognized testing laboratory (GLI, iTech Labs, or an accredited internal audit unit). The certificate should name the operator, the game family, and the date. A generic badge on the website is not enough.

Operator-level checks belong in the same audit loop as bankroll planning; see bankroll management fundamentals for how to decide when one session’s edge is worth the liquidity risk of a site with no audited statements.

Transparency Checklist and FAQ

• Save the pre-round hash for 10 consecutive rounds and verify each reveal with a SHA-256 command.
• Recompute the final result from the server seed, client seed, and nonce using the exact algorithm in the whitepaper.
• Calculate the house edge from the paytable and compare it with the probability output of the hash-to-result mapping.
• Pull at least 10,000 historical rounds from the API and run a binomial confidence interval on win rate.
• Trace a test withdrawal: record request time, mempool time, and confirmation time; compare with the published window.
• Search the regulator’s register for the exact legal entity shown in the casino terms; look for license number and expiry.
• Check the latest certificate from a testing lab, with game family and operation date, before making rating decisions.

Do I need to verify every single round?

No. The scorecard works on a sample. Verify 10–30 consecutive rounds across different games, then independently confirm seed rotations and nonce increments. In a deterministic HMAC system, if the derivation logic is correct on those samples, the chance of a different logic on unsampled rounds is low but not impossible; keep the sample random and record each hash before the result.

What if the casino uses an external auditor instead of provably fair?

That is a different but still verifiable model. You cannot recalculate the result from a seed, so you have to rely on the auditor’s report. Check that the auditor tested the live system, not just the same code in a staging environment. Ask the casino for the report ID or test logs; if they cannot produce them, the certification claim is not measurable.

How many past rounds do I need before an RTP deviation is meaningful?

The standard deviation for a binary bet with probability p is sqrt(p(1-p)/n). For a 49.5% game over 10,000 rounds, the standard deviation is about 0.5%, and with 95% confidence you measure win rate within roughly 1%. For multi-payout games, run a chi-square test over all payout buckets. Treat deviations above 2% in the primary payout as evidence for further investigation, not a proof of fraud on its own.