Did you know? A lottery can run on a blockchain, publish every ticket transaction and still pick a winner unfairly if the supposedly random number can be predicted or influenced. A transparent ledger is useful evidence, but transparent bookkeeping does not automatically create an unpredictable draw.
Imagine a fictional school science club awarding one telescope poster among ten enrolled students. Alicia proposes selecting the winner from the final digit of a public clock. Kai Kai notices the organiser can choose when to stop the clock. Tricia points out that whoever controls the stopping moment can influence the result even when everyone can later see exactly which digit was recorded.
That is the core challenge of randomness in smart contracts: blockchain execution aims to be deterministic so independent participants can agree on the same result, while a fair draw needs an unpredictable selection process that relevant participants cannot manipulate.
Quick answer: a blockchain-based random draw needs more than a publicly visible number. It needs a defined participant set, an unpredictable or appropriately unbiased selection process, verifiable evidence of how the number was generated and safeguards against parties choosing, withholding or rerunning an unfavourable result. Verifiable random functions (VRFs), commit-reveal designs and other protocols address different parts of this problem, with distinct security and availability assumptions.
This article explains how blockchain technology works using a harmless classroom raffle. It is not a guide to operating a gambling service or a promise of financially fair games. Our aim is to show what a cryptographic proof can and cannot establish about randomness, rules and real-world outcomes.
Your quick reading route
- A visible result is not necessarily a fair result
- Why deterministic smart contracts need outside randomness
- Why a timestamp is not a safe secret draw
- Why an old block hash is not a random secret
- What a verifiable random function helps prove
- Why a VRF proof does not certify the whole lottery
- Commit-reveal: a different route to unpredictability
- Frequently asked questions
- Primary sources and further learning
A visible result is not necessarily a fair result
Suppose the science club promises to select a winner by choosing one number between one and ten. The organiser writes the number seven on a public noticeboard. Everyone can read the result and verify that seven belongs to the permitted range.
But who chose seven? Could the organiser have selected a different number? Was the participant list fixed before the selection? Can somebody arrange for a favourite student to be number seven? A fully visible final number does not answer those questions.
Now suppose the organiser publishes a hash of the number before revealing it. That can make a later change more detectable under appropriate commitment rules. Yet the organiser may have chosen a biased number in the first place or may refuse to reveal it after seeing an unfavourable outcome.
The question of fairness therefore involves how unpredictability was generated, what opportunities for manipulation existed, and whether the result was actually applied under the agreed rules.
A blockchain can be valuable for recording commitments, accepted calls and prize allocation. It cannot make an arbitrary organiser-supplied number fair merely by recording it.
For foundational technical context, see Ethereum Oracles, which explains why verifiable randomness is a distinct challenge in deterministic smart-contract systems.
Why deterministic smart contracts need outside randomness
A blockchain’s execution rules aim to let honest validating participants reproduce agreed state transitions from accepted data. If a contract used an ordinary computer’s local clock or operating-system random generator differently on each validator, they could disagree about the result.
Determinism is important for consensus. The same relevant inputs and accepted state should produce the same protocol-defined result. That property is helpful for accounting but makes “choose a secret unpredictable number out of nowhere” more complicated.
A smart contract can compute a number from data available to everyone. But if the data are already known or can be influenced by parties who benefit from the result, the generated number may not be appropriate for a fair draw.
A real randomness design must decide which source has the required unpredictability, how the source is authenticated and how the contract confirms that the value corresponds to the intended draw.
The Ethereum Oracle documentation describes this problem and approaches to verifiable randomness, including systems that produce a random value together with proof of its derivation.
The essential lesson is that determinism helps everyone agree on what happened; unpredictability helps prevent participants from knowing or influencing what will happen before the draw. A trustworthy raffle needs both properties in the right places.
Why a timestamp is not a safe secret draw
A classroom might choose a winner from the last digit of the time recorded on a wall clock. The rule is simple, but a person who can influence the moment of selection might affect the number. Even a small ability to delay the draw creates a potential bias.
A blockchain block timestamp is useful within its protocol rules, but it was not designed to be an independent secret random-number source for every application. Block production and timestamp rules may allow limited influence or create predictable relationships.
For a high-stakes game, drawing a winner directly from an easily anticipated or influenceable block value can give some participants an unfair advantage. The exact risk depends on the chain, timing and selection design.
This does not mean every use of timestamps is malicious. Time-based eligibility and deadlines are legitimate application features when designed appropriately. The mistake is treating a time value as inherently unpredictable and beyond all interested parties’ influence.
OWASP’s Smart Contract Weak Randomness guidance warns against relying on accessible or manipulable block-derived values as a secure source of randomness.
The useful distinction is easy: a timestamp says something about when the network recorded a block; it does not automatically provide an unbiased secret number for a prize draw.
Why an old block hash is not a random secret
A hash can look like a chaotic string of hexadecimal characters. That visual complexity may create the impression that it is always a strong source of randomness. But randomness quality depends on how the underlying data are generated and when participants can predict or influence them.
If a smart contract uses a block hash that is already known when someone enters a draw, the relevant digits may be predictable. If a block producer has some ability to influence candidate content, ordering or publication, its choices can affect outcomes under the specific model.
It would be wrong to say that every blockchain hash can always be manipulated freely. Consensus constraints and economics matter. The point is that a cryptographic hash is not itself a proof that its input was unbiased.
A secure application should begin with the threat model: Who may gain from influencing the result? Which values can they observe before committing? Can they choose when to submit, withhold or discard relevant data?
For classroom use, imagine rolling a die behind a screen, then publicly hashing the reported result. The hash can protect against later alteration of the recorded report but cannot establish that the die roll was fair or even that a die was used.
The stronger question is how the unpredictable source was created and verified, not whether its final output looks sufficiently complicated.
What a verifiable random function helps prove
A verifiable random function, or VRF, combines pseudorandom output with cryptographic evidence that a value was generated according to a defined procedure under a particular key and input. A verifier can check the proof under the system’s rules.
This can be useful for smart contracts because the random output can be supplied from an appropriately designed external component while the contract verifies its accompanying evidence before relying on it.
Chainlink’s VRF documentation explains one widely used implementation. It describes random outputs and proofs that are verified on-chain before use by the consuming application.
The important claim is narrower than “every lottery using a VRF is fair.” The proof can establish that the output corresponds to the defined cryptographic process. It cannot independently prove that the organiser compiled a fair participant list, honestly described prize rights or did not deliberately abandon an inconvenient draw.
The documentation also discusses security assumptions, including the limitations of the participating blockchain’s settlement and the possibility of bias in extraordinary circumstances involving compromised secret material and block production.
The useful concept is that verifiable randomness makes a specific numerical generation step checkable, while the surrounding game still needs correct rules, honest authority and reliable fulfilment.
Why a VRF proof does not certify the whole lottery
Suppose the fictional school has ten eligible students and uses a properly verified random number to choose an index. The number-generation step may be strong, but what if the organiser secretly includes the same student three times in the participant list?
A cryptographic proof of a random index would not fix a biased participant list. The selected number may be unpredictable, while some students have more entries than the rules promised.
Another problem is a manipulated deadline. If the organiser closes entries early after seeing which students have joined, the randomness could remain cryptographically valid while the overall process becomes unfair.
Prize distribution matters too. A verifiable draw does not prove that the organiser owns the telescope poster, that it will deliver it or that the winner is legally eligible to receive it. Those are outside facts.
A strong system therefore links the random output to a fixed, publicly understandable input population and a documented selection formula. It also includes operational controls ensuring that the result is used according to the published rules.
The learning habit is to ask what exactly was proved? A VRF proof answers a numerical-generation question; it is not a universal certificate of honesty for every surrounding business decision.
Commit-reveal: a different route to unpredictability
A commit-reveal design lets participants commit to secret values before revealing them. A cryptographic hash can serve as a commitment when the scheme is constructed correctly and includes suitable domain separation or other protections.
Imagine Alicia and Kai Kai each choose a secret classroom number and publish a properly designed commitment to it. They later reveal their original values. The school verifies that the reveals match the earlier commitments and combines them under its agreed rule to select a result.
This can reduce some forms of advance prediction, because participants commit before seeing the others’ revealed values. But the exact security depends on the sequence, who may participate and how values are combined.
The system still needs rules for participants who refuse to reveal, commit to weak predictable values or attempt to influence the ordering of the process. A cryptographic commitment can prevent changing one value after the fact without guaranteeing that everyone will cooperate.
The eduKateSG guide to Random Selection on a Blockchain examines commitments, proofs and the option to withhold. It is a useful technical follow-on to this reader’s explanation.
For beginners, the key distinction is that commit-reveal protects specific advance commitments, while VRF designs offer a different proof and participant model. Neither is a magic replacement for complete selection rules.
Why withholding a reveal can bias a result
Suppose Alice and Tricia commit secret numbers for the class raffle, then both must reveal them. If Tricia can see Alice’s reveal before deciding whether to publish her own, she may be able to influence whether the final outcome is produced.
Even without changing her committed number, Tricia might refuse to reveal when she dislikes the result. If the organiser responds by cancelling and restarting until a preferred participant wins, the process is biased.
This is sometimes described as a last-revealer or selective-abort problem. It illustrates why a cryptographic proof of a committed value is not enough when one actor can choose whether the draw proceeds.
A secure design needs a defined policy for missing reveals, deadlines, incentives, aborts or default behaviour. The correct policy depends on the game’s fairness requirement and the participants’ trust assumptions.
In a harmless classroom experiment, place students’ committed numbers in sealed envelopes and reveal them in sequence. Ask whether the final student could benefit by withholding the envelope. The question reveals the problem without requiring a live protocol.
The central lesson is the ability to refuse publication can sometimes create influence even when changing the committed value is cryptographically difficult.
Who chooses when randomness is requested?
Timing can create another manipulation opportunity. A system might obtain a new random number when somebody presses a button, when a fixed event occurs or when an authorised operator asks an oracle to fulfil a request.
If an interested participant can choose between several eligible moments after seeing useful information, they may influence which randomness input is used. The exact risk depends on what is predictable and which request-selection powers exist.
For example, a club organiser might claim that the raffle is based on a secret random source but retain permission to repeatedly request numbers until an acceptable winner appears. Even if every generated number has a valid VRF proof, selecting among the outputs can bias the published result.
A trustworthy system fixes the selection trigger or constrains requests under rules that prevent undisclosed cherry-picking. A participant should know how many draws are allowed and what happens if a request fails or times out.
This is not an argument that all repeat requests are improper. Legitimate systems may need retries after service outages. The challenge is to define retry conditions before learning whether the result is favourable.
The important question for readers is who controls the request, which outcomes can be rejected, and how is that power constrained? Those governance details are separate from the cryptographic quality of one random output.
Why waiting for confirmations can matter
Some randomness protocols derive security assumptions from future chain state and the accepted history around a request. If the chain’s recent blocks can reorganise, the context of a request may change before it receives stronger settlement confidence.
A randomness provider can require an appropriate confirmation depth or finality-related condition before fulfilling a request. The exact choice depends on the network and mechanism, and a larger number is not a universal guarantee against every attack.
Chainlink’s VRF security considerations discuss confirmation requirements, ordering and the handling of randomness requests under its model. They are provider-specific guidance and should be read in context rather than applied blindly to all chains.
For the science club, think of waiting until the official participant register is approved before drawing a winner. Drawing from a provisional register that can later change creates a different outcome risk from drawing after the agreed cut-off.
A lottery can therefore need both an unpredictable random source and a sufficiently settled record of which participants are eligible.
For the general consensus issue, see Why a Confirmed Transaction Can Be Reorganised. Finality is part of the evidence chain, not an ornamental badge.
How a random number is mapped to a winner
A random value on its own does not name the winning student. The application needs a mapping from the numerical output to a clearly defined participant list.
Suppose the school has ten eligible entries numbered zero through nine. A simple conceptual rule could choose a result based on a uniformly sampled integer in that range. The fairness of the procedure depends on whether each eligible entry has the intended chance and on how the random output is converted into the final index.
Technical designs can introduce bias when mapping an output from one numerical range to another, especially when the ranges do not divide evenly and the implementation applies a naive remainder operation without considering distribution. The significance depends on the output range and exact method.
For a school lesson, imagine using a twelve-sided die to choose among ten students and simply ignoring results eleven and twelve. If the rule is defined and applied appropriately, the students’ probability can be calculated. If the organiser instead maps extra results to the first two students, those students receive an unintended advantage.
The mapping is therefore part of the published rule, not a cosmetic detail. A perfect VRF proof over one number does not independently prove that the mapping to entrants is fair.
A transparent programme identifies the eligible entries, numbering, drawing rule and result, allowing a reader to reconstruct the selection from the accepted data.
A correct random value can select from an incorrect list
A participant register might contain duplicates, ineligible entrants, outdated ticket ownership or missing entries. Those issues change the effective odds even if the random-number source is excellent.
Imagine the class announces one entry per student but accidentally lists Alicia twice and leaves Kai Kai off. A uniformly chosen index now gives Alicia more chances and Kai Kai none. The cryptographic draw can be correct while the event violates its stated rules.
Eligibility and identity also need separate checks. One blockchain address is not necessarily one human being; one person may control several addresses, and several people may share a smart-account treasury. A promise of “one ticket per person” cannot automatically be implemented by counting unique addresses.
A responsible design defines the enrolment process, how duplicates are treated, how errors can be challenged and the exact cut-off after which the eligible list is fixed. It should also protect personal data rather than publishing students’ full names or sensitive details unnecessarily.
For the related identity distinction, see Why a Blockchain Address Is Not a Verified Identity.
The strongest fair-draw claim is not just “the random number was correct.” It is “the eligible list was established under fair rules and the agreed unpredictable value was applied to that exact list without discretionary changes.”
An unavailable randomness service needs an honest fallback
What if the randomness provider does not deliver a result? The service could be offline, unable to reach the chain or temporarily unable to meet its protocol requirements. A lottery design must explain what happens rather than pretending failure is impossible.
A poor fallback might allow the organiser to choose an arbitrary number privately, making the “verifiable” promise meaningless at the moment of stress. Another poor design might let the organiser restart the draw as many times as desired without notice.
A better process defines its fallback and cancellation rules beforehand. It should state when a request is considered failed, who may initiate a retry and how the retry is recorded without granting unfair choice over the outcome.
The underlying application might also hold valuable user funds. A randomness failure should not automatically trap them without a defined recovery or dispute process. These are design and governance issues beyond the mathematical random generator.
The classroom example is simple: the electronic drawing machine breaks. The organisers should follow the published backup procedure, not quietly select their favourite student.
The important distinction is cryptographic quality when a result is generated versus reliable and fair operation when a result is delayed or unavailable. A well-designed system must address both.
Why an auditor cannot guarantee a fair result forever
A security auditor can review the random-number integration, access controls, participant mapping and some manipulation risks under a defined code and system scope. Such an assessment can be valuable evidence.
But an audit of one version does not automatically guarantee that future code, oracle subscriptions, operator keys, draw timing and participant records remain unchanged or honest. A valid proof is also not a substitute for auditing the logic that uses it.
Imagine the school initially uses a fair selection rule reviewed by independent teachers. Next term, an administrator changes the participant-index mapping. The original review remains genuine as a historical document but may not cover the new arrangement.
External fairness concerns also remain. A promised physical prize might not be delivered. An organiser may misrepresent which students are eligible. A code audit cannot independently validate every real-world fact.
For a related security principle, read Why a Smart Contract Audit Is Not a Safety Guarantee.
The correct claim is proportionate: “The reviewed system verifies randomness and applies the specified rule under documented assumptions.” Calling every possible outcome guaranteed fair would overstate that evidence.
A fictional ten-student science-club draw
The class has ten eligible students, recorded as entries 0–9 in a register approved before the closing time. A contract requests a random value from a system that produces a checkable proof under its rules.
Assume the resulting value is accepted, and the contract applies a clearly defined mapping that selects entry 6. Tricia checks that the participant list matches the committed version and confirms that entry 6 belongs to a particular student.
Kai Kai asks whether the VRF proof also proves the student’s identity. No. It proves something about the numerical generation step. The school still needs to verify the registration list and the identity-to-entry mapping.
Alicia asks whether the organiser could discard an inconvenient result and draw again. The class consults its rules: only a documented technical failure permits a retry, and every request must be logged. The answer depends on what the rules and code actually enforce.
Next imagine the selected student is absent on prize day. Delivering the poster or determining eligibility under the school’s terms becomes a real-world task separate from the verified draw.
This paper example demonstrates a complete chain of claims: entry eligibility, fixed list, random value, proof verification, deterministic winner mapping and prize fulfilment. The blockchain can help with some stages without replacing all the others.
A seven-question fairness checklist
Which entrants? Identify the complete eligible list, entry weights and cut-off conditions. A perfect random value cannot repair an unfair population.
Which unpredictable source? Distinguish a predictable timestamp, a block-derived value, a commitment scheme and a VRF with the intended cryptographic properties.
What does the proof establish? Verify whether it concerns the generated number, an authenticated source or another narrow statement—not every detail of the event.
Who controls timing and retry? A valid random output can still be cherry-picked if one actor may request many draws and publish only a favourite result.
What if someone withholds data? Commit-reveal and other designs need defined procedures for missing reveals, unavailable providers and aborts.
How is the winner computed? Check the mapping between random value, participant indices and any relevant probability weights. The result must follow the published rule.
What happens after selection? A blockchain event does not prove the winner’s legal identity or the physical delivery of a prize. Verify fulfilment separately.
This checklist is for understanding fairness in digital systems and classroom demonstrations. It is not a substitute for legal requirements governing lotteries or gambling in any jurisdiction.
Seven claims that need correcting
“The draw is on-chain, so it must be fair.” A public ledger records defined actions but does not automatically make selection inputs unpredictable.
“A random-looking block hash is always a secure random number.” The security depends on when the data are known and who can influence the block or request.
“A VRF proof certifies the whole event.” It verifies a defined cryptographic generation property, not participant eligibility or prize delivery.
“A correct hash commitment proves everyone will reveal.” A participant may refuse to reveal after committing. The protocol must address withholding or aborts.
“Every address means one genuine entrant.” Accounts and people are not universally one-to-one. Identity and eligibility require appropriate checks.
“A uniform random integer always gives a fair allocation.” Mapping and list construction can introduce bias if the rules are poorly designed or applied.
“A failed request can be retried secretly without affecting fairness.” Repeated attempts and selective publication can introduce manipulation when the protocol permits cherry-picking.
The accurate alternative is to examine the complete chain from eligibility through unpredictable selection to enforced outcome, rather than relying on one colourful “verified random” badge.
Frequently asked questions
Why do blockchain lotteries need random numbers?
They need unpredictable selection when winners or outcomes should not be chosen or influenced by interested participants. The network’s deterministic execution does not automatically generate that property.
Why isn’t a block timestamp a safe randomness source?
A timestamp is public protocol data subject to defined timing and production constraints. It is not inherently secret or guaranteed beyond the influence of interested participants.
What is a verifiable random function?
A VRF produces an output accompanied by cryptographic evidence that it was derived according to a defined function and key. A verifier can check the proof under the scheme’s assumptions.
Does a Chainlink VRF proof guarantee a lottery is fair?
It can establish specified properties of the random value generated through that system. It does not prove the entry list, prize rules, organiser conduct or physical fulfilment are fair.
What is commit-reveal?
It is a design in which participants first commit to hidden values and later reveal them for verification and use. Its fairness depends on how commitments, reveals and missing participation are handled.
Can someone manipulate a draw by refusing to reveal?
Under some commit-reveal designs, a participant may influence whether the draw completes by withholding a reveal. Robust rules must address this possibility.
Why does the eligible participant list matter?
An unbiased selection among incorrect entries can still yield an unfair event. The list and any weights must match the stated eligibility rules.
Does one wallet address equal one person?
No. One person can control many addresses and multiple people can share a smart account. Real-world eligibility cannot always be inferred from addresses.
Can a lottery use several random draws?
It can under rules defined in advance, but allowing an organiser to retry until a preferred result appears can bias the outcome.
What happens when a randomness provider is offline?
The application must follow its documented retry, fallback or cancellation rules. A delayed provider response does not justify arbitrary secret selection.
Is a smart-contract audit proof of future fairness?
No. Audits are scoped to specified code, assumptions and versions. Operational governance, eligibility and delivery remain relevant.
What should students remember?
Fair selection needs a trustworthy participant set, appropriately unpredictable randomness, an unbiased published mapping and no hidden opportunity to choose an advantageous result.
Primary sources and further learning
Ethereum’s Oracles documentation explains why deterministic contracts require external or specialised randomness sources. Chainlink VRF describes a verifiable random-function implementation and its proof-based process. OWASP Weak Randomness guidance warns that predictable or influenceable block data are inappropriate for secure randomness. These references describe technologies and assumptions, not universal certification of any lottery.
For deeper eduKateSG lessons, continue to Random Selection on a Blockchain: Commitments, Proofs and the Option to Withhold, Why an Oracle Can Deliver Incorrect Data, Why a Confirmed Transaction Can Be Reorganised and Why a Merkle Proof Cannot Prove the Original Claim Is True.
The conclusion is simple: a verifiably random number is an important ingredient of a fair draw, but fair rules, eligible entrants and accountable fulfilment remain separate requirements. Understanding that boundary is useful whether you are learning blockchain or evaluating any automated decision system.