Why is AMM necessary for prediction markets?

Public.icon

For a prediction market to function properly, liquidity is necessary. However, while most people understand what it means for an event to be likely, converting that knowledge into corresponding orders in a prediction market can be confusing. Additionally, coordinating trades of prediction assets between participants can be difficult.

Simple case without a market maker

Let's say Alice and Bob are trying to determine whether it will rain in Gotham on Saturday. Alice thinks it will rain with at least 80% probability, but Bob thinks it's likely to rain in Gotham, but with at most 70% probability.

Alice and Bob can come together to trade in the following way:

Alice converts $7.50 into 7.5 Yes tokens and 7.5 No tokens, and Bob converts $2.50 into 2.5 Yes tokens and 2.5 No tokens.

Alice exchanges her 7.5 "No" tokens for Bob's 2.5 "Yes" tokens.

If it rains, Alice exchanges 10 Yes tokens for the system's collateral of $10.

If it doesn't rain, Bob exchanges 10 No tokens for $10.

Alice has paid $7.50 for her tokens, and Bob has paid $2.50 for his. Alice thinks her tokens are worth at least $8, even though she only paid $7.50 for them, and Bob thinks his tokens are worth at least $3, even though he only paid $2.50 for them, so both think they got a good deal in the trade. From the outside, one might say that the probability of Gotham raining on Saturday is about 75% based on the trading activity of Alice and Bob in this prediction market. However, to arrive at that probability estimate, they would need to gather information from the trades they made.

Of course, as more traders enter and more trades are made, the situation becomes more complex. It can be difficult to coordinate trading of these prediction assets among many traders and understand what those trades are saying about the future. These traders may also operate at different times and may not be able to effectively coordinate without multiple order books. Additionally, aggregating trading data from these order books and succinctly showing the probability of the results becomes more difficult. These issues can be addressed by using an automated market maker.

Basic Mechanics of AMM

Essentially, an automated market maker (AMM) is a bot that ensures there are always some outcome tokens for every possible outcome in its inventory and always a price available to offer for those outcome tokens. As long as the AMM is active, traders can buy and sell outcome tokens for the prediction market, and the AMM aggregates the trading data to estimate the odds of the results.

Gnosis provides smart contract implementations of two automated market makers for prediction markets: the logarithmic market scoring rule (LMSR) market maker and the constant product market maker (CPMM). Both of these market makers require funding to obtain the initial outcome tokens necessary to start providing liquidity.

The LMSR market maker was originally developed by Robin Hanson and has a rich academic history. It is designed specifically for the use case of prediction markets, and its properties have been well studied.

The CPMM is a new market maker that uses the same mechanism as Uniswap and Balancer pools. In Gnosis' codebase, it is also known as the Fixed Product Market Maker (FPMM). It was originally designed for the common use case of token swapping, but was adapted for the use case of prediction markets in the FixedProductMarketMaker contract.

Both market makers can be explained from the perspective of an invariant value held between trades.

In the case of LMSR, the invariant value is expressed as follows:

Invariant Value = sum(numOutcomes^(-numOutcomeTokensInventoryForOutcome/ funding) for every outcome)

In the case of CPMM, the invariant value is expressed as follows:

Invariant = Product (numOutcomeTokensInInventoryForOutcome for all outcomes)

This invariant can be thought of in the context of a constant function market maker.

When a trader buys an outcome token from the AMM, it is basically done in the following steps:

The trading participant sends the cost amount to the AMM.

The AMM converts the received cost amount into a set of outcome tokens and adds the outcome tokens to the inventory. The AMM's invariant is now broken.

The AMM sends enough requested outcome tokens back to the trader to recover the invariant. This is the amount of outcome tokens requested for purchase.

Similarly, sales work as follows:

The trader sends the sale amount of the outcome token to the AMM.

The AMM adds the sold outcome token to its inventory. The AMM's invariant is now broken.

The AMM restores the invariant by returning the set of outcome tokens as collateral and sending it back to the trader. This amount becomes the sale price.