Positive expected value lotteries

👋
This proposal is out of date. Play it now at pevl.xyz! It has a liquidity provider mechanism for building, and maintaining, large jackpots.

TLDR: Every lottery is negative expected value, since fees are taken from the prize pool. This lottery is a protocol, which runs freely on a blockchain, and takes no fees from the prize pool, which makes it neutral expected value. To make this positive expected value, users are rewarded for participating in the lottery with revenue share. Revenue comes from yield on the money in the lottery pool. The frontend blocks US users to stay legally compliant. As a permission-less protocol, builders trust building on it since they can’t be de-platformed, and can even take on the risk to allow US users.

How does this compare to existing lotteries?

Why are existing lotteries inefficient? Because all of the following is taken from the prize pool

  • Real world expenses like scratch cards or payments to brick and mortar locations
  • Demand generation by running advertisements since many lottery competitors
  • Business running the lottery needs a way to profit

Our lottery system - let’s call it lottery.tech for now - will be efficient by nature of blockchain:

  • Lottery has no cost to run as it is a decentralized blockchain protocol
  • No user acquisition cost and competitors. Rewards are provided for users who refer lottery entrants. Protocol is structured such that competitors will want to build on top of protocol, rather than compete.
  • Team monetizes independently of the lottery pool via the frontend

Why this is important and valuable

People will always want to gamble and speculate. However, crypto is full of scams, casinos take a large margin, and lotteries/scratchers take even larger margins. Let’s return that margin to the user.

This is uniquely crypto native, has true product-market fit, and can be 10x better than non-crypto alternatives. Building as a protocol means others will contribute rather than compete, speculation is human nature, and positive expected value is infinitely better than rake.

Lottery Components

  • Onchain lottery contract
    • Drawing commences every 24h, users have a proportional chance based on contribution.
    • No fees are taken from the prize pool, so users’ expected value is neutral, aka what they put in.
  • Points program
    • Users get points for participating in the lottery and referring other users.
    • A leaderboard gamifies the experience.
    • Points get a share of revenue from the yield generated from money in the prize pool, as well as potentially, blockchain-based incentives and governance. This makes participating in the lottery positive expected value.
  • Trusted frontend
    • Team makes money by monetizing the frontend with onramp fees and swap fees. Focus on being doxxed with a transparent business model, vs undoxxed shady competitors
    • Others are encouraged to build competing frontends

Building on BLAST L2

  • Quick primer on BLAST: Stablecoins automatically rebase to earn yield, gas fees from the protocol are returned to developers, and they are airdropping tokens to users and developers
  • Thus, deposits into a lottery contract, before the lottery is drawn, earn yield. This can be the source of revenue for token holders.
  • Gas fees allow developers to make money even if someone else’s frontend drives traffic.
  • Lastly, there is a sizeable developer airdrop. Offering a share to token holders incentivizes product usage, which grows developer airdrop, a virtuous cycle.

Hypotheses

  • Users use this because if you’re going to gamble, it’s the highest ROI way to do it
  • Users will use us partially because there is an airdrop
  • Positive EV is a strong selling point for users. Thus, it’s important to keep it positive, even if a small magnitude (+0.01%).
  • Points let us tilt revenue share towards early adopters and referrals to build a network. If we rewarded purely based on yield, there isn’t enough incentive to get the network off the ground.
  • Yield revenue share (0.014%/day at 5%/year) isn’t enough to motivate users. We expect some combo of Blast points share (developer airdrop share), gas fee share, and more gamification (leveling / NFT system) can get us there
  • In the short term to win the hackathon, gamification and ease of user experience are more important than building composability or non-upgradability of protocol
  • In the medium/long term, frontend builders/developers want to build on top of us because:
    • Protocol is composable so it satiates 95% of use cases of raffling/gambling needs, with the ability to easily plug into liquidity, reduces time/resources needed for development or user acquisition
    • Protocol is non-upgradeable so there are no deplatforming concerns

Implementation Details

