Powerblocks Blog

On-chain Lottery RNG: Why Randomness is Hard on a Blockchain

Smart contracts run on deterministic machines: every validator must re-execute your code and reach the exact same result. That’s great for auditability, but it makes “pick a random number” surprisingly dangerous. If the randomness source can be predicted or influenced, a motivated attacker can bias outcomes – especially in high-value games like lotteries.

This is why on-chain lottery RNG design is really a trust and adversary-model problem: who can influence the number, how much influence do they have, and what does it cost them to try?

The Three RNG Approaches Used in On-chain Lotteries

Most on-chain lotteries fall into one of these buckets:

• VRF (Verifiable Random Function): a cryptographic proof that a specific random value was correctly generated from a seed.
• Commit–reveal: participants commit to secrets, then reveal them later; the final randomness is derived from the revealed secrets.
• Block entropy: using on-chain variables like blockhash, timestamp, or prevrandao as “randomness”.

Each can be made safer or more dangerous depending on implementation details.

1) VRF: Cryptographic Randomness with a Proof

A verifiable random function (VRF) produces:

1. A random-looking output, and
2. A cryptographic proof that the output was generated correctly from a given input seed and a specific public key.

Because the proof is checkable, a VRF provider cannot “re-roll” outcomes without being caught: for a given seed and public key, there is only one valid output/proof pair. That’s the core property that makes VRF attractive for lotteries. Chainlink VRF is the most widely used VRF oracle pattern in production smart contracts.

How VRF Works in a Lottery Flow

A typical VRF-based lottery looks like this:

• Your contract requests randomness and supplies a seed-like input (often including a nonce and other request parameters).
• The VRF oracle/network generates the random value and a proof off-chain.
• An on-chain “coordinator” (or verifying contract) checks the proof and then delivers the random value to your contract via a callback.

From an operator-trust perspective, VRF turns “Trust the operator” into “Verify the randomness proof.” That does not eliminate all trust (you still depend on liveness and correct integration), but it sharply reduces outcome manipulation risk.

Failure Modes You Must Design For

VRF shifts risk into a few specific buckets:

Liveness / availability risk
If the oracle network is down or your subscription is misconfigured, draws can stall. You need timeouts, refunds, and an emergency path (ideally governed and transparent) to complete or cancel a draw without creating a manipulation backdoor.

Callback / integration risk
Most real-world exploits come from bad integration: forgetting to validate request IDs, mishandling re-entrancy, or allowing anyone to trigger winner selection with stale randomness. Treat VRF output as a critical input and wrap it in strict state transitions.

Cost & latency
VRF verification and oracle callbacks add overhead. Depending on the chain and configuration, you pay extra gas and wait extra blocks for fulfillment. This is usually worth it when jackpots are meaningful.

When VRF is the Right Choice

Use VRF when:

• prize values are large enough to justify strong guarantees,
• you need “single-click” UX (one transaction to start a draw),
• you want a clean, audit-friendly story: “Here is the proof; anyone can verify it.”

In practice, VRF is the safest default for a high-value on-chain lottery RNG.

2) Commit–reveal: Decentralized Randomness with Game-theoretic Weaknesses

Commit–reveal is conceptually simple:

• Commit phase: parties submit a hash of a secret (a commitment).
• Reveal phase: parties reveal the secret; the contract verifies it matches the commitment.
• The final random value is computed from all revealed secrets (e.g., hash of the concatenation or XOR then hash).

This avoids a single trusted oracle, which is appealing. But it introduces a new attack surface: incentives.

The “Last Revealer” / Withholding Attack

The classic failure mode is the last revealer attack:

• If the final participant to reveal can compute the final outcome before revealing,
• They can choose to withhold their reveal if the result is unfavorable,
• Causing either (a) a stall, or (b) a biased outcome if the protocol proceeds without them.

This limitation is widely discussed in analyses of blockchain randomness and protocol design.

Practical Mitigations

You can mitigate withholding, but each mitigation adds tradeoffs:

Penalties / bonds
Require committers to post collateral and slash it if they fail to reveal. This helps, but only if the bond exceeds the value of manipulating the draw.

Timeouts & default reveals
Proceed after a deadline using only revealed secrets. This prevents stalling, but it reintroduces bias: the set of revealed secrets is now strategic.

Many contributors
The more independent contributors, the harder it is for one party to control the outcome. But coordinating many contributors is hard, and it can degrade UX.

Modern “Commit–reveal with a Provider” (Example: Pyth Entropy)

