Provably Fair

The core mechanism where the service provider generates a seed and commits to it before the user's action. This is done by publishing a cryptographic hash (e.g., SHA-256) of the seed, known as the server seed. This hash acts as a tamper-proof commitment, ensuring the seed cannot be changed after the fact without detection.

To ensure the outcome is not predetermined by the server, the user provides their own random input, called the client seed. This seed is combined with the server's seed to generate the final result. The user can change their seed for each round, adding a layer of unpredictability controlled by the participant.

The final result (e.g., a random number, card draw, or dice roll) is generated by a deterministic, publicly disclosed algorithm (like HMAC-SHA256) using both the server and client seeds. Because the algorithm is known, anyone can re-run the calculation with the revealed seeds to confirm the result matches the published outcome.

After the round concludes, the service provider must reveal the original server seed. Users can then:

• Hash the revealed seed to verify it matches the original commitment hash.
• Input both seeds into the known algorithm to reproduce the result. This transparent audit process allows for after-the-fact verification by any third party, eliminating the need to trust the operator.

While pioneered by online casinos, provably fair logic is critical in decentralized systems:

• NFT minting and fair drops to prevent front-running.
• Blockchain lotteries and prediction markets.
• Validator/leader election in some consensus mechanisms.
• Randomized airdrops to ensure equitable distribution.

Provably fair does not mean 'perfectly fair'—it only verifies the execution of a predefined process. Key limitations include:

• Algorithm Bias: A flawed or predictable generation algorithm can be exploited.
• Seed Entropy: Weak randomness in seed generation compromises security.
• Implementation Bugs: Errors in the code can invalidate the cryptographic guarantees.
• User Verification Burden: The onus is on the user to perform the audit.

A Provably Fair system operates on a commit-reveal scheme. The service provider first generates a secret seed and a public commitment (hash). After the user provides their input, the final result is generated using both seeds. The provider then reveals their original secret, allowing anyone to cryptographically verify that the result was determined fairly and was not altered after the fact.

A critical limitation is reliance on client-side entropy. If the user's seed is predictable (e.g., derived from a timestamp) or compromised, the overall randomness is weakened. Malicious implementations may also use flawed or biased pseudo-random number generators (PRNGs) on the client side, undermining the fairness guarantee despite the cryptographic proof.

Systems that derive randomness from external oracles or public data feeds (e.g., future block hashes, weather data) introduce a trust assumption. The integrity of the outcome depends on the oracle's correctness and censorship-resistance. A compromised or malfunctioning oracle becomes a single point of failure for the entire fairness proof.

The cryptographic proof only verifies the specific algorithm was followed; it does not audit the full system implementation. Vulnerabilities can exist in:

• The frontend code that collects user input.
• The server-side logic before commitment.
• The verification tool itself. A provably fair system is only as strong as its weakest code audit.

For the service provider, being provably fair is a public verifiability feature, not a cryptoeconomic security guarantee. There is often no slashing mechanism or stake lost if a flaw is discovered. The primary deterrent is reputational damage, which may be insufficient against anonymous operators or short-term schemes.

The 'provable' aspect requires active verification by users. Most participants lack the technical skill to run the verification scripts, creating a security model where trust is placed in third-party auditors or community members. This shifts security from cryptographic certainty to social trust, diluting the core benefit for the average user.

A two-phase cryptographic protocol where a party first publishes a commitment (a hash) to a secret value, and later reveals the original value. This prevents outcome manipulation in systems like games or lotteries by binding a participant to a choice before the result is known. The scheme's integrity is guaranteed because the hash function is preimage-resistant.

A cryptographic function that produces a random output and a cryptographic proof that the output was correctly generated from a given input and secret key. Unlike a standard hash, a VRF allows anyone to verify the randomness was not manipulated, even by the secret key holder. It is a core component for generating on-chain randomness in a trust-minimized way.

A decentralized randomness beacon on Ethereum where participants collectively generate a random number by each submitting a number and having them combined. The final value is a hash of all contributions, making it unpredictable if at least one participant is honest. It exemplifies a cryptoeconomic approach to provable fairness, relying on incentives and game theory.

The initial source of randomness used to generate cryptographic keys and, by extension, fair outcomes. In provably fair systems, the client seed (from the user) and server seed (from the platform) are often combined. The critical requirement is that at least one seed remains secret and unpredictable until after the commitment phase to prevent bias.

A method by which one party (the prover) can prove to another (the verifier) that a statement is true without revealing any information beyond the validity of the statement. In advanced provably fair systems, ZKPs can be used to prove that a game's outcome was computed correctly according to the rules and random inputs, without revealing the inputs themselves, enhancing privacy alongside verifiability.

The process of executing verification logic directly on a blockchain via a smart contract. For a provably fair system, this means the commitment, the revealed data, and the verification algorithm are all recorded and executed on-chain. This provides the highest level of transparency and auditability, as the verification is performed by the decentralized network itself, not a trusted third party.