DAOrayaki DAO Research Bonus Pool:

Funding address: DAOrayaki.eth

Funding address: DAOrayaki.eth

Total bounty: 100 USDC

Voting progress: DAO Committee 2/0 passed

Total bounty: 100 USDC

Types of research: DAO, AMM, LMSR, CPMM

Original Author: Gnosis

Contributors: Dewei, DAOctor @DAOrayaki

Original: Automated Market Makers for Prediction Markets

Prediction markets require liquidity to function properly. However, while most people understand what the likelihood of events means, translating knowledge of the likelihood of events into a corresponding order in a prediction market can be difficult work. Also, coordinating predictive asset transactions among participants can be tricky.

A simple case without a market maker:

• Suppose Alice and Bob want to know if it will rain in Gotham City on Saturday. The outcome of the event is Yes and No. Alice thinks there is at least an 80% chance of rain, but Bob thinks that while it looks likely to rain in Gotham, it's only a 70% chance at best.

• Alice and Bob can transact together in the following ways:

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

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

If it rains, Alice redeems her 10 Yes tokens with the $10 mortgaged by the system.

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

Alice paid $7.50 for her token and Bob paid $2.50 for his. Both parties will think they got a good deal when they trade, because Alice will think her tokens are worth at least $8, even though she only paid $7.50 for them, and Bob will think his tokens are worth at least $3, even though He only paid $2.50. Looking at the system from the outside, one might say that there is about a 75% chance of rain in Gotham on Saturday, based on the trading activity of Alice and Bob in that prediction market. However, arriving at that probability estimate requires gathering information from the trades they make.

Of course, add more traders and more transactions, and things get complicated. Coordinating trades in these predictive assets among many traders and understanding what the trades say about the future can be difficult. These traders may be active at different times and may not be able to coordinate effectively without multiple order books. It also becomes more difficult to arrive at a concise measure of the probability of an outcome by aggregating trade data in these order books. These problems can be improved by using automated market makers.

Basic AMM mechanism

Essentially, an Automated Market Maker (AMM) is just a market participant, a robot that ensures that every outcome in its inventory has some outcome token, and that an outcome token always has a price it can offer. Traders can buy and sell outcome tokens for a prediction market as long as the AMM is active, and the AMM will aggregate transaction data to produce an estimate of the outcome probability.

Gnosis provides two smart contract implementation tools for automated market makers for prediction markets: Logarithmic Market Scoring Rules (LMSR) market makers and Constant Product Market Makers (CPMM). Both market makers need capital to acquire the initial result tokens needed to start providing liquidity.

LMSR market makers, originally described by Robin Hanson, have a rich academic history. It is a market maker designed for prediction market use cases and its properties are well researched.

CPMM is a newer market maker that uses the same mechanism as Uniswap and Balancer pools. It is also known as Fixed Product Market Maker (FPMM) in the Gnosis codebase. It was originally designed for the more general use case of exchanging tokens, but has been tailored for the prediction market use case in fixed product market maker contracts.

invariant = sum(num Outcomes^(-num Outcome Tokens Invent））

Both market makers can be described by a value that remains constant between trades.

invariant = product(numOutcomeTokensInInventoryForOutcome

For LMSR, the formula for the invariant is:

For CPMM, the formula for the invariant is:

• This invariant value can be considered in the context of a constant function market maker.

• When a trader buys a quantity of Result Tokens from an AMM, basically the following steps take place:

• The trader sends the cost amount to the AMM.

The AMM converts the cost amount received into a set of result tokens and adds the result tokens to its inventory. AMM's invariant expressions are now broken.

• The AMM now sends enough desired result tokens back to the trader for the invariants to be restored. This is the number of desired outcome tokens purchased.

• Likewise, sales works as follows:

• The trader sends the amount of resulting tokens sold to the AMM.

The AMM adds the resulting tokens of the sale to its inventory. AMM's invariant expressions are now broken.

The AMM converts a certain amount of the full set of resulting tokens back into collateral and sends that collateral back to the trader in order to restore the invariants. This amount is the sale price.

oddsForOutcome = numOutcomes^(-numOutcomeTokensInInven）

Two AMMs can also estimate the odds of an outcome.

oddsWeightForOutcome = product(numOutcomeTokensInInven）

oddsForOutcome = oddsWeightForOutcome / sum(oddsWeight）

The odds of an LMSR outcome can be found with the following formula:

The CPU's chances of obtaining a result can be found using the following formula:

LMSR example

• Let's go back to Alice and Bob in Gotham. We will use $10 to create and fund an LMSR market maker called CPU. The CPU takes the money and converts it into 10 Yes and 10 No for its own inventory. The initial odds in the market were estimated at 50:50.

• Now suppose Alice buys $10 worth of Yes tokens from the CPU:

• Alice sends $10 to the CPU.

The CPU turns $10 into 10 Yes and 10 No tokens. The CPU now has 20 Yes and 20 No tokens, and the CPU invariant is broken (the invariant should be 1, but is now 1/2).

The CPU returns 15.84963 Yes tokens to Alice, restoring the invariants.

At the end of this transaction, CPU has 4.15037 Yes and 20 No tokens, which estimates a 75% chance of Yes and a 25% chance of No.

CPMM example:

• Let's fund a CPMM called Digi with $10. Like CPUs, Digi takes $10, converts it into 10 Yes and 10 No tokens, and adds them to its inventory.

• Now suppose Alice buys $10 worth of Yes tokens from Digi:

• Alice sends $10 to Digi.

Digi turns $10 into 10 Yes and 10 No tokens. Digi now has 20 Yes and 20 No tokens, breaking its invariant (the invariant should be 100, but is now 400).

Digi returns 15 Yes tokens to Alice, restoring the invariant.

At the close of this transaction, Digi had 5 Yes and 20 No tokens, and it estimated the chance of a Yes to be 80% and the chance of a No to be 20%.

Difference Between LMSW and CPMM

LMSR and CPMM have some differences besides the numerical difference of different curve shapes. These differences manifest in strengths and weaknesses in each application.

Advantages of LMSR

On the one hand, LMSR is more recognized in academic work and its properties are much more studied than CPMM. It is easier to find papers on the properties of LMSRs, or to use existing research on this market maker.

When applied to compositional prediction markets, LMSR decomposes into self-similar components. Its analysis in these scenarios has been explored quite a bit in the literature.

Finally, a closed-form expression for buying and selling using LMSR allows computing the net cost of a batch of simultaneous buying and selling. CPMM does not recognize this expression of the prediction market use case, so buying and selling on the contract is limited to one resulting token at a time.

Advantages of CPMM