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?
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.