Onchain lottery contract

  • When the lottery reaches a predetermined time, eg. every 24h, a lottery drawing commences and users have a proportional chance based on how much they contributed.
  • Provably fair, audited, etc.
  • Every transaction has a referrer field
    • On a non-lottery.tech website, that website can set its own wallet as referrer
    • On lottery.tech website, users can generate a referral code which then sets the referrer to their wallet

Contract does not have a fee switch

Points

  • Users gain points for lottery participation and referrals. Points are tied to revenue generated, and points convert to tokens that represent ownership and revenue share.
  • Points for participation
    • Users gain points for participating in lotteries based on time and amount contributed, since this determined amount of BLAST yield received.
    • Points are weighted towards early adopters
    • No limit on points provided
  • Users gain points for referring users to participate in lotteries. It’s possible for another frontend to use the same protocol, and use their wallet address as the referral.
    • Build a leaderboard like Blur and Blast.
  • Users gain points for using frontend monetized features.
    • Points are given based on onramp or swap fees, since those generate revenue
  • Points are not tradeable
  • Points allocation changes as the business matures - at the beginning it may be for participation, then for referrals, then for monetization features

Unique go-to-market

  • First three months: We allow regular users to get access to developer airdrop BLAST airdrop.

Frontend allows anyone to enter a lottery, whether they are in crypto or not

  • Easy crypto way to deposit with native wallet. Anything that’s not USDC will be swapped into it. If you have a crypto wallet, the lottery $ is sent there
  • Fiat onramp to deposit. A wallet is created based on your social via Privy. Frontend will charge the user at cost for what we pay for Privy.
  • Block US users since they aren’t legally allowed to gamble outside of state-sanctioned lotteries. If another frontend wants to take the risk to allow US users, they can do so.

Archive

Differing approaches

Approach 1: Fee switch

  • This is a traditional hyperstructure fee switch like the Uniswap fee switch. Token holders can vote to turn on a fee switch, to have 0.3% of funds sent to the treasury. Tokenholders would be able to claim a proportional amount of funds.
Details

Onchain lottery contract

  • When the lottery reaches a predetermined time, eg. every 24h, a lottery drawing commences and users have a proportional chance based on how much they contributed.
  • Provably fair, audited, etc.
  • Every transaction has a referrer field
    • On a non-lottery.tech website, that website can set its own wallet as referrer
    • On lottery.tech website, users can generate a referral code which then sets the referrer to their wallet

Contract has a fee switch

  • Fee switch takes a maximum of 0.1% of the lottery amount, and it is sent to the treasury. Eg. A $100 lottery pool now pays $99.90, $0.10 goes to treasury
  • Fee switch can only able to be enabled when 10k wallets have participated in lotteries.
  • After fee switch occurs, a snapshot is taken at every lottery conclusion and the proportional fee is claimable by token holders

Points

  • Users gain points for participating in lotteries. Only X points are given out per day. Depending on how much they wager, they get a proportional/quadratic amount of points. Thus, it pays to be an early lottery player.
  • Users also gain points for referring users to participate in lotteries. Build a leaderboard like Blur and Blast.
  • Users lastly gain points (uncapped) for using onramp or swap, since that generates revenue
  • Points are not tradeable
  • Points allocation changes as the business matures - at the beginning it may be for participation, then for referrals, then for monetization features

Tokens

  • Every so often, points get converted into tokens
  • Tokens get 50% revenue share from the frontend
  • If fee switch is turned on, tokens get to claim $ from lottery revenue

Frontend allows anyone to enter a lottery, whether they are in crypto or not

  • Easy crypto way to deposit with native wallet. Anything that’s not USDC will be swapped into it. If you have a crypto wallet, the lottery $ is sent there
  • Fiat onramp to deposit. A wallet is created based on your social via Privy. Frontend will charge the user at cost for what we pay for Privy.
  • Block US users since they aren’t legally allowed to gamble outside of state-sanctioned lotteries. If another frontend wants to take the risk to allow US users, they can do so.

