Provably Fair RNG

The core cryptographic mechanism where the operator first commits to a secret seed and a resulting random number with a hash, then later reveals the original seed for public verification. This prevents the operator from changing the outcome after bets are placed.

• Commit Phase: Server seed hash is published.
• Reveal Phase: Original server seed and client seed are revealed.
• Verification: Anyone can hash the seeds to confirm they match the initial commitment.

Players can provide their own random input, known as a client seed, which is combined with the server seed to generate the final result. This ensures the player has direct, verifiable influence on the randomness, preventing the operator from pre-determining outcomes based solely on their secret.

• Player Control: Users can change their seed for each round.
• Entropy Source: Combines server entropy (secret) with client entropy (known) for robust randomness.

Any participant can cryptographically verify that the published game result was correctly derived from the committed seeds and the agreed-upon algorithm, without requiring special software or trust in a third party. This transforms fairness from a promise into a mathematically provable claim.

• Open Algorithms: The RNG formula (e.g., using HMAC-SHA256) is public.
• Independent Audit: Users or watchdogs can re-run the calculation to confirm results.

The exact deterministic function used to combine the seeds and generate the final random number is publicly documented and open-source. Common algorithms include SHA-256, HMAC, or Mersenne Twister implementations. Knowing the algorithm allows for precise replication of the result verification process.

• Example: Result = HMAC-SHA256(server_seed, client_seed)
• Deterministic: Same inputs always produce the same output, enabling verification.

A nonce (number used once) is incremented for each consecutive game round, ensuring every random result is unique even if the server and client seeds remain the same. This prevents result prediction and guarantees a fresh, unpredictable outcome for every bet.

• Sequential Uniqueness: Round 1 uses nonce 1, Round 2 uses nonce 2, etc.
• Input to RNG: The nonce is included in the data hashed to produce the final number.

Specialized gaming and gambling blockchains heavily rely on external oracles for Provably Fair RNG.

• Polygon (formerly Matic): Many gaming dApps on Polygon integrate Chainlink VRF to guarantee fair outcomes for users.
• Ronin: The Axie Infinity sidechain uses secure oracles for random elements in gameplay and NFT generation.
• WAX: The WAX blockchain often employs oracles to provide verifiable randomness for its NFT packs and collectibles.

The security of a provably fair system hinges on the seed generation and commitment phase. A malicious operator can manipulate the outcome if they control both the server seed and the client seed before the commitment. The standard mitigation is to use a multi-phase commit-reveal scheme where the server commits to a hash of its seed first, the client provides their seed, and only then does the server reveal its original seed for verification.

A provably fair algorithm is only as random as its input seeds. If the entropy source for the server or client seed is predictable (e.g., using a timestamp), the final result becomes biased and attackable. Best practices mandate using cryptographically secure random number generators (CSPRNGs) for initial seed generation. The proof verifies the algorithm's execution, not the quality of its initial randomness.

The deterministic function combining the seeds (e.g., HMAC-SHA256(server_seed, client_seed)) must be carefully designed to prevent:

• Entropy loss: The output must preserve the full entropy of the inputs.
• Predictability: Even with one seed secret, the function should not leak information about the other.
• Bias introduction: The mapping from seed space to result space (e.g., a number 1-100) must be uniform. A flawed mapping function can create exploitable biases.

Security failures often occur outside the core cryptographic proof:

• RNG pre-computation: An operator could generate millions of potential future seeds offline to search for favorable outcomes before commitment.
• Logic bugs: Flaws in the smart contract or backend code that selects or applies the seeds can bypass the proof.
• Lack of true client entropy: If the client seed is auto-generated by the platform, it negates client-side fairness. True user-provided entropy (like a custom string) is essential.

The 'provable' aspect requires users to actively verify the proof, which is often technically complex. This creates a trust gap:

• Most users cannot or do not perform the verification, relying instead on community auditors.
• The system's front-end could display a falsified verification result.
• The published source code for the verification tool must match the code executed on-chain or by the server. Transparency logs and on-chain verification are mitigations.

Provably fair RNG has inherent conceptual limits:

• It proves past fairness only. It cannot guarantee future fairness if the operator changes the system.
• It does not prevent transaction censorship. An operator could refuse to submit a losing transaction or reveal a seed for a round where the user won.
• It is not a substitute for decentralization. A centralized operator controls the game logic and payout execution, which are points of failure separate from the randomness proof.

The unpredictable input data used to generate random numbers. For a system to be truly fair, entropy must be unpredictable and unbiased. Common sources include:

• Block Hashes: The hash of a future blockchain block (e.g., blockhash(blockNumber)).
• Oracle Data: External data feeds from services like Chainlink.
• User-Provided Seeds: Inputs from participants combined with the server seed.

Weak entropy (e.g., predictable timestamps) compromises the entire RNG system.

A key architectural distinction in how randomness is generated and verified.

• On-Chain RNG: Uses data already on the blockchain (e.g., future block hashes). It's transparent but can be vulnerable to miner/validator manipulation if not properly designed.
• Off-Chain RNG: Generated by an external service (like an oracle) and submitted to the chain with a proof. This can provide stronger entropy but introduces a trust assumption in the oracle provider.

Hybrid models combine both for enhanced security.

Provably Fair RNG is critical for NFT minting and allowlist selection to ensure equitable distribution and prevent insider advantages.

• Mint Order & Traits: Randomly assigns rarity traits to NFTs in a collection in a verifiable way.
• Allowlist Selection: Randomly selects winners from a pool of applicants, with the process being auditable post-reveal.

Without provable fairness, projects risk accusations of rigging outcomes, damaging community trust.