Provably Fair Mechanism Documentation

Publicado em 2026-04-02 · 11 min de leitura

Document Purpose

This document explains how the platform’s Provably Fair mechanism operates, why it enables users to verify that results are untampered, and how users can independently review historical draw records.

The core goal of this mechanism is not to predict future results, but to allow users to verify each draw process independently after the result is generated, confirming that:

Draw results are generated from pre-committed data
The platform cannot secretly modify results after the draw
The same rules apply to all users
Every draw record is recalculable and verifiable

1. Core Concepts

To understand the Provably Fair mechanism, familiarize yourself with the following key terms.

1. Seed

A data string used as input for a pseudorandom algorithm. Random results are not generated out of thin air; they are computed by fixed algorithms based on input parameters.

2. Server Seed

A random string generated by the server. It is not displayed to users in plaintext before the result is revealed; instead, it is first committed as a hash. The plaintext is only disclosed for verification after the seed is invalidated or rotated.

3. Client Seed

A user-participated seed. Users can usually view or modify it. It ensures the random process is not controlled unilaterally by the server, enhancing transparency and verifiability.

4. Salt

An additional string used to protect the Server Seed. It participates in hash calculations, making it nearly impossible for external parties to reverse-engineer the real Server Seed from the public hash.

5. Public Hash

A public commitment value calculated from the Server Seed and additional protection parameters. Users can view it before the draw to prove the platform did not replace the Server Seed after the draw. In short: The platform first publishes a "commitment", then discloses the "original text", and users verify consistency between the two.

6. Nonce

A sequential number indicating how many times the same Server Seed has been used. The Nonce increments by 1 for each draw, ensuring different results even if the Server Seed and Client Seed remain unchanged.

7. Roll

A numerical value computed by the algorithm using the Server Seed, Client Seed, and Nonce. It falls within a fixed range and is then mapped to a specific outcome in the prize pool.

8. Odds Range

A set of numerical ranges corresponding to each outcome in the prize pool. The prize or result is determined by which range the Roll value falls into.

2. Why Provably Fair Is Necessary

The biggest trust issue in online random systems is: Users only see the result, not how the result is generated.

If the platform can arbitrarily adjust probabilities, set different outcomes for specific users, or modify records after the draw, users will almost never detect it.

The value of the Provably Fair mechanism lies in:

Making key input data verifiable
Making random results recalculable
Making historical results traceable
Preventing the platform from tampering after the fact without leaving traces

It cannot predict future results in advance, but allows users to check whether each result complies with the rules after the draw.

3. Overall Working Principle

A verifiable random process involves three types of inputs:

Server Seed
Client Seed
Nonce

And two key outputs:

Public Hash
Roll

The full process is summarized as:

The platform generates a new Server Seed
A hash commitment is created for the seed, and the Public Hash is shown to users
The user initiates a draw
The system generates a random result using Server Seed + Client Seed + Nonce
The result is mapped to the prize pool range to determine the final outcome
After the Server Seed is rotated or invalidated, the platform discloses the old seed
Users can recalculate and verify results using public historical data

4. Roles of the Three Input Parameters

1. Server Seed

Generated by the platform. It is a critical source of randomness but is not disclosed in plaintext before the draw (otherwise users could predict future results). Thus, the platform only shows its corresponding Public Hash before the draw, not the original seed.

2. Client Seed

Provided or modified by the user. It enhances transparency and prevents unilateral control by the server. Even if the platform holds the Server Seed, user control over the Client Seed strengthens the verifiability and credibility of the entire mechanism.

3. Nonce

It represents the number of uses under the current Server Seed. Its functions:

Avoid replacing the Server Seed for every draw
Ensure different results for multiple draws with identical seeds
Provide a clear sequence for historical verification

5. Why the Server Seed Cannot Be Disclosed in Advance

If users know the Server Seed before the draw and it remains valid, they could theoretically deduce future results using the algorithm and other inputs. This would make the random process predictable and undermine fairness.

The correct approach is:

First publish its hash commitment
Disclose the original value after the seed cycle ends
Let users verify the commitment afterward

This is the purpose of the Public Hash.

6. Role of the Public Hash

The Public Hash is the most important commitment proof in the Provably Fair mechanism.

