What Makes a Web3 Lottery Verifiably Fair?

A lottery can use strong randomness and still exclude valid entries. It can record every entry and still change the winner rule after seeing the random value.

It can select the right winner while the advertised prize remains only a promise.

This is why “on-chain” and “fair” are not synonyms. A blockchain can preserve data that was produced by a weak or manipulated process.

A useful fairness review asks which decisions were fixed before participation, who could still change them, and which evidence allows another person to reproduce the result.

Rules and deadline

Eligibility, entry price, ticket limits, deadline, number of winners, and prize terms should be available before participation. Any permitted changes and cancellation conditions should also be explicit.

Participant set

The system needs a clear rule for accepting entries and a defined point when the set closes. After closure, an operator should not be able to silently add, remove, or reorder entries that affect the result.

Prize terms and custody

Participants should know what the prize is and who controls it. A contract-held asset, an organizer-held asset, and a future promise require different evidence.

A recorded winner proves who was selected. It does not by itself prove that an external prize exists or will be delivered.

Randomness request

The request should be bound to the correct event and participant snapshot. The random output should be unpredictable before generation and verifiable afterward.

Winner-selection rule

The method that maps the random output to a ticket or participant should be fixed before the output is known.

Scaling, retries, and invalid values need defined handling so that an operator cannot keep only a favorable result.

Result and fulfillment evidence

The published record should let a reviewer connect the rules, entries, random response, mapping, and winner.

Prize fulfillment should be shown separately so that selection and delivery are not presented as the same proof.

1. Publish the rules, deadline, prize terms, and winner-selection method.
2. Accept entries according to those rules.
3. Close participation and preserve the final participant set.
4. Request randomness that is bound to the correct event.
5. Verify the response instead of trusting a number supplied by an operator.
6. Apply the predetermined mapping rule.
7. Publish the result and report prize fulfillment as a separate state.

This sequence does not require every system to use the same architecture. It identifies the evidence that must remain connected from the first entry to the final result.

A VRF produces an output together with a proof that can be checked against a public key and defined input. RFC 9381 describes the verification and uniqueness properties of VRF constructions.

The UK Gambling Commission's RTS 7 is not a universal Web3 rule.

It is a useful external benchmark because it requires unpredictable outcomes, rules available before play, and a consistent mapping from random inputs to outcomes.

A valid VRF proof does not show that the participant set was correct, that the prize exists, or that the mapping rule was chosen fairly. Those claims require separate evidence.

Warning signs include:

• a server selects the winner and publishes only the final address;
• entries can be edited after the deadline;
• the operator can discard a random response and request another;
• the mapping rule is missing or can change after the response;
• the prize is described without explaining who controls it;
• administrator powers can change critical data without a visible trace;
• the interface shows a final result without the evidence needed to reproduce it.

None of these failures is repaired merely by storing the final value in a smart contract.

Before treating a lottery as verifiably fair, ask:

• Were the rules and deadline available before entry?
• Can I determine which entries were included?
• Was the participant set closed before randomness was requested?
• Is the prize identified, and is its custody clear?
• Is the random response tied to the correct event?
• Can the response be verified independently?
• Was the winner-selection rule fixed in advance?
• Can anyone discard or rerun an unfavorable result?
• Are winner selection and prize delivery reported separately?

An unclear answer does not always prove fraud. It does show where the fairness claim still depends on trust.

ElyxS uses Supra dVRF for draw randomness. Before calculating the result, the smart contract verifies the response and binds it to the expected request, draw, and round.

This illustrates one part of the broader model: a random response is rejected unless it matches the recorded request. It does not make the VRF proof evidence for every other claim about participation or prizes.

See Verify Draw Results for the user-facing evidence path and Smart Contracts for the conceptual contract model.

• UK Gambling Commission: RTS 7 — Generation of random outcomes — rules before play, unpredictability, mapping, and result presentation.
• RFC 9381: Verifiable Random Functions — VRF algorithms and security properties.
• Solidity security considerations — the difficulty of randomness when block builders may influence the process.
• Supra dVRF overview — the general model of verifiable randomness used in the ElyxS example.