WEAK RANDOMNESS: PUBLIC INPUTS, PROPOSER BIAS, AND SAFER DESIGNS

Weak randomness appears when a contract uses a predictable or biasable value for an outcome whose value exceeds the cost of influencing it. Hashing block.timestamp, a recent block hash, caller data, or other public inputs does not make them secret. Attackers can often compute the same result during execution and decline unfavorable outcomes.

BLOCK DATA AND PREVRANDAO

Solidity warns against relying on block.timestamp or blockhash as randomness. A past block hash is already public, while blockhash(block.number) returns zero. Combining several public values with keccak256 changes their representation, not their predictability.

block.prevrandao deserves a more precise analysis. EIP-4399 exposes the proof-of-stake RANDAO mix and offers guidance for applications that use future values with sufficient lookahead. It is not a universal drop-in random number for immediate, high-value settlement. A proposer can withhold a block rather than update the mix and can censor an outcome-producing transaction into a later block. The practical risk depends on lookahead, validator control, transaction ordering, repetition, and value at stake.

REVIEW AND TESTING

Trace every value that selects a winner, trait, allocation, committee, liquidation order, or reward. Work backward through hashes and helper functions to the original entropy. Ask when each input becomes known, who can influence inclusion, whether a caller can revert after learning the result, and whether a proposer, sequencer, oracle operator, or final revealer gets another attempt.

Tests should use an attacker contract that calculates the same block-derived value and calls only on favorable outcomes. Model repeated attempts and gas costs rather than testing one draw. For asynchronous randomness, test reordered and delayed fulfillments, chain reorganizations, duplicate requests, callback failure, and attempts to accept new bets after randomness was requested.

Firepan can inspect entropy sources and their data flow into outcomes in a submitted repository and commit. It cannot prove cryptoeconomic safety without deployment, chain, adversary, and value-at-risk assumptions.

MITIGATION AND LIMITS

• Use a reviewed verifiable-randomness protocol for high-value outcomes and follow its request, confirmation, and fulfillment rules.
• Freeze user inputs before requesting randomness. Match each fulfillment to its request ID and do not let a party cancel or re-request after an unfavorable result.
• If using PREVRANDAO, select a future value with an analyzed lookahead and document proposer-bias assumptions from EIP-4399.
• Design commit-reveal so one party cannot bias the result by refusing to reveal. Timeouts, deposits, default contributions, and enough independent participants may be necessary.

VRF integration is not secure merely because the output is verifiable. Chainlink's guidance requires suitable confirmation depth, forbids outcome-specific re-requests, and warns that fulfillment order is not guaranteed. Liveness and callback behavior remain part of the protocol design.

SOURCES

• EIP-4399: PREVRANDAO
• Solidity Documentation: Block and Transaction Properties
• Chainlink Documentation: VRF Security Considerations