A “provably fair” claim needs a reproducible result

One published provably-fair approach uses a commit-and-reveal design. Such a design can let you check that a published result follows from specified inputs and that a secret input matches a commitment shown earlier. The details vary by operator and game; never paste one site's seeds into another site's formula and call the mismatch evidence of fraud.

The components you need

Step 1: verify the commitment

Suppose the operator displayed a SHA-256 hash before the wager and later reveals the server seed. Compute SHA-256 over the exact bytes of the revealed seed. The result must match the pre-wager hash character for character.

NIST describes SHA-256 as a hash algorithm that creates a message digest used to detect whether a message changed. See the NIST SHA-256 glossary and its hash-functions overview.

Step 2: recompute the raw outcome

Follow the operator's exact specification. HMAC-SHA256 and plain SHA-256 are not interchangeable. Neither are server:client:nonce, client:nonce:server and their byte encodings. Record:

• hash or HMAC function and which input is the HMAC key;
• input order, delimiters and character encoding;
• client seed, server seed, nonce and any cursor or round ID;
• how many output bytes or hexadecimal characters are read;
• rejection sampling, modulo, rounding and precision rules.

The example shows the questions to answer; it is not a universal verifier. Use only the algorithm published for the exact game and version being checked.

Step 3: audit the result mapping

A correct digest can still be interpreted incorrectly. For case opening, you need the probability intervals and item ordering. For roulette or coinflip, you need the ticket range and boundary rules. For crash, you need the multiplier formula, maximum and instant-crash condition. For battles, you may need seat order, shared inputs and tie handling.

A reproducible verification record

1. Before betting: save the commitment, your client seed, nonce/round identifier, rules version and timestamp.
2. After reveal: save the server seed and the complete displayed outcome record.
3. Verify the commitment: hash the revealed seed using the documented algorithm.
4. Recompute the digest: use a separate implementation or inspectable code, not only the operator's verifier.
5. Map the digest: reproduce the ticket, multiplier or item using published boundaries.
6. Compare: record expected versus displayed result and every assumption.
7. Retain safely: redact account identifiers and never publish active secret material that could compromise an account.

A record should identify the operator, game, algorithm version, timestamp and source URL. If the documentation changed after the wager, archive both versions and do not silently apply the new formula to the old result.

How to read operator fairness pages

Operator documentation is a primary source for what the operator says its system does. It is not independent certification. For example, Bandit.Camp's public fairness article describes a design involving EOS block data for some games and a different client-seed system for others. RustClash publishes a separate fairness page. These links are examples of documentation to inspect, not SkinRake endorsements or completed audits.

For each operator, ask:

• Does the page cover every game marketed as provably fair?
• Can you obtain all inputs for your own completed wager?
• Is the verifier source visible, or only a closed form?
• Can you independently reproduce the mapping, including boundaries?
• Does the documentation identify versions and changes?

What a successful verification does not prove

Fairness red flags

• The verifier asks only for a bet ID and returns “valid” without exposing inputs or computation.
• A method claiming a hidden server seed exposes it before the wager, or provides no pre-wager commitment.
• The player cannot view or change the client seed despite marketing that says they control it.
• The published hash matches, but the probability table or mapping is missing.
• Different pages specify different algorithms without a version history.
• Only winning examples are provided, or the site prevents exporting historical data.
• A third-party randomness source is named without explaining when it is selected and how it enters the result.

If your result does not match

First assume a reproducibility problem, not fraud. Check whitespace, letter case, character encoding, nonce indexing, cursor, input order, HMAC key/message direction, endianness, decimal precision and algorithm version. Then preserve the full record and ask the operator to identify the exact discrepancy.

A useful report contains the pre-wager commitment, revealed seed, client seed, nonce, displayed result, expected result, documentation version and independent code or calculation. Do not publish account secrets or identity data. One unexplained mismatch merits investigation, but it still needs a complete record and an opportunity for a technical response.

Use this technical check alongside the Rust gambling safety guide and withdrawal guide. SkinRake has not independently completed these fairness tests. The RustyLoot evidence profile labels operator claims and testing limits, while the review directory separates published profiles from incomplete research.