Caveat: You can prove that this breaks something or leads to 'cheating' and we can throw the entire idea away. It might not be perfect, but I argue it is better than the status quo.
Background
Manifold still uses the maniswap AMM for binary markets, which has a very handy solution to the "excess shares" issue when liquidity is added to an existing pool. Maniswap adjusts the p parameter to allow better use of subsidy mana without throwing away shares. This causes some changes in behavior of the AMM when betting against it, but usually it ends up better than just throwing away a lot of mana.
When Multiple Choice markets were introduced in 2023, one concession made in the implementation was fixing p = 0.5 due to Math Reasons. It mostly didn't matter a ton at the time, some reasons being: Manifold was pumping liquidity into markets for every trader, so it was papered over; the actual amounts of mana used were significantly smaller, 100 mana was about what 1000 is today due to mana inflation over time.
Later on, Set markets were introduced as "We took the Multiple Choice markets and just turned off the auto-balancing". These also have a fixed p = 0.5.
Problem
So, what's wrong?
On both Multiple Choice and Set markets, significant amounts of liquidity added after market creation are totally lost. Your mana basically just goes "poof".
In the case of Set markets, it's really simple. Since p = 0.5 is fixed, if you subsidize a Set market where answers are far from 50%, a significant portion of the amount you subsidize is thrown away as excess shares. You don't get them back. Manifold doesn't get them. They're just vaporized.
In the case of Multiple Choice markets, it's a little more complicated, but in most cases you will be vaporizing somewhere between.....5% and "a massive amount" of your mana.
Concrete Example
Here's a concrete example to help you understand the issue.
A market is created with 3 answers A, B, and C, with 1000 mana as the initial subsidy. Traders do some trading and the market ends up with A = 80%, B = 10%, C = 10%, like this:
Total Liquidity: 1000
Option A 80.0%
Pool Yes shares: 176.8
Pool No shares: 707.1
Option B 10.0%
Pool Yes shares: 1060.7
Pool No shares: 117.9
Option C 10.0%
Pool Yes shares: 1060.7
Pool No shares: 117.9
Pool Value: 707.11At this point, some of the initial 1000 mana in the pool has been used up by traders who have moved the market from 33/33/33 to 80/10/10, as represented by the "pool value" of 707 mana.
If you found this market and decided you wanted to add more liquidity to it at this point, perhaps you would supply an extra 1000 mana. Pause for a moment and make a guess, what will the pool value be after we apply 1000 mana of subsidy to this market?
Here's the market state after the 1000 mana subsidy:
Total Liquidity: 2000
Option A 80.0%
Pool Yes shares: 294.6
Pool No shares: 1178.3
Option B 10.0%
Pool Yes shares: 1531.9
Pool No shares: 170.2
Option C 10.0%
Pool Yes shares: 1531.9
Pool No shares: 170.2
Pool Value: 1084.07Ha, did you think that spending 1000 mana would result in more than 377 mana added to the value of the pool?
In this example, 778 Yes shares in Option A (present value of 623 mana) were completely vaporized during the subsidy process. You never get it back and no one else does. (You will just have to take my word for it, the math part would take a long time to explain.)
Possible Fixes
The main thing I care about is doing absolutely anything other than the status quo. I often see multiple choice markets that would benefit from a lot of subsidy, but in many cases it is so inefficient that users would be crazy to do it.
The best fix is to keep track of all excess shares, but choosing a method to do so might rub people the wrong way. This is a play money site, we can just try stuff.
I'll present 2 options, someone else might have others...they would both work on both Multiple Choice and Set markets:
Option A: just give the subsidizing user the excess shares as a "bet"
straightforward implementation
need to decide on the "cost basis" of this bet because it will affect profit (a safe one is one mana per share which always results in negative profit but not by too much)
can be traded like any other shares
Option B: keep track of the excess shares using some other method and pay them out on market resolution
they could be a special "bet" that cannot be sold/redeemed and don't count as profit
or they could be kept as a pool-adjacent value that just remembers how many excess shares any user owns, to pay back at resolution time
Concerns
Basically you can make slightly one-sided trades at the expense of funding the AMM. Maybe it is abusable but I can't see exactly how it would ruin things, especially since we cannot withdraw liquidity in the MC markets. Like you could effectively exit out of a position by funding the AMM rather than changing the market price.
Would love any feedback!! Where have I messed up?
Thanks, I never could figure out what was happening to my mana when I tried to add more liquidity. I thought it had something to do with adding liquidity after some of the options had already resolved. If I added with all options still open, it seemed like most of the mana eventually got into the pool.
It would be nice if you could subsidize different options in the same "set" different amounts or at different times. For instance, if I wanted to subsidize today's games on /OnTheMARK/nba-basketball-games-live-20242025 I would have to also subsidize 1300+ closed markets (or maybe not I still don't understand this).
this is very cool! the issues with set markets wasting added liquidity annoyed me to no end until i begged them to apply the hacky fix of removing the drizzle, so while adding liquidity is still broke, as long as you have lots of mana to spare and you plan the market in advance you can avoid wasting mana. it's nice to see a worked out example for how bad it is for MC as well.
i think the main advantage of Option B is that Option A will be more confusing for users. in practice, many creators don't understand liquidity. many don't even know that "liquidity return" is a thing. but people absolutely notice "bets". so if people add liquidity and suddenly see they have some enormous YES position for one option, they are going to be panicked/confused/etc ("I didn't predict that!"), even if mathematically those shares are just pure upside for them (and/or if the profit doesn't count). it's largely a UI issue—in theory that can be fixed by any approach that doesn't display those additional shares like a bet they placed—but it's a substantial one.
whereas Option B i think is generally the right way to think about it—this is just a more complicated form of liquidity return, which happens behind the scenes and you only need to track what's happening if you choose to. ideally users would understand liquidity return better than they do, but given that most don't pay much attention to the simpler current system it seems unlikely they'll want to wade through and understand where these conditional payouts are coming from.
@Ziddletwix Indeed, I think Option B is significantly better than the status quo, which is throwing away those shares so no one gets them. It's slightly more work to implement which is why I included Option A so my target audience ( @ian ) can weigh the benefits and drawbacks of each approach.
As you noted, this would be particularly noticeable in a Set market. It's no more "capital efficient", but it would at least return more of your capital at the end of the day.
For anyone else following along, imagine adding liquidity to a Set market currently priced like this:
A 90%
B 80%
C 10%
D 10%
E 10%In the current pattern, your subsidy would be applied equally across all 5 answers. However, on A and B, some of the Yes shares would be thrown away, while on C/D/E, some of your No shares would be thrown away.
If we just kept track of those shares until resolution, then you would get paid out mana if A or B resolved Yes and if C/D/E resolved No. (If they went the other way, you would get nothing, but that's okay too -- in that case your mana still subsidized the market like before.)
I am guessing here as a baseline that both Option A and Option B would be less total work to implement than the "better fix" of having a variable p for Set markets. If this plan doesn't work, I'll next try to advocate for that instead.
@Eliza My personal preference would be:
Option C: just implement p != 0.5 for all market types, and do the same thing binary markets do in both set and linked MC markets. The linked liquidity addition operation then becomes buy some mix of Y/N shares on each individual market and apply those as you would for binary. That's a breaking change, so make it noticeable in the API -- call it multi-cpmm-2 or whatever. You can make it only on new markets, or just convert the market type when it becomes relevant.
@EvanDaniel I wrote this in response to the reality that I have been asking for variable p for years and nothing has happened yet. I also prefer your option but I rate it very unlikely to happen.
Can you just add 377 mana to the pool, deduct 377 mana from the balance, and return the rest unspent mana?
@EvanDaniel I considered this but kept it out as an editorial decision for brevity (and because my primary audience already knows this). I made sure to include the link to the Maniswap page which has a worked example, and I can copy the specific section in here for anyone who is interested.
The problem: leftover shares
Suppose you have $100 and are trying to initialize an AMM’s liquidity pool to be at an implied 33% probability using Uniswap.
If you only have $100, then that means that you can put up at most 100 YES shares and 100 NO shares. To get the right probability with this constraint, you must create the liquidity pool with 100 YES shares and 50 NO shares (since 50/(100+50) = 1/3).
But notice that if you started with $100, you still have 50 NO shares left over. This is unfortunate. Ideally, you would prefer to deploy all of your capital to subsidizing the market, not just when the initial probability is 50% (which is the only case when you can deploy 100 YES, 100 NO).
The solution: Maniswap
The solution is to modify the Uniswap constraint to make it parametrized in terms of the initial probability.
Suppose you want to want to initialize the probability at p. Instead of the simple constant-product formula, use
(y^p)(n^1-p) = k
With the corresponding market probability of
P = (pn) / (pn+ (1-p)y)
This will allow you to allocate all 100 YES and 100 NO shares of your original $100 subsidy at any probability you choose!More importantly, the farther the initial probability is in the extremes (0.1% or 99.9%), the better the liquidity and the lower the price-jumpiness you will observe versus Uniswap.