Will Manifold's developers agree with me that the dynamic parimutuel cost function should be changed?

Basic

Ṁ24k

resolved Mar 13

Resolved

YES

ALL

I believe that the dynamic parimutuel betting system as formulated by Manifold (described in the site's technical guide) significantly disincentivizes accurate price setting and should be changed. I have written a blog post arguing this point, which I intend to publish shortly. This market will resolve to Yes if Manifold's developers publicly state an intent to change their pricing implementation, and this market contributed in some way to their decision to do so. This market will resolve to No if this does not happen within a month (either because I become convinced that my argument is wrong, or if I still believe in it but the developers do not agree with me that it is an issue). Fine print: This does not require a specific change to actually be implemented within the next month, as long as the developers publicly state an intention to implement a change. If a change is made to pricing that is unrelated to this market that does not count. In the unlikely event that a change is made but it is unclear whether it is or is not related to this market I will resolve to N/A. I have no inside information about Manifold nor any pre-existing relationship with its developers or with any other prediction markets. Feb 17, 6:50pm: Here's the argument https://kevin.zielnicki.com/2022/02/17/manifold/ Feb 19, 9:40pm: Here's a TLDR summary of the issue, which I still believe is significant enough to justify a change to Manifold's betting system: If market odds change substantially over time due to arrival of new information, earlier traders will not get the payouts they were expecting from the odds at the time of their bet. This is a common occurrence in interesting prediction markets, many of one can even expect will go to nearly 1 or 0 by the time they close (which is the worst case for this issue). This significantly distorts incentives for accurate pricing.

Get

1,000

and

1.00

20 Comments

Sort by:

Thank you @SG, excited for the change!

I think you can probably resolve this as YES. I intend to switch over the betting system for new binary markets to a CFMM (constant function market maker) sometime next week, and this market did play a role in leading us to switch.

And re "I think -probably- if they say they currently expect to change it that should work too?" -- yes, I would consider this sufficient

Or to put it another way, I want to separate "intent to change" from "intent to evaluate"

@jbeshir I would also accept "intent to change" from the devs, I don't mean to introduce a higher level of commitment than originally set out in the market description. I just want to make sure I'm not overreading into a discussion of possible alternatives, if for example unmodified DPM is still considered a contender for market making in the long-term.

Just updating on that the wording in the above comment suggests it doesn't just need to be an intent to change, which could be e.g. conditional on testing working as expected with the existing algorithm a fallback position, but a "commitment", which is a higher bar than intent to change that I'm not at 97% about. I still think we're probably going to get something satisfying the market (I think -probably- if they say they currently expect to change it that should work too?), esp given that in the same channel we have a competing proposal to move to DPMM-with-sidepools which also is attempting to address this issue and I think should also qualify as a pricing implementation change, so DPMM as-is doesnt' seem to be the first fallback option here. But I'm less sure about how this is going to decide now.

I believe we can tell who just sold $3003 worth of YES based upon some simple forensic analysis. Based upon that person's record, I'm going further in on NO.

From comments here & on discord, I'm inclined to think dev statements amount to an intent to change pricing in some way that would address the DPM issues discussed here, and thus the market should resolve yes (even if the exact form of the change may not yet be fully decided). @Austin or @SG could you confirm if this is a reasonable interpretation? The line I want to draw is between "we're evaluating different market makers, but may end up sticking with the current DPM implementation" which I would resolve to No (if still true at market close), while "we're evaluating different market makers, but are committed to choosing something other than the current DPM implementation" which I would resolve to Yes.

Case in point why OP's argument was a good one - I put $10 down on this market when the implied probability was only 16%. My current expected payout for that? $24, for a profit of $14. ;P

For those of us not in the know, what's the general info on CPMM?

https://discord.com/channels/915138780216823849/927671564177133618/951713160660930600 - CPMM implemented (on the dev site) with a statement of intent to bring it to the main site.

Case in point. I bought at 42%...

Buying YES as a protest, I'm very disappointed to realize that the "Payout if YES" isn't actually a guarantee. This makes manifold no better than metaculus in my opinion, but hopefully it will change.

Quick update for y'all: we are still actively evaluating different market makers; currently excited about the Polymarket-style CPMM, though it doesn't scale well to multi-category or free response questions. Thanks for your patience on this front!

I still do not think that developers at Manifold are going to be able to respond to this request in the timeframe set up. However, I think it would be cool to allow the market maker to select which algorithm governs the bet (fixed for the duration of the market). Maybe there could be 2 or 3 different options so it's not too complex, feature different emoji/symbols for the type of market algorithm, this would be a cool way to introduce people intuitively to different styles of market algorithms.

One more question where participating with current payout is pointless: https://manifold.markets/ValentinManes/will-george-rr-martin-publish-an-as

Set up this market referencing this DPCF market even though my bet here on the DPCF market was no. https://manifold.markets/PatrickDelaney/will-russia-invade-ukraine-in-march

Another way of stating this is that the *best* ratio of YES odds and NO odds in this kind of market is 5.8. You can calculate this odds ratio gap as a function of the probabilities that YES and NO will reach 1 early, or some more complicated model. I recall someone at the forecasting meetup saying a typical e.g. sports betting market has a bid-ask spread of 2%. I'm guessing DPM has a larger gap than CLOB down to about a 5% chance of the market learning the outcome early.

@SG and some others have stated this as a problem with the interaction between how the math works and how information is displayed to the user. I disagree. DPM generates an enormous bid-ask spread which makes markets "will x happen by y date" markets very distorted. Consider the most popular market https://manifold.markets/Duncan/will-russia-invade-ukraine-before-t Assuming shares go to 0 or 1 before resolution, the current implied probability of buying YES is 62.5%, while NO is 21.8%. If this market resolves NO it's guaranteed to go to 0. If it resolves YES it's also quite likely to go to 1, unless the creator somehow sees the event happen before anyone else. This is not a volume issue. A market at 50% will give payoffs of 70.7% and 29.2% - a gap of 40% - no matter the volume. So how does the probability move at all? Only very confident bettors who think there's an extreme probability will participate, and we see the ratio between the extreme YES and extreme NO groups. That's some info about the distribution of beliefs and hence "true" probability, but it sure ain't the mean or median.

Thanks for all of the helpful comments on this question. @SG could you say a little more about what you see as the disadvantages of other options, especially Hanson-style AMMs? I find DPM hard to reason about / anticipate and would feel better knowing it was the last bad option for what Manifold is trying to do :)

Related questions

Related questions