What Problem Does It Solve?

The platform cannot disclose the Server Seed before the draw, but users need confirmation that the seed was not replaced mid-process. The platform first displays the hash of the Server Seed.

Hash functions have three key properties:

Identical inputs always produce identical outputs
It is extremely difficult to reverse-engineer input from output
A tiny input change causes a drastic output change

When the platform later discloses the original Server Seed, users can recalculate the hash and compare:

A match confirms the platform used the same seed throughout
A mismatch indicates tampering

Simple Analogy

Before draw: The platform submits an "untamperable commitment"
After draw: The platform discloses the original data
User verification: Check if the commitment matches the original data

7. How the Roll (Random Result) Is Generated

Random results are not "drawn directly"; they are computed via cryptographic hash algorithms following fixed rules.

Basic Logic

The system combines:

Server Seed
Client Seed
Nonce

It then computes a long hexadecimal string via hashing/HMAC, extracts a portion, converts it to a decimal integer, and maps it to the target range to get the final Roll.

Example Process

Construct an input string, e.g.:

ClientSeed-Nonce

Perform HMAC/hash operations on the input per fixed rules to get a hexadecimal result
Extract the first N digits (e.g., first 15 digits)
Convert the hexadecimal value to a decimal integer
Take the modulus of the maximum roll range, e.g.:

roll = (outcome % MaxRollNumber) + 1

Get the final value within the fixed range

For a maximum range of 100000, the Roll falls within:

[1, 100000]

The final prize or draw result is determined by which Odds Range the Roll falls into.

8. How Results Are Mapped to the Prize Pool

The platform predefines numerical ranges for each outcome. Example:

Outcome A: 1 - 50000
Outcome B: 50001 - 80000
Outcome C: 80001 - 95000
Outcome D: 95001 - 100000

If the computed Roll is 87342, it matches the corresponding range and outcome.

Thus, outcomes are determined by which range the Roll hits, not subjective awarding.

This is why:

Odds Ranges must be public
Roll values must be recalculable
Every draw record must be traceable

9. How Users Verify a Historical Result

A complete Provably Fair verification follows these steps:

Step 1: Obtain Key Parameters for the Draw

Including:

Server Seed (plaintext disclosed after the draw)
Client Seed
Nonce
Public Hash
Roll
Corresponding prize pool Odds Range

Step 2: Verify the Public Hash

Recalculate the hash using the platform’s disclosed Server Seed and agreed rules, and confirm it matches the Public Hash shown before the draw. A match confirms the Server Seed was pre-committed and not replaced after the draw.

Step 3: Recalculate the Roll

Regenerate the Roll using:

Server Seed
Client Seed
Nonce per the public algorithm.

Step 4: Check Outcome Mapping

Compare the recalculated Roll to the historical Odds Range to confirm it matches the recorded draw result.

If:

Hashes match
Rolls match
Range mapping matches

the draw record passes Provably Fair verification.

10. Why This Mechanism Is Trustworthy

The credibility of the Provably Fair mechanism rests on three foundations:

1. Pre-Commitment

The platform must publish the hash commitment before the draw, not retroactively.

2. Recalculability

Historical draw records are not black-box results; users can recalculate them independently using public parameters.

3. Cryptographic One-Wayness

The Public Hash proves the platform "pre-committed to a seed" without revealing the seed itself, balancing:

Unpredictability
Verifiability

11. Critical Boundary: Provably Fair ≠ Absolute Risk-Free

The Provably Fair mechanism is highly valuable but does not make the entire system "perfectly flawless" at every level.

More precisely, it guarantees:

Verifiable result generation process
Difficulty for the platform to tamper after the draw without detection

It cannot independently resolve all business, product, or presentation-layer issues. The mechanism’s boundaries must be clearly stated when introducing it.

12. Theoretical Potential Risks & Considerations

Below are key risks and considerations for this mechanism in theory and engineering practice:

1. Server Seed Generation

If the platform generates non-genuinely random Server Seeds (e.g., selectively picking "favorable" seeds), the mechanism may show bias in early draws despite formal compliance. Fairness depends on both the verification mechanism and truly random Server Seed generation.

2. Historical Data Presentation

If all historical data is stored only on the platform’s system with no external records, there is a theoretical risk of "retroactively modifying displayed data". Factors affecting credibility:

