Oracles and On-Chain Randomness: How Crypto Games Get Their Dice Rolls

Randomness is the foundation of every casino game. For an on-chain gambling contract to be trustworthy, its source of randomness must be unpredictable, unmanipulable, and verifiable after the fact. Achieving all three simultaneously on a deterministic blockchain — where every node must reproduce the same computation — is genuinely hard. This article explains how the industry has tried to solve it, where the solutions work, and where they still carry meaningful risk.

Why Blockchains Can’t Generate Randomness Natively

A blockchain is a deterministic state machine. Every node running the network must execute every transaction and arrive at the exact same result. True randomness — by definition unpredictable — cannot be generated deterministically. If a smart contract tried to use something like “random number between 1 and 6,” every node would need to agree on the same number, which means it can’t actually be random from the contract’s perspective.

Early solutions reached for block-hash based randomness: using the hash of the upcoming block as an entropy source. This seems reasonable at first — block hashes are unpredictable in advance. But it has a critical flaw.

The Block-Hash Manipulation Attack

A miner or validator who is about to produce a block knows the candidate block hash before publishing it. If a gambling contract uses block.hash(block.number) as its randomness seed, the validator can:

1. Compute the outcome before committing the block
2. If the outcome is unfavorable (e.g., casino wins), simply discard the block and try again
3. Include the block only when the hash produces a favorable outcome

This is called withholding or selective publishing, and it costs the validator only the opportunity cost of that block reward — a worthwhile trade if the bet is large enough. A validator controlling 10% of the network has 10% of blocks and could systematically exploit any contract that uses block hashes as randomness.

Variants that look more sophisticated — using multiple block hashes, XORing with timestamps, combining with user-supplied seeds — are often similarly exploitable or simply move the trust to the miner without eliminating it.

Chainlink VRF: The Current Industry Standard

Chainlink VRF (Verifiable Random Function) is the most widely used solution to on-chain randomness. Here’s how it works:

The Mechanism

1. A gambling smart contract requests randomness by calling the VRF Coordinator contract, paying a fee in LINK tokens.
2. Chainlink’s oracle network receives the request along with a seed (derived from the request block hash and a request ID).
3. A designated Chainlink node generates a random number using a cryptographic function that combines the seed with the node’s private key.
4. The node returns: the random number, and a cryptographic proof that the number was generated correctly from that seed and key.
5. The VRF Coordinator verifies the proof on-chain before passing the result to the requesting contract.

The key property is verifiability: anyone can check after the fact that the random number was generated from the claimed inputs. The casino cannot alter the result; the Chainlink node cannot predict what number will be used for what purpose at the time of key generation.

What VRF Actually Guarantees

• The random number was generated correctly from the inputs (verifiable)
• Neither the requesting contract nor the Chainlink node could have predicted the output before the request (assuming honest key management)
• The result cannot be altered between generation and delivery

What VRF Does Not Guarantee

• Speed: VRF adds latency — typically one to several blocks between request and fulfillment. Games must be designed to accommodate this, often requiring two-phase interactions (commit, then reveal).
• Liveness: If Chainlink’s oracle network experiences issues, the game cannot proceed. Dependency on Chainlink is a liveness dependency.
• The Chainlink node’s key integrity: If a node operator’s private key is compromised, future VRF outputs could be manipulated. Chainlink mitigates this through multiple nodes and key rotation, but it remains a trust assumption.
• The overall game fairness: VRF provides fair randomness. It does not guarantee that the game’s payout structure, house edge, or terms are favorable to players.

Other Randomness Approaches

Commit-Reveal Schemes

Some games use a commit-reveal pattern: the casino pre-commits to a hashed secret before the bet, and the player provides their own seed. After the bet, the casino reveals its secret, which combines with the player’s input to produce the outcome.

This is the basis of most provably fair systems. It works if:

• The casino truly commits before knowing the player’s seed
• Neither party can selectively abort (a casino that can refuse to reveal is effectively choosing outcomes)

The provably fair gambling article covers this model in depth. The short version: commit-reveal is sound in theory but requires careful implementation and honest operator behavior.

RANDAO (Ethereum’s Native Randomness)

Ethereum’s proof-of-stake consensus uses a system called RANDAO to generate per-block randomness. Validators contribute random values in a mixing process. The result is available as block.prevrandao in smart contracts.

RANDAO is stronger than old block-hash randomness, but it still has a last-reveal attack: the last validator in an epoch to contribute can see the current accumulated value and choose to reveal or withhold, biasing the output slightly. For low-stakes games, this bias may be negligible. For large bets, it remains a meaningful attack vector. VRF is generally preferred for gambling contracts.

Drand and Threshold Schemes

Drand is a distributed randomness beacon run by a consortium of independent parties. It produces publicly verifiable random values on a schedule (roughly every 3 seconds). Some protocols integrate Drand’s outputs as a randomness source. The trust assumption is that no single party controls enough of the consortium to bias the output — a reasonable assumption if the nodes are genuinely independent.

The Oracle Trust Layer

More broadly, any time a smart contract depends on external data — randomness, price feeds, sports results — it uses an oracle. The oracle is the bridge between the on-chain world and external reality, and it is always a trust assumption.

A game that promises “fully on-chain fairness” while using a centralized oracle for its randomness has moved the trust from the casino’s server to the oracle operator. This isn’t necessarily bad — Chainlink’s VRF is a meaningful security improvement over block hashes — but it’s not the same as trustlessness.

For sports betting and prediction markets, the oracle trust problem is even more acute: someone must report the real-world outcome, and that reporter can be wrong, bribed, or hacked. See smart contracts in gambling for how this plays out in practice.

What to Look For as a Player

If a gambling site claims provably fair or on-chain randomness, you can verify it — to a degree:

1. Find the smart contract address (a reputable site will publish it)
2. Read the contract source code on a block explorer like Etherscan
3. Look for VRFConsumerBase or VRFCoordinatorV2 imports — these indicate Chainlink VRF usage
4. Check event logs for RandomWordsRequested and RandomWordsFulfilled events on actual bets

If the contract is unverified (source code not published), or if randomness comes purely from block.hash, treat the fairness claims with skepticism.

Even with perfect randomness, the house edge is structural and permanent. No oracle makes a negative-EV game neutral. For a full picture of what randomness verification does and doesn’t protect you from, visit responsible gambling.