Provably fair algorithms are designed to give players cryptographic proof that each game outcome was generated fairly, without manipulation by the casino. However, the practical implementation of these systems often contains weaknesses that undermine their trustworthiness. As a player, you can—and should—verify the claims yourself. This article outlines five red flags that indicate a provably fair system may be unreliable, and explains exactly how to check each one using publicly available data, seed histories, and your own computing tools.
Red Flag #1: Opaque or Non-Standard Hashing Algorithm
The core of any provably fair system is a one-way hash function. Legitimate implementations use well-established, publicly audited algorithms such as SHA-256 or SHA-512. A red flag appears when a casino uses a proprietary hash function, an undefined combination of multiple hashes, or a custom algorithm whose source code is not published.
How to check: Look for clear documentation of the hash function. If the casino does not explicitly state the algorithm, or if it uses a function like “double SHA-256” without revealing the exact method, you cannot independently verify that the hash is computed correctly. Use the pf-verifier tool to run the same algorithm on the provided seeds and compare the resulting hash. If the output does not match, the system is broken.
| Hash Function | Status | Verification |
|---|---|---|
| SHA-256 (or SHA-512) | Standard – auditable | Easily reproduced with any SHA library |
| Custom combination (e.g., SHA-256 + MD5) | Suspicious – requires full source code | Only verifiable if the exact combination is published |
| Proprietary, no source code | Red flag – cannot be verified | No verification possible |
Red Flag #2: Static or Reused Server Seeds
A critical property of provably fair systems is that the server seed (the casino’s secret) must be generated fresh for each game round and discarded after the round ends. If the same server seed is used for multiple rounds, or if seeds are not rotated at all, a player can derive future outcomes by observing past results.
How to check: Examine the seed history available on the casino’s fairness ledger or similar page. Verify that each game round has a unique server seed hash. You can also check that the seed cycle follows a predictable pattern (e.g., every 1000 rounds) and that the casino does not reuse seeds. Some casinos provide a list of the last 1000 server seed hashes; confirm that none are identical.
Additionally, use a script to fetch the seed for a past round and check that the same seed does not appear for a different round. If duplicates exist, the system is not truly provably fair.
Red Flag #3: Client Seed Not Under Player Control
The client seed is the player’s contribution to the random outcome. It should be modifiable by the player before each round, so that even if the casino knows the server seed, the player can change the client seed to ensure a new outcome. A red flag is when the casino does not allow the player to change the client seed, or when the client seed is fixed for the entire account.
How to check: Before placing a bet, navigate to the game settings or provably fair page. Look for an option to change the client seed. If it is not present, or if the system says “client seed is automatically generated every round” without giving you control, that is a red flag. True provably fair systems allow you to set your own client seed, or at least to view and change it between rounds. Check the provably fair guides for typical implementations.
If you can change the client seed, do so after each round and verify that the outcome changes correspondingly. If the outcome remains the same, the seed is not being used in the calculation.
Red Flag #4: No Public Verification Tool or Manual Verification Steps
Provably fair is only as valuable as the player’s ability to verify it. A casino that claims provably fair but does not provide a verification tool on its website, or at least a step-by-step explanation of how to manually verify, is hiding something. The verification tool should accept the server seed hash, client seed, and nonce, and output the game result.
How to check: Visit the game’s provably fair page. If there is no embedded verifier and no example of manual verification (e.g., using a command-line hash tool), treat the claim as unsubstantiated. You can use our pf-verifier tool to test the casino’s algorithm: you need the exact seeds and nonce. If the casino provides these but the result does not match the verifier output, the algorithm is misimplemented.
A further red flag is when the casino provides a verification tool that only works for certain games or requires you to trust a third-party service without source code. Insist on open-source verifiers or at least a reproducible manual process.
Red Flag #5: RTP Does Not Match Provably Fair Math
Even if the hash function and seeds are correct, the casino may still manipulate the game by mapping the hash output to a game result in a way that lowers the RTP (Return to Player) below what is mathematically expected from a fair distribution. Common tricks include using a weighting function that skews the outcome, or adding a house edge beyond the standard 1–5%.
How to check: First, obtain the algorithm that converts the hash to a game result. For example, in a dice game, the hash should be converted to a number between 0 and 9999, then the casino may apply a house edge by defining a win range. The expected RTP can be calculated from that range. Compare the casino’s stated RTP with the theoretical RTP derived from the public algorithm. If they do not match, the casino is either misrepresenting the RTP or using a non-transparent mapping.
You can also run a simulation: gather the last 10,000 outcomes (if the casino provides a history) and compute the actual RTP. If it significantly deviates from the promised RTP after accounting for statistical variance, the system may be rigged. Always cross-check with the bankroll management principles to understand the expected variance.
FAQ
What is the most common provably fair flaw I can check immediately?
The most common flaw is the inability to change the client seed. If you cannot modify your client seed, the casino has full control over the outcome. Check the settings of any game claiming provably fair; if no client seed option exists, it is a red flag.
How can I verify a casino’s provably fair algorithm without a tool?
You need the server seed hash, client seed, and nonce. Then use a standard SHA-256 library (e.g., using OpenSSL or any online hash tool) to compute the hash of the concatenated seeds. Then convert the hash to a number using the game’s published method. If the resulting number matches the game outcome, the algorithm is working. Most casinos that are truly provably fair provide a manual verification example.
Should I trust a casino that uses a proprietary hash function?
No. Proprietary or undocumented hash functions cannot be independently verified. Even if the casino provides a verification tool, without the source code you cannot be sure the tool is honest. Stick to casinos that use standard, open-source hash functions like SHA-256 and provide full documentation of the algorithm.