Some systems blend commit–reveal with a specialized randomness provider to reduce cost and simplify coordination. Pyth Entropy, for example, is designed so users can request a random number and later reveal to finalize it, with details intended to keep the randomness verifiable and reduce manipulation opportunities.

The core idea is still commit–reveal-like: there is a request and a later reveal/finalization step, which implies at least two transactions in the general case.

When Commit–reveal is the Right Choice

Commit–reveal can make sense when:

• Jackpots are moderate,
• You can enforce strong economic penalties,
• You can tolerate 2-step UX,
• Or the randomness is used for governance-like decisions where “stall risk” is acceptable.

For lotteries, commit–reveal is viable, but you need to be brutally honest about who can refuse to reveal and what happens next.

3) Block Entropy: Cheap, Simple, and Often Unsafe for Meaningful Jackpots

“Block entropy” means deriving randomness from values already inside the block, like:

• Block timestamp,
• Blockhash,
• Or Ethereum’s PREVRANDAO (exposed in Solidity as block.prevrandao) after Proof-of-Stake.

It’s tempting because it’s cheap and needs only one transaction. The problem is: block producers have influence.

Why Block Data can be Biased

Ethereum’s EIP-4399 explains that PREVRANDAO replaces the old DIFFICULTY opcode semantics and is sourced from the beacon chain’s RANDAO mix. But it also highlights the key security reality: a proposer can influence outcomes by deciding whether to publish a block (and by transaction ordering), within economic limits.

More broadly, research and engineering write-ups repeatedly show that using block variables for randomness enables biasing attacks via re-ordering, censorship, or selective block publication when the reward outweighs the cost.

The Economic Attack Intuition (Lotteries Make it Worse)

Lotteries concentrate value into a single outcome. That’s exactly when block entropy is weakest.

If a block producer can:

• Simulate whether a given block’s entropy makes them (or a briber) win,
• And then decide to discard/withhold that block if they lose,
  they can bias the distribution. The larger the jackpot, the more rational it becomes to spend resources to bias it.

Even if the protocol is “honest most of the time,” the few times it matters most (big jackpots) are precisely when manipulation is most attractive.

When Block Entropy is Acceptable

Use block entropy only when:

• The stakes are low (testnet, free games, non-critical randomness),
• The randomness does not decide direct monetary outcomes,
• Or you combine block entropy with stronger mechanisms (e.g., commit–reveal or VRF) so it’s not the sole source.

For a real-money on-chain lottery RNG, raw block entropy should be treated as a vulnerability, not a feature.

VRF vs Commit–reveal vs Block Entropy: Choosing the Right Model

Choose VRF if you want the strongest “fair draw” story

• Best security for high jackpots
• Clear public verification
• Simple user flow (often 1 transaction to request; fulfillment later)

Tradeoff: higher cost and reliance on oracle liveness.

Choose commit–reveal if you can enforce incentives and tolerate 2-step UX

• More decentralized control
• Lower on-chain verification cost
• But must handle withholding/last-revealer risk explicitly

Avoid block entropy for high-value lotteries

• Cheapest, but easiest to bias by block producers
• Acceptable mainly for low-stakes or as an auxiliary input

Implementation Checklist for a Provably Fair Lottery

Regardless of model, these patterns make an on-chain lottery RNG safer:

1. Explicit state machine
   No “anyone can call finalize anytime.” Use clear phases: open → closed → randomness requested → randomness fulfilled → winners paid.
2. Anti-stall design
   Define what happens if randomness is delayed or a reveal never arrives. Timeouts must not let an operator pick a favorable alternative.
3. Public audit trail
   Emit events for every critical step. Make it easy for third parties to re-compute winner selection and verify fairness.
4. Economic threat modeling
   Ask: “Who profits from manipulation, and how much does it cost them?” If the profit dwarfs the cost, assume they will try.
5. Defense in depth
   For very high jackpots, consider hybrid approaches (e.g., VRF plus a user seed) so even one compromised component can’t fully control the outcome.

The Bottom Line

If you’re building a serious lottery, the randomness mechanism is the core of your integrity story. For high-stakes payouts, VRF remains the most robust option because it converts trust into verifiable cryptography. Commit–reveal can work, but only with well-designed incentives and clear handling of withholding. Block entropy is fine for toys and tests, but it’s not a safe foundation for meaningful jackpots.

A secure on-chain lottery RNG is less about “what’s trendy” and more about choosing the model whose failure mode you can live with, then engineering every edge case so no one gets a second chance to manipulate the draw.