I know how the Automated Market Maker (AMM) works for binary markets from here
Will someone explain how it works for linked multichoice with more than 2 options before the end of this year?
I may resolve this to a partial % if I feel like I only partially understand the AMM.
What I already know:
When you initialize a market with a given subsidy, that subsidy is split into shares on each of the options
If someone places a bet on an outcome, their bet is added to the liquidity and then they get back some amount of shares, as determined by a function
What I want to know:
How is the shares received determined
How are the odds determined
I will not bet on this market.
1,000🏅 Top traders
| # | Name | Total profit |
|---|---|---|
| 1 | Ṁ7 | |
| 2 | Ṁ2 | |
| 3 | Ṁ0 | |
| 4 | Ṁ0 |
People are also trading
Hi! Your post about AMM for linked multichoice markets is fascinating, especially when viewed through the lens of technology. You know, the concept of AMM and calculating odds can be quite similar to algorithms used in mobile apps, particularly in financial apps or trading platforms.
Speaking of mobile app development, such systems could be implemented using cross-platform technologies like Flutter or React Native to ensure quick access to AMM features directly from a mobile device.
Even more exciting is how artificial intelligence and machine learning can enhance these apps, adapting to user behavior and even predicting trading actions based on historical data. Maybe your market could be integrated into such an app, with https://dashdevs.com/mobile-app-development/ to make the betting process even more user-friendly. What do you think?
@traders Thanks to everyone who helped out (particularly @SisyphosDale). I now know that linked multichoice is just unlinked multichoice which does some arbitrage for you, but I am clearly missing something, as when doing some test bets it didn't produce the expected results. Therefore, I am resolving this 50%.
@bagelfan Makes sense. I'm still glad I looked into it, since it really is a very interesting mechanism, but I'm also still confused what could be causing that last bit of mismatch between the expected shares received and the actual result. @windysoup's idea that there might be something different about the initialization of the market vs. adding liquidity could be correct, but I looked at it when I first saw the comment and I couldn't even find the part in the code where the market is actually initialized.
This question inspired me to look into how it works on Manifold, and it's actually quite an interesting solution.
You already mentioned the basic way it works for binary markets: Manifold uses a fixed-product market making algorithm, where for every 1Ṁ you put into the pool to buy yes/no, the AMM adds one YES share and one NO share to the pool, then it removes yes/no shares (depending on which one you are buying) until the product of the number of shares on both sides is equal to what it was before. i.e. if you initialize a market with 100Ṁ, then the pool contains 100 YES and 100 NO, which multiplies to a product of 10,000. If you buy 10Ṁ worth of YES shares, the AMM increases the pool to 110 YES and 110 NO, then removes YES shares until the product is 10,000 again, which means it needs to remove approximately 19 shares to a total of 91. Hence the first 10Ṁ you spend buys you 19 shares.
In a market like this the probability of YES is the number of NO shares in the pool divided by the total amount of shares in the pool, so in the previous example the probability moves to 110/201, which is approximately 54.7%. Manifold uses a unique system they call "Maniswap" [1], which can change this calculation with an initial probability p, but in the code the linked multiple choice systems use a fixed p value of 0.5 for every option, which means the calculations for probability and share price are unchanged.
For linked multiple choice questions there is also an implementation proposal by manifold [2], but after checking the actual implementation that doesn't seem to be the approach they use. Instead, Manifold keeps all of the formulas from the normal binary markets and treats every individual option as an independent market, and just uses the property that a YES share in one market is the same as a NO share in every other market, and vice versa. Essentially, when you want to buy n shares of YES on option 1 of a linked multiple choice question, which would drive the probability of option 1 up and make it so that the probabilities no longer add up to 1, Manifold performs a binary search to calculate the number of YES buys that it needs to convert into NO buys in every other market, so that the increase in probability in option 1 and the decrease in probability in every other market cancel out, and the probabilities still add up to 1. The calculations for this happen in calculate-cpmm-arbitrage.ts [3], and get used in calculate-cpmm.ts [4].
Sorry it turned into somewhat of a long answer, this was definitely an interesting investigation. If you have any questions about my explanation let me know and I'd be happy to clarify.
[1] https://manifoldmarkets.notion.site/Maniswap-ce406e1e897d417cbd491071ea8a0c39
[2] https://www.notion.so/manifoldmarkets/Multi-CPMM-62fe5b99013c4d5a87dfa84e0b8fa642
[3] https://github.com/manifoldmarkets/manifold/blob/e63fea77477c8be0c44d3f175607c5f6f02275b3/common/src/calculate-cpmm-arbitrage.ts
[4] https://github.com/manifoldmarkets/manifold/blob/e63fea77477c8be0c44d3f175607c5f6f02275b3/common/src/calculate-cpmm.ts
@SisyphosDale Wow, thanks for the detailed response!
Just to check, is this correct?
When you create a linked multichoice market with n answers and liquidity subsidy k*n, manifold creates n binary markets with liquidity subsidy k, each initialized at probability 1/n using Maniswap
When you bet Yes on an option, it works as usual as if it were a single binary market, but Manifold will take some of that bet to bet No on the other options in order to keep the probabilities summing to 1 (and giving you better prices)
The probability of each option is calculated the same way as if it were n binary options
I plan on resolving this Yes soon (and giving you the bounty) after doing some tests
@bagelfan Great questions! Most of that is correct, except an aside about Maniswap (see second paragraph).
The liquidity is indeed divided equally across the different markets, including with later subsidies. Initially it might seem like that leaves you with too little liquidity, since you can make e.g. a 10-option market with an initial subsidy of only 100Ṁ, which leaves 10Ṁ per option. However, since some of the YES buys in each market get converted into NO buys in every other market and vice versa, which use the liquidity from those markets, you are actually still indirectly using the liquidity of the whole market, and indeed getting better prices because of that as well. The rest is correct too: the probability is calculated independently using the normal binary formula for each option, but the share conversion system keeps the probabilities adding to 1.
The only part that isn't quite correct is that the initial probability given to the markets, which is indeed 1/n, is not the same as the value of p used in Maniswap. Instead, the value of p seems to be fixed to 0.5 for each market, as in normal Uniswap. This doesn't mean that the probability of the market has to be equal to 0.5, just that in order to get the correct probability you have to "throw away" shares that you could otherwise have used for liquidity. One example would be initializing a 10 option market with 100Ṁ, putting 10Ṁ in each option resulting in 10 YES and 10 NO shares. Then in order to get the probability to 10% in each option, the AMM has to throw away approximately 9 NO shares in each market, leaving only 1 (but because YES shares in other markets can also be used as NO shares, this isn't a problem). Interestingly, this shows that 10 options is about the limit for an initial subsidy of 100Ṁ, since otherwise you would be left with less than one NO share per market, and indeed if you try to create a question with more than 10 options Manifold will increase the basic subsidy from 100Ṁ to 10Ṁ times the amount of options, which indicates that it does work this way.
@SisyphosDale I did some tests, it doesn't quite match up 😬
Sorry, I'm pretty busy right now, I'll share more details soon. Thanks a lot for digging into this with me
@bagelfan Hmm, what part doesn't quite match, the liquidity or the price/probability calculation?
I did find one one thing that changes the liquidity: Manifold also uses the conversion of NO shares in one option to YES shares in every other option to optimize liquidity used and avoid throwing away too many shares (when adding liquidity this happens in the function addCpmmMultiLiquidityAnswersSumToOne in [4]). When liquidity is added the function tracks how many shares are thrown away, then converts all thrown away NO shares into thrown away YES shares into every other options, then takes the minimum of those and adds that much liquidity again, repeating until there is no more liquidity left. This means there is actually quite a bit more liquidity than I estimated.
To take the example of 10 options and 100Ṁ of liquidity again, throwing away 1 NO share is like throwing away 1 YES share in 9 other markets, so throwing away 9 NO shares in each market is like throwing away 81 YES shares in every market. 81 YES shares in every option is the same as 81 Ṁ (since the options are mutually exclusive), so then Manifold would add another 81Ṁ, or 9Ṁ per option, effectively meaning that the first allocation only used 19Ṁ, and the process repeats on and on (I use integers for simplicity but these calculations are not rounded in Manifold). I wrote a quick Python program to simulate this and it turns out that by constantly freeing up liquidity by turning n discarded NO shares into 9*n discarded YES shares, this process actually still converges on having 90 YES shares and 10 NO shares in each individual option. This means that the liquidity for linked multiple option markets can be much more efficient, just because the options are mutually exclusive.
@SisyphosDale Huh, I would think that the process converges to 50 Yes shares on each option and 50/9 No shares on each option. All of the Yes shares would be worth 50 in total and the No shares worth 50 in total as well, summing to the 100M of liquidity that the market creator put in. If it converged to 90 Yes and 10 No on each option, the total liquidity would be 180
I made a testing question with 1000M subsidy: https://manifold.markets/bagelfan/test-thLSIU5CqZ
The 1000M subsidy becomes 500 Yes shares on each option and 500/3 (166.666) No shares on each option. The constant product on each option would thus be 500^2/3.
If I want to buy an option down to 1%, the auto-arbitrage converts my No trade into a No trade on one option (pushing it down to 1%) and Yes trades on three other options (pushing them to 33%).
The shares remaining in the pool for each option would be (approximately)
Yes 2872.2183 No 29.0129 (this is the option I bet No in)
Yes 411.329 No 202.595
Yes 411.329 No 202.595
Yes 411.329 No 202.595
The total No shares I get back should be 166.666 - 29.0129 + 500 - 411.329 = 226.3247
However, when I actually place the trade I get a payout of 2634 and spend 2480, meaning I got back 2634 - 2480 = 154 No shares.
@bagelfan For the first comment, I don't think that's necessarily true since the 10 NOs on each market also combine, and can be backed by 10Ṁ, so 90 YES and 10 NO in each market can still be backed by 100Ṁ.
For the second comment I'm also somewhat stumped. I wrote another Python script to calculate if it would be any different if I were correct, but with your starting shares I get that you should get back about 2707.18 shares, and with my starting numbers (750 YES and 250 NO) you should get back 2800.16, neither of which match 2634. I'll have to take a closer look at the code tomorrow to see what could be going on to cause the difference.
@SisyphosDale Just realized what I wrote about NOs in every market "combining" and yeah obviously that makes no sense, n - 1 out of n NOs will pay out so you need n - 1Ṁ to cover them, there must be something wrong with the assumptions in my script. I'll have to double check those calculations tomorrow too, but for now your 50 to 50/9 seems much more reasonable.
@bagelfan Just checking in, 50 to 50/9 is definitely correct, I was just mistakenly multiplying by n instead of n - 1 somewhere. However, it's still not clear what's causing the missing shares. I've checked a couple of things that are definitely ruled out:
It's not because there are fewer shares than we thought, because the 50 to 50/9 is definitely correct, and to get only 154 shares back the starting liquidity should be approximately 650Ṁ, in which case the probability should move down further to 0.4%. It's also not because of fees, because fees are still zeroed out everywhere where they could affect these calculations (and you bought and sold for the same amounts so there couldn't be fees anyways). It's not because of the redeeming of YES shares for NO shares at the end because even though that moves shares from one market to the other, it shouldn't affect the shares in the liquidity pool because they have already been bought. Finally, it's not something to do with buying the maximum number of shares, because I tested it on a new linked multi market that had no trades yet and it also gave back fewer shares than expected, even for just a partial buy.
I double checked the function buyYesSharesInOtherAnswersThenNoInAnswer in [3] which should be the one used here and it seems to be doing exactly what we expect, so it's not clear where the share difference could come from. It seems that the basic mechanism is still definitely correct, and every individual part like the liquidity division and converting shares for the buy is clearly visible in the code, but there's some additional factor that's changing the number of shares received that we haven't found yet.
@SisyphosDale Is addCpmmMultiLiquidityAnswersSumToOne used to initialize a market? One thing I was confused about is how the pools passed to this function are initialized, since they already need to have the correct probabilities and I think can't have 0 shares?