# on-chain randomness from block attributes is deterministic and manipulable by validators Block attributes used as randomness sources — `block.timestamp`, `blockhash`, `block.difficulty` (now `block.prevrandao` post-merge) — are either known before the transaction executes or can be manipulated by block producers. Miners (pre-merge) could choose not to publish blocks where the randomness outcome was unfavorable, and validators (post-merge) know `prevrandao` before proposing the block. Chainlink VRF provides verifiable randomness by having an off-chain oracle generate randomness with a cryptographic proof that the contract can verify on-chain. Any application requiring fair randomness (lotteries, NFT minting, gaming) must use an oracle-based solution. Validators who can manipulate randomness can also engage in [[frontrunning exploits public mempool visibility to insert competing transactions before profitable pending operations|frontrunning]] — they see pending transactions before including them and can choose block orderings that favor their own outcomes. **Chainlink VRF version differences matter for security:** | Feature | VRF v1 | VRF v2/v2.5 | |---------|--------|-------------| | Block confirmations | Fixed 10 blocks | Configurable 3–200 blocks | | Outputs per request | 1 | Multiple (multi-word) | | Funding model | Direct LINK | Subscription or direct (LINK or native in v2.5) | | Base contract | VRFConsumerBase | VRFConsumerBaseV2 (with coordinator check) | VRF v2.5 replaced both v1 and v2 on November 29, 2024. Contracts on v1 or v2 should migrate. **Critical implementation rules for any VRF version:** - `fulfillRandomWords()` must **never revert** — the VRF service will not retry; a reverting fulfillment permanently blocks the randomness request - Store randomness in state first, take complex actions in subsequent calls — keeps `fulfillRandomWords` simple and revert-free - Never implement re-request or cancellation logic — VRF v2 explicitly classifies re-requesting as improper usage because it allows the service provider to withhold unfavorable outcomes **Remaining VRF manipulation vectors** (even with correct implementation): - Block producers can order multiple in-flight VRF fulfillments — if contract behavior depends on fulfillment ordering, this is exploitable - Block reorgs produce different VRF output — protocols requiring reorg resistance must wait for sufficient confirmations The Roast Football exploit (December 2022, 12 BNB) used `block.number`, `block.timestamp`, buyer address, and balance as lottery RNG — all directly predictable or influenceable, allowing the attacker to purchase tokens only in favorable blocks. --- Relevant Notes: - [[block timestamp manipulation within protocol bounds enables exploitation of time-dependent contract logic]] — timestamp manipulation as a specific instance of block attribute control - [[frontrunning exploits public mempool visibility to insert competing transactions before profitable pending operations]] — validators combine randomness manipulation with transaction ordering privileges - [[private visibility in solidity only restricts contract-level access while all on-chain data remains publicly readable]] — on-chain transparency enables both randomness prediction and frontrunning - [[commit-reveal schemes without msg.sender binding allow front-runners to copy commitments and claim the reveal reward]] — commit-reveal is the classic defense against frontrunning, but even correct commit-reveal schemes must bind the commitment to msg.sender to prevent commitment copying Topics: - [[vulnerability-patterns]]