Summary – Run a pro football survivor pool on Ethereum. Place the entry pool into the MakerDAO or a similar interest bearing DApp for the duration of contest. At the end, release the principal to the winner(s), keep the earned interest.
Inspired by PoolTogether, we invent & model out a consumer product using the MakerDAO DSR as our primary revenue source. Does an interest bearing DApp provide enough revenue to power a decentralized survivor pool? If you don’t know what any of that last sentence means, don’t worry, I’ll explain.
We all know the premise of Thunderdome. Two men enter, one man leaves. It’s a fight to the finish where the reward is your life. What about a tontine? It’s an investment scheme where the annuity payouts increase as participants die off. In the end, one person remains and they get all the money.
As Tina Turner once sang, what’s
love pro football got to do with this? A football survivor pool operates like a tontine. Players pay an entry fee that goes into a pooled pot. They pick one team a week to win. The catch is they can only use a team once. Get the pick right & you move on with fewer future choices. Make the wrong pick & you’re out. The last person standing wins the pool.
Ok, so where’s the DeFi in all of this? Also, help me out there. What’s DeFi?
DeFi stands for decentralized finance. It’s a movement to bring traditional financial services onto the blockchain in a decentralized manner. DeFi replaces decision making organizations with code & democratizes finance for everyone. Learn more here.
For this idea, we’re going to use MakerDAO which has been called the central bank of DeFi. Specifically, we are going to use their Oasis App where we’ll deposit our pool entry fees. MakerDAO operates a collateralized lending facility where you can deposit DAI & earn interest on it. The interest rate is known as the DSR (Daily Savings Rate) & is determined by MakerDAO voting tokens.
Here’s a mockup of the ThunderDome user interface. It’s simple enough. The UI contains pool stats, your past picks, this week’s schedule & a form to make your next pick.
Defining a Survivor Pool
Disclaimer: These are product specs. I’m using business logic & am not qualified to write tech requirements for smart contracts.
Each pool is open to N number of players & costs X amount of money to enter. An player is defined as an Ethereum wallet address & each pool allows one entry per wallet.
For this example, a pool allows 1000 players & charges a $25 entry fee (paid in DAI). A pool is open until one of two conditions happens:
- The 1000 entrant limit is reached
- The limit is not reached, but it’s 1 hour before the pool starts.
Let’s assume we have 1000 players & the pot is $25,000.
Here’s a diagram outlining how the pool is structured & where funds would flow:
Entry fees are paid into an Ethereum smart contract that controls the pool. The smart contract places the pool into a MakerDAO Savings Account. The money will sit there earning interest until a liquidation event takes place. At that point, the smart contract retrieves the pool funds, sends the principal on to the winning wallet address(es) & the interest earned to the pool operator.
Each entrant starts with 32 teams they can use. Each team may only be used once.
On Week 1, a player is presented with the week’s schedule & has to choose one team to win their game. Players can pick any team in any game. The pick is registered as a vote on the blockchain & the team selected is removed from player’s list of future choices.
For example, I pick New England to beat Cincinnati. New England wins. I advance to Week 2, but I cannot use New England for the rest of the contest.
Everyone who picks wrong in Week 1 is eliminated from the pool.
Everyone who picks right survives & moves on to Week 2. They now have 31 teams to chose from. This process repeats week after week. Winners advance with fewer teams left to choose from. Losers are eliminated.
At some point, almost all entrants are knocked out & it’s time to pay the pot out to winning player(s) in a liquidation event.
2 events can trigger liquidation:
- 1 player remains & is the winner
- The season ends & the pot is evenly distributed to all remaining active players
*Note: Some survivor pools allow voting to split the pot prior to the season ending. This could be done here as well.
When the liquidation event occurs, the pool’s smart contract retrieves the accrued amount from the MakerDAO & distributes it in this manner:
- The principal is sent to the remaining players who are declared the winner(s)
- The interest earned is given to ThunderDome’s operator
Let’s say in our case, there’s a single winner, the pool lasted 17 weeks & the DSR rate is 8%. The winner receives $25,000 & ThunderDome receives $635 for running the pool.
The product is relatively simple. Most of the work is in the initial build of the contracts & UI, then ensuring they are secure and bug free. Once launched, ongoing maintenance is minimal. Pools need to be setup by deploying copies of the contracts, schedules need to be loaded & adjustments need to be made if games are suspended.
For ThunderDome to work, the operator needs to run multiple pools. A single pool will not generate enough revenue. You also don’t want too many entrants into a pool or it will discourage others from joining.
The knockout nature of a survivor pool & capping the number of entrants per pool means an operator can run many simultaneous pools.
Below, I’ve modeled out a business where an operator is running 50 pools at the start of the season. If you remember above, each wallet address is limited to one entry per pool. However, we’re allowing wallet addresses to enter multiple pools per week. Given how hard it is to win a survivor pool, this happens often.
I’ve also modeled new pools starting each week of the season. This assumes two things:
- Some people knocked out in Week 1 enter a new pool in Week 2
- New players discover ThunderDome
So how does this business look? Let’s start with our assumptions:
- Entry Fee: $25
- Week 1 Entrants: 50,000
- Entrant Churn: 25%
- MakerDAO DSR: 8%
- Probability of Max Pool Duration: Starts at 90% & increases each week.
Note: When I modeled this the DSR was at 8% but has been subsequently reduced to
4.5% 0%. OMG! What a weird couple weeks & (spoiler alert) a very cruel confirmation of my conclusion. Fear not though, there’s a solution that salvages this idea!
Entrant churn means that I expect 25% fewer people to enter new pools as the week before. So if 50,000 enter new pools in Week 1, I expect only 37,500 to enter Week 2.
MakerDAO DSR is the interest rate the pool pot earns while the contest is running.
Max Pool Duration – We need to determine the time unit T for our compound interest calculation. The likelihood of a pool running its full length is determined by a combination of entrants & weeks. I’m swagging this model variable.
So does this product idea make money?
In this example, our pool operators had a gross margin of $95,643 after running one season’s worth of pro football survivor pools. That assumed they attracted a lot of initial entrants & generated strong entrant volume as the season went on.
There’s no customer acquisition or development costs modeled. It’s very likely that one or both are significant & that ThunderDome runs at a loss in year 1.
Evaluating The Idea
I loved the idea of using the DSR interest rate as an engine to create a product & wanted to see if I could come up with a compelling use case. A survivor pool is a strong consumer offer that if marketed right could generate a large amount of volume.
Should someone create Thunderdome? It depends.
- Simple product to build & manage
- Survivor pools are popular ways to bet
- Development is the only hard cost in the business
- The concept extends across other sports & competitions
- Lack of KYC in DeFi lends itself well to gambling space
- Not defensible. Very easy product to clone
- As modeled above it’s entirely dependent on the DSR interest rate or similar products
- High risk for low return – Picking up nickels in front of a steamroller
- Would require regulatory approval in the US across multiple states to operate traditionally
Personally, I would not create this business for regulatory reasons. As a US citizen, I have no interest in the work it would take to get ThunderDome approved because it’s not a defensible product. A dozen people offshore will copy the model & create competitors which don’t have the same cost burden of compliance.
There’s also an element of picking up nickels in front of a steamroller here. For this business to be meaningful, it has to really scale. The model above assumes nearly 200k entrants placing almost $5 million in custody. The product operator is only getting $95k in gross margin for taking that risk. A one time hack or exploit of the smart contracts powering ThunderDome would be catastrophic for the service.
Finally, a big reduction in the DSR rate (yeah it went to 0%) would also really hurt. An opportunistic operator can spread their risk across other interest bearing DApps, but realize this space is very young & risky.
Is the MakerDAO DSR Enough?
Technically? Yes. If you had a small team, wanted to build this primarily as a labor of love & did not spend on customer acquisition, then the DSR would provide enough revenue to operate the service & distribute some money.
Practically? No. I would not recommend an organization build this only relying on the DSR unless they had a large customer base they could crossmarket to. (Basically decentralized sports books should do this & no one else.) The biggest challenge here is acquiring customers. Could you get 200k entrants over a season spending less than $95k & pay for the initial build? Assuming you’ve scaled, can you retain those players once ThunderDome clones come to market? Those are some tough challenges.
How Do You Make the Economics Work?
Charge a vig.
If the pool operator took 5% of the pot for operating the service, then revenue goes from $95k (interest only) to $345k (interest + vig).
The benefits of charging a vig:
- Provides a guaranteed revenue stream which can fund early customer acquisition
- Insulates against DSR rate changes during the season
- Is a common in sports gambling. Customers would accept it
- Can be adjusted as entrants scale, competition emerges & interest payouts fluctuate
This is a sketch. I’ve glossed over acquisition, branding (bitching black & white logo though), development & auditing costs in order to focus on the product & a single revenue source. The product lends itself well to Ethereum & DeFi. As demonstrated with the vig, there’s plenty of ways to tweak the product to create a viable model.
ThunderDome has legs to it, but it cannot rely on the DSR alone. Since, there’s a lot of room to innovate on this concept, it wouldn’t surprise me to see survivor pool(s) running on Ethereum come the fall.
Rights / Intellectual Property
I waive all rights to the ThunderDome idea, name, logo, concept, etc.. I only ask that you acknowledge the idea as Blockstar’s. This was a thought exercise & a chance to dust my product skills off after a long break from designing.
Personally, I was hoping to find a use case beyond sports betting to demonstrate the utility of building products using the MakerDAO DSR, but failed to. I’ll keep thinking about it & maybe the light bulb goes off later on.