
We've had Multiple Choice and Free Response markets for a long time, but our top creators often avoid using these because they market mechanism they use is Dynamic Parimutuel, meaning:
The payouts aren't fixed
You can't short (bet NO) on a specific option
There's no limit orders
James has a proposal to change this, by using one Constant Product Market Maker (the system we use for Binary aka Yes/No markets today) for each of the options in a multiple choice markets.
After some research, I think something like 70-90% of markets today should actually be a Multi Binary market; e.g.
[Single event] Which team will win the NBA Finals 2023?
Nuggets?
Heat?
[Multiple events] Who will endorse Trump?
Mike Pence?
...
[Grouping related] At the end of 2023, will Twitter...
Be profitable?
Increase DAU?
[Uncertain Date] Will the US Debt Ceiling be raised by...
June 2023?
July 2023?
See our thoughts on Notion:
https://manifoldmarkets.notion.site/MultiBinary-Product-Spec-fe7b741b84e049099d44cb826ae5f271
https://manifoldmarkets.notion.site/Multi-set-of-binary-markets-8bd7ad1fde074e67b75bc1dd65f9a59a
EDIT: Market resolves according to the criteria outlined for the other "most impactful 2023" markets; likely some kind of decision process (vote, poll, quadratic funding) that we agree on among Manifold core team members. We should only pick 1 "most impactful feature".

