The problem GomuRaffles 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.

Challenges I 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.