NoLo
Don't YOLO. Just NoLo
About
The problem it solves Traditional DeFi lotteries and gambling websites are risky and can make you lose your savings if you don't win. Yield farming is technically complex and lacks compelling user experiences. Also if your supplied amount is small, the yield will be not worth waiting for it. We though why not combine lotteries and yield farming. ***This is how we came up with NoLo*** NoLo is a yield based lottery where users can deposit funds and get tickets for the lottery, which are pooled into a yield-generating pool by Aave. After the lottery time period has passed, the winner doesn't get all the deposited funds, but instead they gets the yield generated by those funds. We used Chainlink Automation to trigger winner selection which further uses Chainlink VRF to get a random number. Using that random number we select a ticket. The owner of that ticket then automatically gets the yield generated after it has been withdrawn from the Aave pool.  The remaining funds are safe in the pool and ready to generate yield unless any user wants to withdraw their funds. The more the number of tickets purchased, the more is the yield generated. ***NoLo is currently deployed on Ethereum Sepolia testnet now !***
How it's made
Challenges we ran into Our main challenges where running into gas issues trying to select a winner and distrubute funds from within **fullfillrandomWords()** so we moved the logic to its own function but then had issues with the async nature of the vrf call. **The Problem:** Chainlink VRF doesn't work like a normal function call. When you need randomness, you can't just call **getRandomNumber()** and get an instant result. Instead, you have to: 1. Request randomness in one transaction 2. Wait (could be minutes) 3. Receive the random number in a completely separate callback transaction ***Why this was hard:*** - The contract needs to "remember" that it asked for randomness - Chainlink Automation keeps calling the contract regularly, but you only want to act when VRF is ready - You need to prevent duplicate requests or processing the same result twice - The contract state must stay consistent across multiple transactions ***Our Solution:*** We created a state machine using a **selectWinner** boolean flag:  Then we had gas issues with multipe calls to perform upkeep which were solved by increasing the **performUpkeep** gas limit.