What is Insecure Randomness?

Insecure randomness occurs when a smart contract relies on predictable, manipulable, or insufficiently protected sources of randomness. On public blockchains, values like blockhashes, timestamps, or predictable seeds can be observed or influenced by miners, validators, or adversaries.

Why is Insecure Randomness a Fundamental Threat?

Randomness is often used to assign rewards, pick winners, shuffle order, or decide outcomes. When randomness can be predicted or manipulated, the integrity of these outcomes is destroyed. Attackers can bias lotteries, drain prize pools, or tilt odds in their favor. What was meant to be fair turns into adversarial control.

How Common is the Insecure Randomness Vulnerability?

From Sherlock’s audit history, about 1 in every 80 vulnerabilities involves some form of insecure randomness. It’s considerably less frequent than arithmetic bugs or access control flaws. But (and this is important) when randomness is at the core of functions like prize draws, NFT mints, or validator selection, the consequences can be disproportionately significant.

In recent years, public governance of randomness has improved dramatically thanks to secure oracles and cryptographic techniques like VRFs. Yet the risk hasn’t vanished entirely.

What’s the Impact?

Insecure randomness compromises fairness and trust. Attackers can game lotteries, guarantee favorable NFT traits, manipulate validator elections, or tilt governance. The result isn’t just theft, it’s a collapse of credibility.

Examples from Sherlock Audits:

1️⃣ PoolTogether

In PoolTogether, attackers found a way to siphon yield that was supposed to fund prize drawings. By diverting those rewards, they could artificially boost their odds of winning the lottery-style payout. A mechanism designed to be fair and community-driven was instead skewed, showing how insecure randomness can break trust in incentive systems.

2️⃣ Boost

Boost’s wallet contracts used blockchain variables like the block’s timestamp (the time a block is added) and block entropy values as “random” inputs to select raffle winners. The problem? These values aren’t truly random - they can be predicted or even influenced by block producers. That means the outcome of supposedly random draws could be manipulated, leaving users exposed to unfair results.

3️⃣ LooksRare

LooksRare ran a selection process where random numbers were used to decide which participants would be penalized in a game-like mechanic. But the way the logic was structured meant that participants later in the list had a much higher chance of being selected than those at the front. Even though randomness was used, the distribution wasn’t fair, certain players had the odds stacked against them.

Past Exploit Examples:

2023 Chainlink VRF Bug (Whitehat Patched):

Security researchers discovered a flaw in Chainlink’s Verifiable Random Function system, where a malicious subscription owner could repeatedly attempt randomness requests until they received a favorable number. Chainlink patched the issue and rewarded the discovery with a $300,000 bounty.

EtherPredictions (2017): 

A betting DApp relied on block.timestamp for randomness. Miners could slightly adjust the timestamp to tilt outcomes in their favor. This was one of the earliest wake-up calls that block variables are not true entropy.

Fomo3D (2018): 

The popular Ethereum lottery game used block attributes (blockhash, timestamp) to determine winners. Attackers manipulated these values, exploiting predictable randomness to time entries and gain unfair advantages.

How to Prevent Insecure Randomness?

✅ Use Verifiable Random Functions (VRFs)

Chainlink VRF and similar oracle-based systems generate randomness with cryptographic proofs, ensuring it can’t be predicted or tampered with.

✅ Commit-and-Reveal Schemes

Design systems where participants commit to hidden values first, then reveal them later. This ensures randomness depends on multiple parties, not just public data.

✅ RNG via Multi-Party Computation

Distribute trust across multiple participants who jointly generate random values, reducing single-point manipulation.

✅ Stress-Test Assumptions

If randomness underpins core logic, simulate adversarial conditions. Assume miners, validators, or participants can bias or censor inputs.

Our Take

Randomness is deceptively hard in deterministic environments like blockchains. Without cryptographic guarantees, “random” values are really just predictable system variables. For protocols where fairness is the foundation, ensuring trusted randomness is not optional, it’s critical to security, credibility, and adoption.

‍

For teams aiming to secure their code from development through production, the Sherlock Intelligence delivers dynamic, full-lifecycle security - combining collaborative audits, continuous monitoring, and bounty protection in one connected framework. Contact our team to learn more.