Scaling prediction markets via pooled liquidity & market creation via oracles
A guest post by the Azuro team.
In this article, we are going to examine the issues faced with prediction markets today and how they are affecting decentralized betting. Furthermore, we will look at our solution deploying innovative liquidity allocation and market creation that we believe will revolutionize decentralized betting.
Existing solutions today are built on layer 1 and 2 EVM compatible chains such as Ethereum and Polygon, and they have made progress to speed up transactions and reduce gas fees. However many problems beyond transaction cost & speed remain. The three prominent teams that have built prediction markets are Gnosis, Augur, and Polymarket. Gnosis has made the conscious decision to pivot away from prediction markets and focus on other web3 solutions but Augur and Polymarket remain operating today. Let’s dive a little deeper into how they have been built and what is preventing them and other similar solutions from scaling.
Augur & Polymarket
Augur and Polymarket started strong and gained a following with the exciting new propositions they were offering to the space. Polymarket focused on bringing less conventional markets to their users, such as the predicted floor price of a Crypto Punk or the number of COVID cases in the USA by Christmas day. This is a novel case for prediction markets but still lacks depth with usually under 100 markets live at any given point. Augur has attempted to provide a betting experience centered around sports but has lost all momentum and there’s hardly any market to bet on there today. Data taken from Dapp Radar at the time of writing shows Augur has only processed 1 transaction in the last 30 days (as of 22 Dec 21).
Augur and Polymarket share a lot of the same core architecture in their solutions, both using peer-to-peer betting a.k.a. betting exchange as the backbone. Adopting the P2P model has led to the same complications and limitations for Augur and Polymarket which are key factors in their inability to scale.
Problems with Prediction Markets
Prediction markets are currently the only form of decentralized betting. Many attempts have been made to make them work, but ultimately they have failed to deliver on the fundamentals of betting (plenty of events, markets, and competitive odds with multiple betting options). Three main areas where the current solutions have failed are:
- Liquidity
- Product Depth
- UX
Liquidity
Liquidity being an issue is easy to understand when you consider the P2P model. Exchange betting removes the bookmaker and players themselves provide liquidity, set odds, and create markets. Prediction markets being peer-to-peer inhibits truly efficient liquidity allocation. Liquidity providers on prediction markets are not LPs like in the rest of DeFi (i.e. stake tokens and earn yield) but the burden of creating each betting market falls on the LPs. They have to start markets manually, set the odds and seed liquidity to each market they create. Then, that liquidity is market-specific, which means the LP carries betting risk connected to that betting market.
All of that comes down to a heavy lift expected from LPs, both in terms of the manual effort and the betting risk they need to take. LPs must be savvy and have a great understanding of the event or could face losing out to the bettors. It is the combination of risk, knowledge and manual creation of markets that limits the number and level of effectiveness of liquidity providers. As a result — there’s hardly any liquidity, and therefore — hardly any betting markets for people to bet on. And finally, that means — there’s practically no betting.
Product Depth
The architecture of prediction markets makes it harder and the UX much clumsier for bets with 3 or more outcomes. And that is a big dowfall. Moreover, the current use of peer-to-peer architecture inhibits the product depth that can be achieved in other ways, too.
For example, one of the most popular types of bets players like to place (and the most popular amongst casual players) is an “accumulator”, where players place multiple bets on the same slip and therefore get a much larger potential pay-out if all bets in their slip are won. Peer-to-peer doesn’t really allow for accumulators due to how the markets are created, which is a huge drawback for the betting experience and features players are used to.
UX
In traditional betting, players are accustomed to finding an event, checking the odds, placing a bet, and receiving a slip that tells them their potential winnings. This is not the case with prediction markets. The UX is clumsy, and far from what bettors are used to. Odds as not represented as expected, such as fractional or decimal, instead, players must buy tokens to back a certain outcome. The token price will change based on the circumstances around the event and tokens have to be sold back to realize a profit. Traders will understand this concept as it is somewhat similar to futures trading, but this approach is rather inappropriate for drawing in sports bettors from web2.
Is There a Viable Solution?
Azuro is building a protocol to address the above key issues while retaining decentralization. The different core architecture is utilized to achieve this, revolving around a peer-to-pool liquidity allocation model and market creation via oracles. By rebuilding almost from scratch the goal is to address the issues with liquidity, event/market depth, odds competitiveness, product depth, and UX.
Liquidity Provision
Core to Azuro is the shift towards peer-to-pool. Betting markets share a common pool. The common pool ensures all markets are liquid from the outset. The pool is rewarded with a share of the earnings, which are split amongst LPs and other participants in the ecosystem. A common pool has advantages for liquidity providers. If liquidity is provided for only one market, LPs face a similar risk to bettors as pointed out previously. Spreading liquidity over multiple events reduces the risk for the LPs dramatically and increases the consistency in yield returned to the pool.
Anyone can provide liquidity, and the process is easy to understand. Users can decide which pool to stake, based on token preference or APY and, in return for their staked token, receive LP tokens. The LP tokens represent the value of their initial stake. The value of the tokens will increase based on the performance of the liquidity pool vs the betting. No matter how low-risk staking is, there is always the possibility that bettors could outperform the pool, and should this happen, the LP tokens will decrease in value. Yet, in the simulation models, and also using testnet data, after a certain amount of bets, the probability of the pool realizing profit leans towards 100%.
Furthermore— the proposition for LPs is on par with the rest of DeFi in terms of UX (i.e. stake and earn), but the yield is generated in a unique way uncorrelated to the broader DeFi state or even state of financial markets in general. Therefore — the proposition can be lucrative and appealing enough to attract very significant liquidity which is necessary for deep betting lines on numerous events and markets.
Liquidity Allocation
Although there is a common pool, liquidity is not simply divided evenly amongst all markets. This would lead to idle liquidity on unpopular events and less liquidity for the more popular events. Azuro protocol tackles this via popularity ratings for sports, leagues, teams/players, and markets and those can be updated by the DAO.
Creation of Events, Markets, and Odds
New events are added via oracles and require no human interaction or manual creation. Events are initialized several days before the event is due to commence, by importing real-world data via oracles. This eliminates the need for sophisticated, heavy-lift market-making which would be required on the peer-to-peer model in order to achieve hundreds or even thousands of events, and even more underlying betting markets at any point in time.
The DAO has the ability to decide which sports/leagues will be available on the protocol.
Initial sports available on testnet include:
- Football — Top Leagues from England, Spain, Italy, Germany, Portugal, Russia
- Esports — CS:GO, DOTA2
More sports like League of Legends, Valorant, MMA (UFC, Bellator, ACA, One Championship, PFL) & Tennis (Major Tournaments) are to be proposed for inclusion.
More — the application of the above architecture doesn’t necessarily restrict the creation of custom pools (similar to predictions markets today) which would be supportive of having cultural or political or more unorthodox events which may be created and seeded by LPs in a way similar to how it is possible already with existing solutions.
Improved Product
The architecture used though allows for a much-improved product for players and can bring some features that the players are familiar with and comparable to centralized betting, such as:
- Multiple outcomes — bets on 3-way or even more outcomes will be possible
- Accumulator Bets — Players will be able to place multiple bets on the same slip to create accumulators.
- Fixed Odds — Odds are fixed at the time of the bet being placed. There may be a certain percentage of slippage which could adjust the odds, but the player will set this before placing the bet.
- Non-Fungible Bets — Bets will be non-fungible and will be immutable after being placed on the smart contract. This is an improvement on prediction markets, where players can sell part of their shares, meaning the bet is fungible. Players will also have the option to mint their bets as NFTs opening up opportunities to trade bets pre-game, in-game, or even after the game as collectibles.
In summary, we believe Azuro’s innovative approach to liquidity staking, liquidity allocation, and market creation brings a potent solution to power thousands of events and even more betting markets with increased product depth and classic UX particularly appealing to sports bettors.
Is this the right approach to scaling prediction markets? Only time will tell for sure, but having Gnosis’s partnership and support for Azuro is definitely a step in the right direction.