Since this is essentially grouping multiple binary markets, will this support partial resolution? That is, resolving one of the binary markets but not others.
Suppose I'm running a contest and anyone can submit an entry. Right now, I wait until the end of the month to judge them, because if it's rejected people would sell their answers if I did it while the market was open. Instead with this it seems like I could add a binary market to the group, and resolve it NO leaving the others intact?
Another one might be "When will X event occur?" where you want to keep resolving monthly markets NO as time passes(maybe closing them in advance so people don't just sell out) until the event occurs and you get a YES.
Another reason is just keeping the list organized, so people know an option isn't possible.
I predict everyone would want to trade these as much as possible if they could get rolling payouts.
Now offering a bounty of 10k mana if you can find this closed form solution for our constant product market maker:
https://manifoldmarkets.notion.site/Bounty-for-CPMM-closed-form-for-buy-amount-given-shares-936e629e676d4590a853d65f03d20786
With this closed-form equation, we can remove the last binary search within the inner loop of our multiple choice arbitrage code. Right now, it takes 42 ms on my macbook to arbitrage between 3 answers. With this solution it should take ~1ms, which should allow us to run it even on the client.

@JamesGrugett Spent an hour on this so far, it's a much harder problem than it looks at first glance...

@MayMeta yeah, the fact that p is not fixed really makes this more complicated than it might have needed to be. There are other accounting identities they could use which would allow p to remain unchained during liquidity provisioning. I am not certain why or if Manifold must use such a novel market mechanism in their cpmm.

Even for specific p I'm suspecting we won't improve on binary search here. For example, if p=1% then the solution involves the root of a 100th-degree polynomial!

@JamesGrugett Oh, that one's easy! 1/2*(s-y-n+Sqrt[4*k^2 + (n-y+s)^2])
PS: Or rewriting that without k and with the YES vs NO cases separately:
1/2*(s-y-n+Sqrt[4*n*s + (y+n-s)^2])
1/2*(s-y-n+Sqrt[4*y*s + (y+n-s)^2])
@JamesGrugett We can still offer another 10k mana for the full solution of a general p
, though I'm not sure whether we need it.
I see @dreev has made a market on whether it'll be solved!

I don't think it makes sense to award the bounty for the p=1/2 case because just pasting into WolframAlpha gives you that one!


@JamesGrugett interesting. Fixing p=0.5 initializes each of the n markets at 50% each so you will total n/2. However if you are fixing p then I think you will be rebuilding the liquidity provisioning mechanics in which case I very much favor the multiasset cpmm
@ShitakiIntaki We can actually start each sub-market off with 1/n probability by changing up the yes and no shares initially in the pool. There's a way to maximize use of the initial liquidity because we know that only one answer will resolve YES — which means we can distribute more YES shares than we could otherwise between all the answers.
BTW, I've reduced the arbitrage calculation to one overall binary search that is taking just 3 milliseconds (for an admittedly simple case)!! Those closed form solutions are doing magic.
I've so far only implemented the case for buying YES in an answer, but it includes limit orders.
@JamesGrugett I seem to proved that a general closed form is impossible. Details coming later after I double checked.

I have a bunch of questions! 🙂
1. Are "Multi Binary" and "Multi-set-of-binary" proposals mutually exclusive? Or are the two documents just the UI + Implementation sides of the same feature?
2. Have you completely settled on the multiple binary CPPM's and completely abandoned the Multi-CPMM (multi-asset CPMM) approach? I've tried to read about it, but the notion page isn't public... https://www.notion.so/Multi-CPMM-62fe5b99013c4d5a87dfa84e0b8fa642
3. Will "Free response" be available right from the start, or do you plan to release it later?
4. Will the UI display how all of the probabilities respond to a potential bet, or only the probability of the bought/sold outcome, similar to the current Multiple choice (Parimutuel) markets UI?
5. Have you considered the complexity of auto-arbitraging a Multi-Binary market that has a lot of limit orders? Given that buying YES shares in one of the outcomes results in buying NO shares in all of the rest, it might be computationally challenging to get the entire chain reaction of filled limit orders, every time you're providing the preview of how many shares the user will get for a set amount of mana.
6. Will the YES + multiple NO's redemption be implemented as a loop that needs some time to converge, or as a fixed equation?
* I do understand that this market is about the feature itself, and not about the implementation under the hood. But I simply can't contain my curiosity! Forgive me if I missed that some of my questions have already been answered, I've really tried to lurk more and read the discord discussion. I really hope this feature gets implemented. ❤

@MayMeta the multiasset cpmm notion document is public, just Notion wants you to set up an account so that you are not viewing it anonymously.
Same idea with different explorations
Access it here (without signing in): https://manifoldmarkets.notion.site/Multi-CPMM-62fe5b99013c4d5a87dfa84e0b8fa642
Free response to be released later. Should be possible under the same mechanism
Not sure, but good idea to be able to preview all probabilities. I feel like people will want to bet answers toward to multiple probabilities simultaneously
Yes, I think computers will be fast enough so this works (but it's only possible after someone submitted the close-form for calculating the amount needed to move to a specific probability for binary CPMM). It could be challenging though.
It will be done in a single transaction in our backend. Shouldn't take much longer than a normal bet. But yes, it will be recorded by creating one pseudo-bet for each answer, plus another bet on the answer you bet on.
Note that there's a difference between multiple choice where you intend to choose one answer and where you could choose many as winners. In the first case, you want the arbitrage so the probabilities sum to 100%. We'll probably first release multiple choice without that capability.

@JamesGrugett how would limit orders on multi-markets even work, would you auto-arbitrate the limit order itself so that placing one order involves placing orders in all submarkets?
@Odoacre Nope, limit orders would be placed on just one market. It's just that when you bet (without a limit order) on one market it will also bet against the other markets so that the total probability still sums to 100%.
If any of these markets has a limit order as the best offer, it will trade against that. Only difficulty is calculating things out as @MayMeta suggested, but I think the problem is tractable!

Say theres a market with submarkets m.1 and m.2 with an open limit order on m.2
I want to buy some m.1 but I can't do so until the limit on m.2 is consumed. Assuming the limit order is large enough it's possible I'd bet on m.1 but end up with only short shares in m.2 and nothing in m.1
That's pretty neat, but maybe a bit confusing ?
@Odoacre You'd get short shares in m.2 (aka, NO shares), but our auto-arbitrage will convert to YES shares of m.1 since they are exactly equivalent in this context.
Every operation relies on using different laws to convert combinations of YES and NO shares among different subsets of answers.
For example, 1 YES share in each answer always equals 1 mana (since exactly one answer must be resolved YES), and 1 NO share in all n answers always equals n-1 mana (since all but one answer resolves NO).
I think the actual algorithm for buying YES in m.1 is something like:
Buy x NO shares of each answer, convert the shares to (n-1) * x mana, then buy YES shares in m.1 with your remaining mana. Binary search this operation on variable x until the probabilities total 100% after the operation.

@Odoacre short shares on m.2 (let's call it -m.2) are exactly equivalent to +m.1 only if there is not a third option m.3 (after all, if there were only two options why make it a multiple choice market).
Buy x NO shares of each answer, convert the shares to (n-1) * x mana, then buy YES shares in m.1 with your remaining mana. Binary search this operation on variable x until the probabilities total 100% after the operation.
this makes total sense, but if there's a large enough limit order on m.2 you might not have any remaining mana to buy shares in +m.1 or even -m.3.
If then the market resolves to +m.3 I would gain profit, even though I only intended to buy +m.1
Not saying this is a bad thing, just somewhat surprising.
@Odoacre Should still work — you don't have to fill the whole limit order. You would end up buying like 100 shares of NO from all 3 answers, then buying YES shares of the intended answer.
If there were large YES limit orders for m.2 and m.3, then their probability might not move at all. As m.1's probability drops from the first NO bet, the shares get increasingly expensive, leaving less money to buy m.1 up to its original probability, which is how you can accommodate even large YES bets on m.1 in this situation.

@JamesGrugett If there are only 3 options and m.2 and m.3 don't have their probability change at all then the solution to keeping the sum of probabilities at 100% requires that m.1 does not change either. If there are no limit orders to purchase against in m.1 but there are large purchase orders in m.2 and m.3 then I don't think you can purchase any shares in m.1 with out violating the sum to 100% criteria because you will need to return m.1 to its original probability, unless you are also tweaking the p parameter in the cpmm but this parameter is supposed to reflect the liquidity in the market. Actually I think that is the extra ingredient, since the markets are linked the limit orders in m.2 and m.3 are adding liquidity to those markets when filled and therefore must also impact the liquidity in m.1.

@ShitakiIntaki reading all of this makes me think that multi-asset cppm might be easier to implement [bug-free / in a reasonable timeframe] 😅

@JamesGrugett Will it be possible to later enable this option retroactively for created Multi-Binary markets?

@JamesGrugett The liquidity in the multi cpmm market model are linked because of the redemption of M$(n-1) for 1 share of NO in all n markets. Unlike a M$1 redemption for 1 YES + 1 NO from a single cpmm market, the reserve pools are going to be impacted asymmetrically as the reserves accumulate YES shares while NO shares are depleted by multimarket NO redemptions, so (shooting from the hip at the moment) I suspect that the "p" parameter in each of the cpmm's will constantly need rebalancing. I might model this up to test my hypothesis. Typically the "p" parameter doesn't need to change in the cpmm until there has been a liquidity provisioning because incoming trades are providing liquidity to the trades, but when a trade in one market triggers a redemption in a different market reserve pool (where the trade didn't originate) then I am thinking that this will look like a negative liquidity subsidy and all of the subsidy transactions trigger updates to the "p" parameter.
@ShitakiIntaki There's a third law for cpmm multi binary that makes it clearer a solution exists for the tricky case above:
The following are equivalent:
- x NO shares of answer A
- x YES shares of each non-A answer
This follows because they are worth the same amount of mana in every possible resolution case. If A is chosen, the shares are worth nothing. If any other answer is chosen, the shares are worth x mana.
Scenario: you have three answers all at 33.3%, with large YES limit orders at market price for the last two answers.
If you buy NO in the two answers with limit orders, you can convert those NO shares into YES in the other two answers. Using the first law to redeem equal YES shares to mana, you are left with mana + YES shares in the first answer. You can repeat this procedure while the limit orders don't run out to generate further YES shares in the first answer without moving the probabilities.

@JamesGrugett limit orders on some outcomes resulting in shares in other outcomes sure is an unusual and non-intuitive market behavior for Manifold users... Might take some time to get used to, and raise some false-alarms in the #bugs channel mixed with the actual bugs related to the new feature.

It’s ironic that your examples of grouping markets together for a single multiple choice market could have included this market together with “will newsfeed/boosts/leagues be the most impactful feature of 2023”!

I like that it makes the distinction between mutually exclusive type markets and others in the first document

If I understand correctly what's proposed in the second document Is not so much a multiple choice market but more like a group of related markets. (Users have to manually short non selected options, sum of probability is not guaranteed to be 100%)
The first document talks about mutually exclusive and independent submarkets. Presumably in the case of exclusive liquidity is somehow shared between the submarkets so you'd implemented some sort of auto arbitrage system?

@JamesGrugett oh! I apologise. I was reading this on my phone and thought the document had ended when in fact there was a lot of stuff there, including an answer to my questions! Now I feel dumb.
Looks awesome, can't wait to see it!

This looks awesome! Especially as someone who really enjoys creating markets, I feel like this would be a significant improvement over the current system.

I wanted to create a bunch of markets on a certain topic the other day, and the only thing that stopped me was the thought: "Dynamic Parimutuel is bad, I'll wait for the Multi-choice CPPM!"
Thanks Austin!! Multi-binary markets will definitely be a major upgrade to the core Manifold experience! Perhaps the biggest since inception.

















