Rolling Dice on a Blockchain: Why Fair Loot Drops Are So Hard

Every game runs on dice. Critical hits, loot drops, card packs, map seeds, the order of a shuffle: behind all of them is a random number. On a normal game server, getting one is trivial. On a public blockchain, it's one of the hardest problems in the whole field.

Why a blockchain is bad at randomness

A blockchain works because every node runs the same code and gets the same answer. That's what makes it trustworthy. But it means there is no private, unpredictable source of randomness inside the system. Anything a smart contract can see, everyone else can see too.

Early developers tried using values that looked random, like the current block's timestamp or the hash of a recent block. The trouble:

• Anyone can read them. A player's own smart contract can compute the same "random" result before deciding whether to act.
• Block producers can influence them. The party building a block has some control over its contents and timing, and could choose not to publish a block whose result they didn't like.

When it goes wrong

The classic cautionary tale is Fomo3D, a 2018 Ethereum game that worked like a countdown lottery: the last player to buy a "key" before the timer ran out won the pot. In the first round, a player won more than 10,000 ETH by flooding the network with their own high-fee transactions so that nobody else's could get in before the clock hit zero. It wasn't a randomness bug exactly, but it showed how a public chain lets clever players manipulate the very conditions a game depends on.

For loot-box style mechanics, the same principle applies: if the result can be predicted or nudged, someone will.

The fix: verifiable random functions

The most widely used answer in blockchain games is a verifiable random function (VRF). The best-known service is Chainlink VRF.

Here is how it works, in plain terms: 1. Your game's contract requests a random number. 2. An off-chain operator generates the number using its secret key, together with information from the request that the operator can't control. 3. The operator sends back the number plus a cryptographic proof that it was generated correctly from those inputs. 4. The contract checks the proof on-chain before using the number. If the proof doesn't match, the number is rejected.

The result is randomness that the operator can't secretly fix, the player can't predict in advance, and anyone can check afterwards.

Other approaches

VRF isn't the only option:

• Commit-reveal. Players first submit a hidden commitment (a hash of a secret), then reveal it later. Combining several players' secrets produces a number none of them controlled alone. It's cheap, but slow, and someone who dislikes the result may simply refuse to reveal.
• Protocol randomness. Since Ethereum moved to proof of stake, it produces a value called RANDAO from validators' contributions. It's useful, but validators still have a small amount of influence, so it isn't recommended for high-stakes outcomes on its own.
• Off-chain servers. Many "blockchain" games simply roll the dice on their own servers and record the outcome. That's fast and cheap, but you're back to trusting the studio.

What it means for players

When a blockchain game advertises "provably fair" drops, ask how. If the answer is a VRF or a well-designed commit-reveal scheme, the claim can be checked. If the dice are rolled on the studio's server, the outcome is recorded on-chain but the fairness isn't proven by it.

Why it matters

Fair randomness is where blockchain games can offer something normal games rarely do: drop rates you can check rather than just trust. That matters in an industry where loot boxes and gacha odds have drawn regulatory attention around the world, including disclosure rules in Korea. It's also a reminder that "on-chain" doesn't automatically mean "fair". The design behind the dice is what counts.

For more on how blockchains handle game logic, read our explainers on Dark Forest and gas fees and layer 2s.