Blockchains cannot roll dice

September 13, 2026

Every mint with random traits, every onchain game, every raffle needs a dice roll. And the EVM cannot roll dice. A blockchain works because thousands of machines run the same transaction and arrive at the same result. Determinism is the whole point. Randomness is the one thing the machine is built not to have.

What people use instead

The usual tricks are block.timestamp, blockhash, prevrandao - values that feel random but are produced by whoever builds the block. The proposer sees them first and at some margin can influence them. Worse, any outcome computed inside a transaction can be simulated before sending it, and reverted if you do not like it. That is how early NFT mints got sniped for rare traits - simulate, revert, retry until happy. When there is money on the outcome, someone will always run the numbers first.

The known fixes each give something up. Commit-reveal needs two transactions and dies the moment the losing side refuses to reveal. Oracle VRFs work, but now you are paying a vendor per roll and trusting their keys and their uptime.

Randomness as a public utility

drand is a network of independent organizations that jointly publish a random value on a fixed schedule - quicknet emits one every 3 seconds. Each value is a threshold signature over the round number, which gives you two properties at once. No single member can predict or bias it. And because rounds are scheduled, you can commit to a future round today - round N is unknowable until its time arrives, then verifiable by anyone forever.

We took that and built drand-quicknet-evm at the based labs. A contract commits to an exact future quicknet round before that value exists anywhere in the universe. When the round arrives, anyone - us, you, a stranger - can relay the beacon onchain, and the contract verifies the BLS signature itself, then derives the randomness from the signature. The relayer is not a trusted party. The worst it can do is be late, because only one valid signature exists for that round. Delayed and rigged are very different failures.

It does not solve everything. The chain needs the right BLS verification support, and the discipline of committing to an exact round - never "whatever beacon is available" - is on the app developer. But it moves randomness from something you trust to something you check.

Tl;dr

The EVM cannot generate randomness, only verify it. So stop generating - commit to a future public beacon round and verify the math when it lands.