Lottery Smart Contracts on Blockchain with Chainlink VRF

Imagine you launch a lottery dApp with a $100K pool. Participants demand guaranteed fairness—selecting a winner via block.timestamp gives validators manipulation power. One wrong step and funds can be lost due to reentrancy or front-running. We, blockchain engineers with experience in dozens of projects, solve these problems by implementing Chainlink VRF and rigorous contract audits. Similar architecture has been used in lotteries with cumulative pools over $2M—zero vulnerabilities. In this article, we'll walk through building a verifiably fair lottery on smart contracts.

Why on-chain randomness is unsafe

block.prevrandao in Ethereum gives validators 1 bit of influence. RANDAO aggregates entropy, but the last reveal has influence. For a lottery with a pool >$1M, this is economically attackable: a validator can withhold the reveal. Chainlink VRF solves this cryptographically: randomness is generated off-chain with a proof verifiable on-chain. Faking the random is impossible. Moreover, VRF uses a key pair: the oracle's secret key generates the number, and the public key allows the contract to verify the proof. This guarantees fairness even if the VRF operator is untrusted.

How Chainlink VRF ensures fairness

The contract requests a random number via requestRandomWords, and the oracle returns it in fulfillRandomWords along with a proof. The contract verifies the proof—if invalid, result is rejected. We use the subscription model (VRF 2.5), which is cheaper for frequent requests: pay once for a subscription, then only for gas. Gas cost per request is about 200k gas, which on Ethereum at 20 Gwei is roughly $5-10. For lotteries with frequent draws, this is acceptable.

Lottery contract architecture with VRF

// SPDX-License-Identifier: MIT pragma solidity ^0.8.19; 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 subscriptionId; bytes32 public keyHash; uint32 public callbackGasLimit = 100000; uint16 public requestConfirmations = 3; address[] public participants; uint256 public pendingRequestId; LotteryState public state; enum LotteryState { OPEN, DRAWING, CLOSED } function drawWinner() external onlyOwner { require(state == LotteryState.OPEN, "Not open"); require(participants.length > 0, "No participants"); state = LotteryState.DRAWING; pendingRequestId = s_vrfCoordinator.requestRandomWords( VRFV2PlusClient.RandomWordsRequest({ keyHash: keyHash, subId: subscriptionId, requestConfirmations: requestConfirmations, callbackGasLimit: callbackGasLimit, numWords: 1, extraArgs: VRFV2PlusClient._argsToBytes( VRFV2PlusClient.ExtraArgsV1({nativePayment: false}) ) }) ); } function fulfillRandomWords( uint256 requestId, uint256[] calldata randomWords ) internal override { require(requestId == pendingRequestId, "Wrong requestId"); uint256 winnerIndex = randomWords[0] % participants.length; address winner = participants[winnerIndex]; state = LotteryState.CLOSED; // payout to winner payable(winner).transfer(address(this).balance); } } 

Critical implementation details

requestConfirmations: how many blocks to wait before generating random. Minimum 3, recommended 5 or more. callbackGasLimit: gas limit for fulfillRandomWords. If the logic uses more gas, the transaction reverts and the contract gets stuck. Better to store the winnerIndex and let the winner claim the prize. Subscription vs Direct Funding: subscription model is recommended for regular draws—it reduces request cost by up to 40%.

How to protect against front-running?

If the draw time is known, MEV bots can buy the last ticket in the same block as drawWinner. Solutions: commit-reveal for ticket purchases or close sales N blocks before the draw. Chainlink Automation eliminates manual calls—the contract itself calls drawWinner on a schedule or when conditions are met. This makes front-running practically impossible.

Common vulnerabilities in lottery contracts

Reentrancy during payout

We use the pull-pattern: the winner calls claimPrize(), which updates state before the transfer. This prevents reentrancy. In the code above we use push—for production contracts we always replace it with pull.

Centralization of control

onlyOwner on drawWinner is centralized. We automate the draw via Chainlink Automation, removing the risk of owner collusion with participants.

Integration with Chainlink Automation

Draw on schedule or condition without manual call:

function checkUpkeep(bytes calldata) external view override returns (bool upkeepNeeded, bytes memory) { upkeepNeeded = ( state == LotteryState.OPEN && participants.length >= minParticipants && block.timestamp >= nextDrawTime ); } function performUpkeep(bytes calldata) external override { drawWinner(); } 

Testing and audit

Tests with Foundry using a mock VRF Coordinator. Code coverage: 100% branches, 99% lines. Fuzzing on parameters (number of participants, amounts, gas limit). For testnet: Sepolia with real VRF. We guarantee quality: over 50 implemented projects, 15+ lottery systems.

What's included

• Smart contract development with VRF and Automation
• Full test coverage (Foundry, fuzzing)
• Deployment to mainnet/testnet
• Documentation and operational guide
• Post-launch support (2 weeks)

Timelines

Basic contract: 3-5 days development + 1-2 days testing. Extended (multiple pools, NFT tickets): 2-3 weeks. Audit recommended for any contract with pool >$50K. Cost calculated individually.

Contact us for a consultation on your project—we'll analyze requirements and propose the optimal solution. Request a turnkey lottery contract development with a fairness guarantee.