On-Chain RNG System Development for Blockchain
Using block.timestamp, block.prevrandao, or the previous block hash for random number generation is risky: miners or validators can influence these values. A few years ago, a well-known lottery lost $4M due to block hash manipulation. Random numbers on a blockchain are a non-trivial problem requiring a tailored approach. We develop turnkey RNG systems, assess threats, and propose optimal solutions. Our experience includes more than 50 successful projects in this field.
Why Is On-Chain Randomness Hard?
Blockchain is deterministic. Every node must reach the same outcome by executing the same operations. This fundamentally contradicts randomness: if the result is predictable, it is not random. Any source visible on-chain before the result is committed can be exploited by an attacker.
Validator bias — an Ethereum validator sees block.prevrandao (RANDAO reveal) before publishing the block. If the result is unfavorable, they can skip their slot (slot is skipped, result changes). The attack cost = lost slot reward (~0.01 ETH). If the lottery stake > 0.01 ETH, the attack is rational.
Chainlink VRF: Standard for Most Cases
Chainlink VRF (Verifiable Random Function) is the most battle-tested solution for NFT mints, lotteries, and game mechanics. It works through the oracle network:
- The contract requests a random number by sending LINK.
- A Chainlink node generates the random number and a cryptographic proof.
- The proof is verified on-chain before the number is used.
// VRF V2.5 (current version)
import {VRFConsumerBaseV2Plus} from "@chainlink/contracts/src/v0.8/vrf/dev/VRFConsumerBaseV2Plus.sol";
import {VRFV2PlusClient} from "@chainlink/contracts/src/v0.8/vrf/dev/libraries/VRFV2PlusClient.sol";
contract Lottery is VRFConsumerBaseV2Plus {
uint256 public s_subscriptionId;
bytes32 public keyHash; // gas lane
uint32 public callbackGasLimit = 200_000;
uint16 public requestConfirmations = 3;
mapping(uint256 => address) public requestToPlayer;
function requestRandomWinner() external returns (uint256 requestId) {
requestId = s_vrfCoordinator.requestRandomWords(
VRFV2PlusClient.RandomWordsRequest({
keyHash: keyHash,
subId: s_subscriptionId,
requestConfirmations: requestConfirmations,
callbackGasLimit: callbackGasLimit,
numWords: 1,
extraArgs: VRFV2PlusClient._argsToBytes(
VRFV2PlusClient.ExtraArgsV1({nativePayment: false})
)
})
);
requestToPlayer[requestId] = msg.sender;
}
function fulfillRandomWords(
uint256 requestId,
uint256[] calldata randomWords
) internal override {
address player = requestToPlayer[requestId];
uint256 result = randomWords[0] % totalTickets;
_declareWinner(player, result);
}
}
requestConfirmations: 3 — wait for 3 block confirmations before generating. This complicates reorg attacks on the request.
VRF Limitations: latency 1-3 blocks (15-45 seconds on mainnet), LINK cost per request (0.25-2 LINK depending on network), and subscription management overhead. For high-frequency gameplays (each move in a game requires randomness), it is too expensive and slow.
Commit-Reveal: Randomness Without an Oracle
For cases without access to Chainlink or to minimize costs, use a commit-reveal scheme:
Weakness of commit-reveal: the last person to reveal sees the final result before publishing. They may choose not to reveal (griefing) or reveal only if the result is favorable. Mitigation: a penalty for not revealing (a bond deposited at commit that is burned if the reveal is missed).
Example implementation with bonds
mapping(address => bytes32) public commits;
mapping(address => uint256) public bonds;
uint256 public bondAmount = 0.1 ether;
function commit(bytes32 commitment) external payable {
require(msg.value == bondAmount);
commits[msg.sender] = commitment;
bonds[msg.sender] = msg.value;
}
function reveal(uint256 secret) external {
require(keccak256(abi.encode(secret, msg.sender)) == commits[msg.sender]);
// process secret
payable(msg.sender).transfer(bonds[msg.sender]); // return bond
delete bonds[msg.sender];
}
function claimBond(address participant) external {
require(bonds[participant] > 0);
// check that participant did not reveal in time
// transfer bond to caller
}
RANDAO: Native Ethereum Randomness After PoS Transition
After Ethereum transitioned to Proof of Stake, block.prevrandao provides the aggregated RANDAO reveal from validators. This is better than the old block.difficulty, but has the validator bias issue described above.
For non-critical use cases (cosmetic in games, queue ordering, small lotteries), block.prevrandao is sufficient and free:
uint256 random = uint256(keccak256(abi.encode(
block.prevrandao,
block.timestamp,
msg.sender,
nonce++
)));
Adding msg.sender and nonce increases entropy and makes prediction harder for a specific user, though it does not eliminate validator bias.
How to Choose the Right RNG Method?
| Use Case | Stake / Value | Recommendation |
|---|---|---|
| NFT mint (whitelist randomization) | High | Chainlink VRF |
| Lottery with large prize | High | Chainlink VRF + requestConfirmations: 5+ |
| In-game randomness (items) | Medium | Commit-reveal or Chainlink VRF |
| Queue ordering | Low | block.prevrandao |
| PvP matchmaking | Low | block.prevrandao + nonce |
Comparison of Methods
| Method | Security | Speed | Cost | Complexity |
|---|---|---|---|---|
| Chainlink VRF | High | 1-3 blocks | 0.25-2 LINK per request | Medium |
| Commit-reveal | Medium (depends on mechanics) | 2+ rounds | Only gas | High |
| RANDAO | Low (validator bias) | 0 blocks | Free | Low |
| Hybrid (off-chain + on-chain) | High | 0 blocks | Combination | High |
Hybrid Solutions
For GameFi projects requiring fast randomness with high throughput, we use an off-chain VRF with on-chain commitment:
- Backend generates a seed via Chainlink VRF in advance.
- The hash of the seed is published on-chain (commitment).
- For each game event, use HMAC(seed, event_id) as randomness.
- After the session, reveal the seed; users can verify all results.
This provides instant response for each action and full verifiability post-factum. A hybrid solution saves up to 90% in gas fees compared to direct VRF requests, and at high frequency use, it is 5-10 times cheaper.
What You Get
- Threat analysis and selection of the optimal scheme.
- Integrated smart contract with unit test coverage (200+ tests).
- Deployment and usage documentation.
- Support during deployment and monitoring.
- Team training (optional).
We guarantee transparency — all solutions are verifiable on-chain. Contact us to evaluate your project.
Work Process
Analysis. Determine the threat model: who can attack? What is the maximum profit from manipulation? What latency is acceptable? Is Chainlink available on the target chain?
Development and Testing. VRFConsumer is tested using VRFCoordinatorV2_5Mock from the Chainlink package, allowing fulfillment simulation in unit tests without the real oracle network. Commit-reveal is tested against griefing and last-revealer attacks.
Deployment. For Chainlink VRF, create a subscription, fund LINK, add the consumer. Set up monitoring of the subscription balance.
Time Estimates
Integration of Chainlink VRF into an existing contract: 1-2 days. RNG system with commit-reveal and anti-griefing: 1-2 days. Hybrid off-chain VRF with on-chain commitment and verification: 3-5 days.
Get a consultation — we will evaluate your project and propose the optimal turnkey solution.