GomuRaffles
Simple, transparent and accessible raffles on base.
About
The problem it solves ## Issue Social platforms are often littered with promises of giveaways or raffles for people to participate in. **Participants** - Unsure of the integrity of the contest - Has to go to a random platform to join the raffle - Unsure if they've entered **Creators** - Hard to distribute their contests - Participants have to jump through hoops to get access to their raffles - Raffle creation is a hassle ## Solution Here is how GomuRaffles helps solve these issues: **Participants** - Drawing winners is completely handled by GomuRaffles, winners are stored on chain, and all logic for drawing winners is publicly viewable. - Can purchase their tickets on warpcast through a frame or through the site (if they really prefer that). - Tracks their participation (available for viewing on the website) and can be checked through the smart contract if necessary. **Creators** - GomuRaffles has a warpcast frame to support contest distribution through farcaster and the frame link can easily be copied from their raffle page. - Participants can easily purchase tickets either through the site or through the frame through a couple clicks, nothing else necessary. - Contests can easily be created on the application home page, just provide the ticket price, number of winners, and duration then click create. ## Potential Implementations - Creator runs a contest for whitelists, once complete the creator can download a spreadsheet with all the winners for easy access to their addresses. - Farcaster creator wants to promote their favorite coin, and creates a contest to raise funds for the purpose of providing liquidity. He promises .25 ETH to 4 winners, but makes it cost 0.001 ETH per ticket. 5,000 people join the raffle because the r/r is too good. The Creator raised 5 ETH for their favorite coin at the cost of 1 ETH.
How it's made
Challenges we ran into ## Challenge 1 The first major challenge I faced with GomuRaffles was **figuring out how I wanted to approach the drawing winners process**. My first concern being the issue of on chain randomness. Initially, I considered a **VRF** as I was aiming for full transparency on the blockchain. This could have been a good solution, but the **complexity involved in actually selecting a winner would make this unviable**. Not only would it be **expensive to handle in the smart contract**, but it was also going to be expensive to get these random numbers from the VRF. I also considered using **## PREVRANDAO** for a short period of time while looking at VRFs, but it would also fall in to the same bucket for mostly similar reasons. Finally, I decided the best approach would be to handle drawing winners on the server by pairing **off chain data signing and on chain verification**. Although it's not completely on chain, it removes the expensive process of drawing a winner through the smart contract and provides us with **true randomness instead of psuedo randomness** that could potentially be exploited. Additionally the code will be publicly viewable, which helps me at least provide the transparency I was aiming for. ## Challenge 2 Another big challenge I faced was maintaining parity between my database and my smart contract data. This was a completely new concept and since people had their money at risk I wanted to ensure the user had no concerns even if they left the page prior to full confirmation and updates. While this would usually be simple with a singular database, I had a hard time wrapping my head around it considering that there were two sources of truth. My two step for this (although I'm still looking for a better approach) was to track transactions, so in the case of an inconsistency I could set up a cron job to clean them up. While also using listeners to ensure that once fully confirmed the server would always pick up the final confirmed state of the data.