Approach 2: Leverage BLAST L2’s native yield

Details

Differences from Approach 1 are highlighted in orange

Onchain lottery contract

  • When the lottery reaches a predetermined time, eg. every 24h, a lottery drawing commences and users have a proportional chance based on how much they contributed.
  • Provably fair, audited, etc.
  • Every transaction has a referrer field
    • On a non-lottery.tech website, that website can set its own wallet as referrer
    • On lottery.tech website, users can generate a referral code which then sets the referrer to their wallet

Contract does not have a fee switch

Points

  • Users gain points for lottery participation and referrals. Points are tied to revenue generated, and points convert to tokens that represent ownership and revenue share.
  • Points for participation
    • Users gain points for participating in lotteries based on time and amount contributed, since this determined amount of BLAST yield received.
    • No limit on points provided.
  • Users gain points for referring users to participate in lotteries. It’s possible for another frontend to use the same protocol, and use their wallet address as the referral.
    • Build a leaderboard like Blur and Blast.
  • Users gain points for using frontend monetized features.
    • Points are given based on onramp or swap fees, since those generate revenue
  • Points are not tradeable
  • Points allocation changes as the business matures - at the beginning it may be for participation, then for referrals, then for monetization features

Unique go-to-market

  • First three months: We allow regular users to get access to developer airdrop BLAST airdrop.

Frontend allows anyone to enter a lottery, whether they are in crypto or not

  • Easy crypto way to deposit with native wallet. Anything that’s not USDC will be swapped into it. If you have a crypto wallet, the lottery $ is sent there
  • Fiat onramp to deposit. A wallet is created based on your social via Privy. Frontend will charge the user at cost for what we pay for Privy.
  • Block US users since they aren’t legally allowed to gamble outside of state-sanctioned lotteries. If another frontend wants to take the risk to allow US users, they can do so.

Lottery - hyperstructure
Lottery - BLAST L2
Onchain lottery contract
No fees taken from prize pool If fee switch enabled, 0.3% of pool is sent to treasury
No fees taken from prize pool, ever
Points
Based on amount wagered Referrals get points
Based on amount wagered Referrals get points
Tokens
50% revenue share from frontend If fee switch enabled, claim fees
100% revenue share from BLAST yield 50% revenue share from BLAST developer airdrop
Team
50% revenue from frontend
100% revenue from frontend 50% revenue share from developer airdrop Gas revenue share from protocol
Unique GTM
Just points - won’t stand out.
Allow regular users to get access to developer airdrop allocation

I prefer approach 2. BLAST’s incentive structure uniquely allows for a sustainable “positive expected value” lottery. It also allows for a strong go-to-market angle with a developer airdrop revenue share.

However, the first approach will likely lead to a higher token value, since 0.3% of all lottery pools is significant.

I think it’s feasible to have an approach that combines both, but am concerned that the incentives get too complicated and the messaging isn’t clear - “positive expected value” lottery is a strong value prop.

Comparison to PoolTogether

PoolTogether is a prize-linked savings account, whereas lottery.tech is a real lottery.

Lottery.tech
PoolTogether
Moat → Impact
Lottery pool liquidity → Larger prizes
Lottery pool liquidity → Larger prizes
How team makes money
- Token allocation - Trusted frontend monetization (onramp, swap fee) - Protocol gas revenue share
- Token allocation
Incentives for users
- Revenue share from yield
Governance to choose pools
Comparison to other gambling apps

Need to research how these work. I know there are a ton out there.

