Provably Fair
Last updated
Last updated
Megapot is a decentralized jackpot running on the Base network. We utilize Pyth's randomness entropy protocol for generating random numbers and determining the winner of our jackpots.
Visit stats.megapot.io, go to the Past Rounds section, and next to each jackpot amount is a link that either shows Player -> or LP -> depending on who won that day. Click the link in the red box below to view the public blockchain transaction that determined the winner.
The first log is RevealedWithCallback and is called directly from the Pyth Entropy Base contract for generating random numbers: 0x6E7D74FA7d5c90FEF9F0512987605a6d546181Bb. You can confirm this address in Pyth Entropy docs page. This verifies that the random number used for the drawing was provably random.
Scroll down to see the third event, JackpotRun, which shows the address of the winning player next to winner! If the winner is 0x0000000000000000000000000000000000000000, then no players won that day. The majority of time, LPs will win, since they buy the vast majority of tickets (typically, 95-99.5% of tickets).
Here are two examples of a player winning vs. no players winning that day:
This is a technical deep dive into how the jackpot works and how to verify the results. If you are looking for a quick way to verify the results, use the TL;DR version above.
Our jackpots will have one of two outcomes:
A player wins the jackpot
The LPs collectively win
When the jackpot runs, we feed the contract a random string to use as part of a 2 party randomness generation. Pyth consumes this string and also generates a random string for entropic use, which creates trustless entropy ingestion. We don't know what string they will use, making it impossible for us to rig the random number generated in anyones favor. You can read more about the Pyth protocol design here for an in-depth look at how it works.
Once Pyth generates the random number, it calls back to the contract with the winning ticket number. The contract checks to see who is holding that specific ticket. It will either be an individual player, or the LPs collectively.
Our LPs provide liquidity to fund the jackpot. An LP deposits USDC and sets a percentage of that to be in range for the jackpot. This is what they are risking and it is included in the jackpot.
Since we use ticket sales to pay out to LPs, we use a basis points system for our tickets. For the contract, 1 ticket is actually equal to 10,000 ticket units. Our LPs and ticket referrers earn a cut of each ticket sale for providing the jackpot and rewarding partners for bringing more players to the jackpot. This fee is 30%, or 3,000 ticket units (30% for LPs if no referrer or 20% to LPs and 10% to the referrer if referred). Each ticket a player buys results in 7,000 ticket units. So if a user buys 10 tickets, they get 70,000 ticket units. 5 tickets would be 35,000 ticket units, etc.
At the start of the jackpot, our contract determines the total amount of LP funds in range and that is what is up for grabs to players who buy tickets. The easiest way to think about this is that the LPs pre-purchase all the tickets for the round. When a ticket is bought, it comes out of that pile of pre-purchased tickets.
For this article, let's assume a jackpot of $100,000 USDC. This means the LPs collectively have supplied 100,000 tickets, or 10,000,000,000 ticket units.
The first player to buy tickets gets the very bottom of the pile, let's say they buy 10 tickets. They are assigned the first 70,000 ticket units (100,000 - 30,000 fee bps). The next player buys 5 and gets ticket units 70,001 - 105,000.
Let's assume players buy 1,000 tickets in total or 70,000,000 ticket units. This means players hold tickets 1 - 70,000,000.
When the jackpot draw happens, the contract will select a random number between 1 and the total ticket units. If the number is 1-70,000,000, the player with that ticket unit wins. If the number is 70,000,001 or higher, the LPs collectively win.
