Crypto lotteries determine odds from the underlying game design (for example, how many balls are drawn from how many numbers, or how many tickets are in the pool) and then rely on verifiable randomness to make the draw unbiased and auditable on-chain. Modern systems use verifiable random functions (VRFs), randomness beacons like drand, or commit–reveal schemes so that anyone can verify a draw after it happens.
The core math behind lottery odds
In a classic “N choose K” lottery that draws K unique numbers from N without replacement, the number of possible combinations is C(N, K) and the probability a single ticket exactly matches all K is 1 / C(N, K). This is the same math national lotteries use; for example, a 6-from-49 game has C(49, 6) possible outcomes.
If there are multiple winners or you hold multiple tickets, outcomes follow the hypergeometric distribution (sampling without replacement). That lets you compute the probability of getting at least one winning ticket when n tickets are drawn from a pool of size N that contains K wins.
In “ticket-raffle” style crypto lotteries where every ticket is just an entry and one winner is selected uniformly at random, your chance is simply your tickets divided by total tickets; when m winners are selected without replacement, hypergeometric math again applies.
Why randomness is tricky on blockchains
Blockchains are deterministic, so naïve “randomness” like using a block hash or timestamp can be observed or even influenced by validators/miners at the margins. Security guides and research highlight that block variables are not suitable sources of randomness for value-bearing applications. This is why reputable projects avoid blockhash-based RNG for lotteries.
Since Ethereum’s merge, the PREVRANDAO value exposes the protocol’s RANDAO output, but developer discussions still caution about bias and use-case limits. In practice, production lotteries prefer verifiable, purpose-built randomness rather than raw block data.
Three production-grade ways crypto lotteries get fair randomness
1) Verifiable Random Functions (VRFs)
A VRF produces a random value plus a cryptographic proof that anyone can check on-chain. With Chainlink VRF (widely used in lotteries and prize games), a contract requests randomness; the oracle network returns the random “word(s)” and a proof; the proof is verified on-chain before the consumer contract uses the value. Because the proof must verify, a compromised node cannot bias the outcome; at worst it can fail to respond, which is visible and mitigated at the protocol level.
2) Public randomness beacons (drand / League of Entropy)
The drand beacon publishes a new, publicly verifiable random value at fixed intervals. It’s operated by independent organizations (the League of Entropy), and each round’s randomness can be verified using threshold cryptography, making it suitable as an unbiased public source of entropy.
3) Commit–reveal schemes
Participants commit to hidden values (hashes) and later reveal them. The combined reveals seed the draw. This protects against front-running, but comes with liveness risks if a participant withholds their reveal; research notes that making such schemes fully game-theoretic often requires large deposits. Many builders therefore pair commit–reveal with penalties or fallbacks, or they favor VRF.
How an on-chain lottery implements odds and draws
Ticketing and prize pool
Smart contracts sell tickets and escrow the prize pool. Because all entries are on-chain, you can compute your odds directly from the contract state (for example, your tickets divided by total tickets for a raffle). Documentation for prominent projects shows this pattern alongside verifiable randomness for draws.
Drawing the winner
At the scheduled time, the contract requests randomness from the source (for example, Chainlink VRF). The returned random word is mapped to an outcome (such as an index in the ticket list or the six-number combination). Tutorials and case studies demonstrate this end-to-end pattern for lotteries.
Real-world examples
PoolTogether, a “no-loss lottery,” uses Chainlink VRF so winners are provably chosen without trusting the team. PancakeSwap’s Lottery V2 also integrated VRF and emphasizes public auditability of each drawing.
Deriving your odds in common crypto-lottery designs
Combination lottery (pick K from N)
If each ticket is a unique combination, your chance to hit the jackpot with one ticket is 1 / C(N, K). With t tickets, it’s t / C(N, K), assuming all combinations are equally likely. For lower-tier prizes (for example, “match 3”), use the combination formulas as outlined in standard lottery mathematics.
Raffle with one or more winners
If the lottery draws m winners uniformly from T total tickets without replacement and you hold t tickets, the probability you win at least once is 1 minus the probability all m winners are from other tickets; compute it via the hypergeometric distribution.
Weighted or tiered-entry raffles
If tickets carry weights, the protocol should disclose the selection mechanism. Many systems normalize weights to a cumulative range and choose a random offset via VRF; odds are then proportional to your weight share. The verifiability still depends on the randomness proof.
How to verify a “provably fair” draw as a player
Check three things: first, confirm the randomness source (VRF request and fulfillment or beacon reference) in the transaction history; second, verify the on-chain proof succeeded; third, confirm the mapping from random word to outcome matches the published logic. Chainlink’s docs describe how the proof is generated and verified on-chain before contracts can consume it.
For beacon-based lotteries, inspect the beacon round referenced by the draw and validate its signature using the operator’s public parameters. The drand docs and League of Entropy pages explain the verification flow.
What to watch out for (risk and edge-cases)
Avoid lotteries that seed randomness from block.timestamp or blockhash; these are known anti-patterns. If a project relies on commit–reveal, make sure there are clear penalties or timeouts to prevent griefing. Even with VRF, understand that a misconfigured or non-responding oracle shows up on-chain; reputable systems have fallbacks or redraw logic. Security write-ups and standards bodies repeatedly flag insecure randomness as a top smart-contract risk.
Quick checklist for evaluating a crypto lottery
Confirm the randomness source (VRF, drand, or robust commit–reveal) and where to see the proof on-chain. Read the prize mapping code and the draw schedule. Calculate your odds from the contract state using the math above. For multi-winner designs, use hypergeometric logic. Favor projects with public audits and a history of verifiable draws.
FAQ
Why not use the block hash for randomness?
Because block producers can sometimes bias or withhold blocks, and timestamps are set by producers within bounds. Official security guidance recommends not using these for value-bearing randomness.
What is a VRF in plain English?
It’s a cryptographic function that outputs a random value plus a proof that the value was generated correctly; anyone can verify the proof on-chain. That’s why it’s popular in lotteries and prize games.
What’s a randomness beacon?
A public service (like drand’s League of Entropy) that periodically publishes an unpredictable, verifiable random value that anyone can use as a common randomness source.
How are odds computed in a pick-6 lottery?
With combinations: your chance is 1 / C(49, 6) in a 6-from-49 design. Lower-tier prizes use the same combinatorics.
Which real projects use verifiable randomness?
PoolTogether and PancakeSwap Lottery are well-known examples using Chainlink VRF so that winner selection is publicly auditable.
Sources and further reading
• Chainlink VRF — product and docs on on-chain proof-verified randomness.
• drand / League of Entropy — decentralized randomness beacon.
• Lottery mathematics and combinatorics of odds.
• Hypergeometric distribution for multi-winner raffles.
• Why block variables are insecure for randomness.
• Case studies: PoolTogether and PancakeSwap Lottery using VRF.
