pull down to refresh
139 sats \ 5 replies \ @Undisciplined 24 Aug \ on: A Utility Framework for Bounded-Loss Market Makers oracle
Can't you use a pooled model to avoid losing money?
However events are generated, some user will be first to put their bet in. That will mean X sats are on outcome A. Another user, who thinks outcome A is not certain to happen makes a wager on outcome B of Y sats. Now, the odds of outcome A are X/(X+Y).
The issue is that X is underspecified:
How many shares should the first user receive? This determines how much they would win. If they bet X sats, that could mean they are very sure and want to buy only a few shares at a high price with low payout in case they win (making it attractive for a counterparty) or aren’t very sure and thus would only buy shares at a low price with high payout. This means that X = n*p where n is the amount of shares they buy and p is the price per share (= expected probability of outcome).
So they have to think about share price and how many they want. So they actually specify n and S which then results in X as the invoice amount. This is bad UX since I don’t want that traders have to think about such prediction market details.
Additionally, this means they have to wait until someone else shows up to match their bet. That’s where the money for the payout will come from.
So even if we fix p to 50 sats (assuming shares expire at 100 or 0 sats) initially, there is still an awkward wait which is also awkward to implement.
My idea with an automated market marker would allow them to instantly buy shares at a predetermined price. That price would update after each buy so traders could keep buying until the shares reach a price which matches their expected probability of outcome. So instead of matching bets against each other, the liquidity pool set up by a market marker willing to lose money since they would accept any trade becomes the counterparty in each trade. This would allow traders to simply specify how many shares they want to buy at the current price (= how often they click the BUY button).
Edit: I guess in your model, how much someone wins is a floating number. If they bet a lot on A but no one bet anything on B, they win nothing. If there is some money on B, it would get distributed to betters on A proportionally to how much they bet.
That’s something I considered but I don’t like this floating aspect. It disincentivises initial trading since it’s not clear what the risk/reward is which is imo an essential aspect of prediction markets.
reply
You're exactly right about the tradeoffs. The pooled system more easily allows for the interface you prefer, but at the cost of floating odds.
Either system should converge to the true probability, although the pooled system may do so later, because of the disincentive to early bidding.
reply
Cool, I can have a conversation with a real economist about real economy stuff and I actually understand what we're talking about. Does that mean I am something of an economist myself?
reply
I could see the meme before you added it.
reply
That's not really where we set the bar, but you probably do have a better grasp than many who hold the title.
reply