ChainWin

The problem it solves

This project solves the problem of trust and automation in lotteries by creating a fully decentralized, transparent, and autonomous system. Traditional lotteries often require a central authority to manage ticket sales, pick winners, and distribute prizes, which introduces risks like manipulation, fraud, or human error. This DApp removes that dependency by using smart contracts on Ethereum-compatible networks to handle all aspects of the lottery.

Participants can buy tickets by sending ETH, and the winner is randomly selected using Chainlink VRF, which provides verifiable and tamper-proof randomness. The process is fully automated using Chainlink Automation (Keepers), which triggers winner selection once certain conditions are met, without requiring any manual intervention. The winner automatically receives the prize, and the lottery resets for the next round.

Challenges we ran into

While building the decentralized lottery DApp, I faced several hurdles, particularly around Chainlink VRF integration and Automation:

Getting Verifiable Randomness (VRF) to Work Properly

Issue: Initially, the contract wasn’t receiving the random number from Chainlink VRF. The fulfillRandomWords() function wasn’t being called, which broke winner selection.

Cause: I had misconfigured the subscription ID, Key Hash, and VRF Coordinator address in the deployment scripts.

Solution: I carefully reviewed the Chainlink documentation, created a proper subscription in the VRF Subscription Manager, added the contract as a consumer, and updated all values in the scripts. After redeploying, the VRF started returning valid random numbers reliably.

Automating the Lottery Draw with Chainlink Keepers

Issue: The automated draw wasn’t triggering because checkUpkeep() always returned false.

Cause: My conditions for upkeep weren’t aligning correctly with the contract state (time interval, player count, and balance checks).

Solution: I logged the contract state and carefully adjusted the logic in checkUpkeep() to accurately reflect when the lottery should run. After that, Keepers successfully triggered performUpkeep().

Frontend–Smart Contract Integration

Issue: Connecting the Next.js frontend to the deployed contract was tricky, especially for reading live contract state and sending transactions.

Solution: I leveraged ethers.js with proper provider, signer, and contract instances, and tested each function incrementally. This approach made the frontend responsive and reliable.