Wheel of fortune on blockchain: where draw fairness breaks
A blockchain wheel of fortune breaks not on the animation of sectors, but on the random number generator.
As long as the outcome is calculated by a server-side generator with a predictable seed, the operator knows the result before the start and can rig it for the desired participant — knowing the order of entries or the moment a transaction is sent.
From the outside, this is indistinguishable from an honest spin: the network keeps a record of the payout, but not of how the winner was determined. There is no verifiable trace — meaning the fairness of the draw rests on the operator's reputation, not on code.
The second typical failure is the lack of binding a ticket to a specific prize draw. If the result is not recorded on-chain together with the hash of the input data and the round number, a participant cannot reconstruct whether their ticket took part.
Disputed payouts are then resolved via correspondence and screenshots, and every major win turns into a wave of requests.
The third failure is manual payout. When funds are released only after a manager's confirmation, the outcome depends on business hours and the integrity of a specific person, rather than on contract terms. The peak of requests falls exactly on large wins — when the cost of an error is highest.
We examine how this is closed: the verifiable randomness oracle Chainlink VRF returns a number together with a cryptographic proof, the contract verifies it and only then records the winner and initiates the payout.
What a provably fair prize draw provides
A closed server-side random number generator decides the draw outcome, but it cannot be verified from the outside.
A streak of several losses in a row is immediately read as rigging, and there is nothing to settle a dispute with facts — all that remains is to assure with words and lose players' trust.
Verifiable randomness works differently. The contract requests a number from the Chainlink VRF oracle and receives it together with a cryptographic proof, which is verified on-chain before the prize is issued.
Using the request hash, the player reproduces the same sequence, so the result depends neither on the administrator nor on the moment the button is pressed.
Transparency of results has a measurable effect. The share of disputed requests drops: the player sees the proof themselves and does not go to support. A draw audit comes down to exporting events from a public journal — without manual logs and table reconciliation.
The rules are recorded in the contract, so they cannot be changed unnoticed in the middle of a round.
The question "prove that it used to calculate the same way" is removed separately: past rounds remain in the journal together with proofs, and the history is verifiable at any moment.
For the owner, this is players' trust that rests on code, not promises, and a clear procedure for handling claims.
Methods of generating randomness on blockchain: comparison
A draw must be unpredictable and at the same time verifiable: a participant wants to make sure the outcome was not rigged either at the start or after the bets are revealed.
In practice, the choice comes down to three schemes — an external verifiable randomness oracle, a server-side generator, and a hybrid with result publication. Each has honest limitations, and they determine exactly what you can show the player.
| Option | When it fits | Limitations |
|---|---|---|
| External randomness oracle (Chainlink VRF) | Public rounds with prizes where independent audit of the outcome is needed | Confirmation delay: the value arrives after several blocks, instant display of the spin is impossible |
| Pseudorandomness on the server | Private campaigns, bonus spins, internal test rounds | The outcome depends on the operator, verifiability is limited to logs and the platform's reputation |
| Hybrid draw scheme | Large prizes where both fast interface response and public proof are needed | More expensive in support: two sources of entropy, its own publication and disclosure procedure |
The hybrid works like this: the server forms a preliminary result and immediately publishes its hash, and after a request to the oracle it reveals the original value — any discrepancy is visible to anyone checking the chain.
This compensates for the confirmation delay: the player sees the wheel spin instantly, and the proof of fairness follows and remains on the blockchain forever.
Which scheme to choose depends on the prize class and who, under the campaign rules, is considered the arbiter of a dispute.
Stages of implementing a draw on smart contracts
Implementation of a draw begins not with code, but with analyzing the mechanics: how the winner is determined, where bets are stored, who initiates the payout, and what happens if a transaction is interrupted.
One unaccounted scenario — and the prize is paid twice or the result becomes predictable before publication. That is why the work proceeds in stages, and each stage records a verifiable result.
- Mechanics audit. We analyze the draw rules, the roles of the operator and administrator, the source of randomness, and points where manual intervention is possible. The output is a map of risks and limitations.
- Draw scheme design. We define the structure of the wheel of fortune contract: participant registry, bet acceptance, the moment of randomness request, rules of finalization and prize distribution.
- Environment setup. We connect a verifiable source of randomness, set limits and a funding procedure, move administrative functions to a multisig, add pause and protection against re-launch.
- Test network. We run scenarios: oracle response delay, failure, retry, draw with no participants, calling a function from someone else's role.
- Payout verification. We reconcile amounts with the contract balance, check limits and cases where the prize could not be sent: such a payout goes into a queue rather than being lost.
- Handover to operation. We provide the update procedure, accesses, monitoring and alert settings, the procedure for failure and rollback to the previous version.
Configuration, schemes, and draw procedures
Acceptance of a draw is not a signature saying "it works", but a set of artifacts by which another team can further operate the system.
Below is the minimum that we hand over together with the code and by which we ourselves check the readiness of the wheel of fortune for operation.
- Draw configuration — a table of parameters with current and boundary values: round duration, bet step, prize weights, participant limit. Values are kept separate from the logic, so they can be edited without rebuilding and re-auditing the contract.
- Component scheme — an interaction diagram: the round contract, external randomness source on Chainlink VRF, operator wallet, payout module, participant interface. It marks which calls are automatic and which require a human signature.
- Access policies — a role matrix: starting a round, confirming a payout, pausing the contract, changing parameters. Operator keys are stored in secure storage with separation of duties, not in a single wallet.
- Execution procedure — a step-by-step round scenario with milestone deadlines: accepting bets, requesting a random number, calculating the winner, payout, publishing results and the draw protocol.
- Emergency procedure — what to do if the random number did not arrive within the window, the payout failed, or a participant disputes the outcome. Rollback and round restart points without losing bets are described.
- Support documentation — events and metrics for monitoring, an on-duty incident checklist, the composition of data for audit, and escalation procedure.
Case: reduced disputed payouts after the draw
A gaming project held prize draws via a wheel of fortune every week, but the result was generated on the server and was not publicly confirmed. Players saw only the final record, so an unlucky streak was perceived as rigging.
At peak, the share of draws after which a disputed request came in reached 4%, and handling one case took up to two days: support manually reconciled logs, exports, and correspondence.
What was changed
Randomness was moved to Chainlink VRF: the request and result are recorded in the contract before disclosure, and the participant receives a link to the record and verifies it themselves, without contacting support. A verification page was built alongside — a history of draws with confirmation for each.
What became
The share of disputed requests decreased by about eight times — from 4% to 0.5% of draws. Handling one request dropped from two days to 10-15 minutes: in most cases the issue is closed with a link to the record, not by analyzing logs. Public confirmation is now available for every draw; previously there was none for any.
Isolated cases remain, and they are mainly about account access, not about the fairness of the result. Monitoring was added: if confirmation did not pass or was delayed, an alert triggers and the draw does not start.
Disputed payouts decreased not by tightening the rules, but because the result became visible before the conversation started.
How does verifiable randomness differ from a number generator?
An ordinary number generator on a server lives inside a closed process: only the finished result comes out, and the path to it is visible only in the operator's logs.
There is a single point of trust here: the player is asked to believe that the code was not restarted, the seed was not selected, and an inconvenient outcome was not replayed.
As long as the fairness of the draw rests on the administrator's reputation, a payout dispute is resolved with words, not data. Verifiable randomness removes this point: the generation request is recorded in a public registry before the number itself becomes known.
The value itself comes from an external source together with a cryptographic proof — it cannot be substituted after the fact, the request is already sealed.
Then public confirmation works: any participant takes the request, the response, and the proof and independently recalculates the result, and verification comes down to arithmetic, not to access to the operator's logs.
We separately maintain reproducibility of the result: the number must unambiguously turn into a wheel sector.
The mapping rule is described in the contract, so the same response with the same wheel state always yields the same sector — a dispute over draw history is closed by recalculation, not by a screenshot.
Verifiable generators such as Chainlink VRF work on this principle. For a wheel of fortune, this means the operator stops being the arbiter of their own game: the question "was it fair?" moves from the plane of trust to the plane of verification.
Common technical concerns before launch
Before launching a wheel of fortune on blockchain, engineering questions are usually the same: what to do with an already running draw, how the contract will behave when the randomness oracle is unavailable, and whether the logic can be verified independently of the team. Below are short answers to each, without general promises.
We already have a running draw — can it be migrated?
Yes. We migrate the logic and accumulated state: the participant list, win history, and current prize pool. The contract address changes, so we prepare an announcement for users in advance and mirror the data before switching traffic so that no result is lost.
What happens if the randomness oracle is unavailable?
The contract goes into waiting mode: the random number request remains open, the draw is not finalized, prizes are not blocked. The participant can repeat the request, and after a specified interval — withdraw the bet.
The wheel does not substitute the result with block data: the only source of randomness is Chainlink VRF.
How is the cost of network operations calculated?
Each spin is a separate record on the blockchain, and its cost is determined by network load, not by our team. We allow a margin for the computation limit, batch operations, and give the client a clear corridor: how many spins the contract can withstand at peak activity.
Can the contract be verified without your team?
Yes. The code is published in an open registry, and the source of randomness and draw result are visible by transaction hash. An independent auditor reproduces the fairness check themselves, without requesting access from us and without trusting our reports.
Let's discuss your task: where to start
To make the estimate rely on mechanics rather than guesses, a few inputs are enough for us. Below is what to send in the first message; some points can be clarified during the conversation.
- Mechanics: wheel sectors, drop chances, what exactly the winner receives — a token, a coupon, or service access.
- Fairness: whether a publicly verifiable source of randomness is needed and how a participant will re-check the draw result.
- Network and assets: where the project operates, which tokens are involved, whether contracts are already deployed and their addresses.
- Roles and accesses: who owns the contracts, who funds the prize pool, which operations must be restricted.
- Load: how many attempts per day are expected, how the system behaves at peak and when the prize pool is exhausted.
- Limitations: geography and age of participants, protection against manipulation, reporting to partners.
The first step is a mechanics review on a call: we go through the randomness flow, the contract scheme, and roles. We pull in randomness via Chainlink VRF: the result is publicly verifiable, not "we take your word for it".
After the review, we come back with a scheme, a breakdown into stages with acceptance at each, and a timeline estimate.
We work in stages: wheel contracts and randomness integration, an admin panel for the prize pool, a run on an isolated network, and deployment to the mainnet. Describe the task — we will come back with an estimate and a plan.