Whether users can view complete history
Whether historical data is exportable
Whether cross-verification is allowed

3. Consistent Probability Presentation

Even with verifiable randomness, ensure:

The same Odds Ranges apply to all users
Displayed ranges match the actual ranges used
No differential rules based on user identity, channel, or tags

Technical "verifiable randomness" does not automatically equal product-level "equal treatment for all".

4. High User Learning Curve

The mechanism involves:

Hashing
HMAC
Seeds
Nonce
Hexadecimal-decimal conversion
Odds Range mapping

These concepts have a learning curve for average users. The platform should provide:

Clear result-page explanations
One-click copy for verification parameters
Visual verification workflows
Example calculation steps

Otherwise, users may not understand or use the mechanism.

5. Public Hash Does Not Enable Future Prediction

The Public Hash is designed for "commitment verification", not "future prediction". As long as the platform does not disclose the Server Seed in advance and uses secure hashing/salting, users can only verify history after the draw, not predict future results.

6. Hash Security Depends on Correct Implementation

The mechanism’s security relies on properly implemented cryptographic algorithms and engineering. Flawed implementation, poor seed management, or defective rotation policies weaken credibility.

13. Product Requirements for Full Credibility

Beyond the algorithm, the product should include these features:

1. Clear Display of Active Public Hash

Let users view the current commitment before the draw.

2. Historical Seed & Draw Record Access

Allow users to review usage of every seed cycle.

3. Complete Verification Parameters

Include:

Server Seed
Client Seed
Nonce
Public Hash
Roll
Outcome Range

4. Visual Verification Tools or Sample Code

Lower the barrier for user understanding and verification.

5. Public Outcome Mapping Rules

Let users confirm how Roll values map to final outcomes.

6. Clear Seed Rotation Policy

Examples:

Server Seed rotation after a fixed number of uses
User-initiated Client Seed refresh
Public verification of historical seeds after rotation

14. FAQ

1. What Is a Pseudorandom Function?

Most "randomness" in computers is pseudorandom. It is not uncaused; instead:

Given fixed input parameters
Processed by a fixed algorithm
It generates seemingly random, well-distributed results

This is why historical results are recalculable: Identical inputs + identical algorithm = identical output.

2. Why Does Changing Only the Nonce Produce New Random Results?

Cryptographic hash functions have a strong avalanche effect: Even a tiny input change causes a massive output change.

Example:

seed-example-1
seed-example-2

These differ by only one character but produce completely different hashes. Thus, incrementing the Nonce generates new, unpredictable Rolls even with fixed Server and Client Seeds.

3. Can Users Predict Future Results in Advance?

No. This holds if the platform does not disclose the Server Seed in plaintext early and uses proper seed management and hash commitments. Users only see the Public Hash before the draw (to confirm pre-commitment) and can recalculate/verify results only after the draw using public historical data.

4. Can Users Modify the Client Seed?

Usually yes. Allowing user modification is key to transparency and engagement, proving the random process is not server-controlled unilaterally.

5. Does Provably Fair Prove Absolute Fairness at All Levels?

No. It primarily verifies:

Whether a result was generated from pre-committed inputs
Whether historical results are independently recalculable
Whether the platform modified key inputs after the draw

It does not address:

Reasonable prize pool configuration
Complete probability disclosure
Consistent rules for all users
Permanent historical data retention

These require product design, auditing, and transparency.

15. Summary

The essence of the Provably Fair mechanism is upgrading from "the platform claims fairness" to "users can verify fairness independently".

It is implemented by:

Using Public Hash to pre-commit the Server Seed
Generating random results with Server Seed + Client Seed + Nonce
Determining outcomes via fixed range mapping rules
Disclosing historical parameters after seed rotation for independent recalculation

Users cannot predict future results but can verify after the draw:

Whether the platform pre-committed inputs
Whether inputs were tampered with after the draw
Whether random results follow the rules
Whether final outcomes match Roll mapping

A mature Provably Fair system includes more than just algorithms:

Complete parameter display
Clear historical records
Explicit rotation rules
Low-barrier verification
Consistent, public outcome mapping

Only when all these elements work together can the mechanism be understood, used, and trusted by users.