Analogy to Uniswap, Blur, and LooksRare
Uniswap
Lottery.tech
Blur
LooksRare
Moat → Impact
Liquidity Pool liquidity → Better prices
Lottery pool liquidity → Larger prizes
NFT listing, bids, and lending liquidity → More selection, better prices
Raffle pool liquidity → More games to play, larger prizes
How team makes money
- Token allocation - Trusted frontend monetization (onramp, swap fee)
- Token allocation - Trusted frontend monetization (onramp, swap fee) - Protocol gas revenue share
- Token allocation
5-15% of prize pool
Incentives for users
None now
Points system to gamify and incentivize users to use the product and refer users
Points system to gamify and incentivize users to use the product and refer users
Points (”Gems”)
Incentives for token holders
- Governance over fee switch, etc. - Theoretically treasury can be deployed for users
- Revenue share from yield
- Governance over fee switch, etc. - Theoretically treasury can be deployed for users
Revenue share
Audience
- Crypto-native only use case (tokens) - Mainstream users can onramp
Lottery is understandable by everyone, crypto native AND non-crypto users
Crypto-native only
Crypto-native only
Long-term, how we compete

We have a moat, incentivize others to build on top, and profitability is independent of lottery.

  • Our moat is liquidity. Lotteries will finish very quickly since everyone sends their lottery entries to our contract. Others who fork our lottery will not have the same demand, so their lotteries will take longer, and users will have their money stuck waiting.
  • Referral rewards incentivize others to build on top of us. If you build a frontend and use our protocol, you can set a referrer field to your wallet and reap the benefits.
  • Profitability is from a trusted frontend, and actions that users take (eg. onramp). Thus, for a crypto native, we offer best prices, while for non-crypto natives, we offer peace of mind.

Inspired by LooksRare Raffle and Games

LooksRare has games that are provably fair, and take 5% for simple games (Raffle, Poke the bear, YOLO) and 15% for complex games (Infiltration). These are a hit with people. I think we can simplify it, remove the fee, and make it accessible to non-crypto users.

Early Feedback
  • I think lotteries have super strong product market fit. Both in crypto and out of crypto. So if you execute one that is both superior from a financial perspective and better designed I don't see why it wouldn't work well. I think the Hyperstructure back-end / monetized front-end is a good model though.
  • I love the approach you’re taking - transparency and positively aligned incentives between user and platform are the nr 1 thing missing from crypto gambling platforms. Key to win is a killer GTM imo. Key to win VC funding would be the promise of building a scalable platform for many of these gambling experiences. High level, I feel that you could win this entire vertical by just 1. Being doxxed 2. Being transparent 3. Doing what’s best for users and playing for scale. Real pain point, real scale, real venture outcome.
Previous content

Comparison to PoolTogether

PoolTogether is a prize-linked savings account, whereas lottery.tech is a real lottery.

Lottery.tech
PoolTogether
Moat → Impact
Lottery pool liquidity → Larger prizes
Lottery pool liquidity → Larger prizes
How team makes money
- Trusted frontend monetization (onramp, swap fee) - Initial token allocation
- Token allocation
Incentives for users
- Governance over fee switch, etc. - Built in Revenue share
Governance to choose pools

Comparison to other gambling apps

Need to research how these work. I know there are a ton out there.

Analogy to Uniswap, Blur, and LooksRare

Uniswap
Lottery.tech
Blur
LooksRare
Moat → Impact
Liquidity Pool liquidity → Better prices
Lottery pool liquidity → Larger prizes
NFT listing, bids, and lending liquidity → More selection, better prices
Raffle pool liquidity → More games to play, larger prizes
How team makes money
- Trusted frontend monetization (onramp, swap fee) - Initial token allocation
- Trusted frontend monetization (onramp, swap fee) - Initial token allocation
Initial token allocation only
5-15% of prize pool
Incentives for users
None now
Points system to gamify and incentivize users to use the product and refer users
Points system to gamify and incentivize users to use the product and refer users
Points (”Gems”)
Incentives for token holders
- Governance over fee switch, etc. - Theoretically treasury can be deployed for users
- Governance over fee switch, etc. - Built in Revenue share
- Governance over fee switch, etc. - Theoretically treasury can be deployed for users
Revenue share
Audience
- Crypto-native only use case (tokens) - Mainstream users can onramp
Lottery is understandable by everyone, crypto native AND non-crypto users
Crypto-native only
Crypto-native only