pull down to refresh

Me researching how to best lose money with delphi.market:
We are interested in the design of prediction markets, or markets where price discovery is the designer’s end goal and trading is a means to that end.
For example, suppose a policymaker seeks a forecast of the likelihood of an avian flu outbreak in 2008. He may float a security paying $1 if and only if an outbreak actually occurs in 2008, hoping to attract traders willing to speculate on the outcome. With sufficient liquidity, traders will converge to a consensus price reflecting their collective information about the value of the security, which in this case corresponds to the market’s estimate of the probability of outbreak.
[...]
Traditionally, market makers are human decision makers seeking to earn a profit.
In contrast, a prediction market designer may well subsidize a market maker that expects to lose some money, in return for improving trader incentives, liquidity, and price discovery. The market maker’s loss can be seen as the cost of gathering information for more accurate forecasts. Of course, the market operator cannot afford to lose arbitrary amounts of money; typically he or she will want to set a maximum bound on the market maker’s loss, ensuring that no matter what happens, the loss cannot exceed the bound.
I am currently at the point where I have to decide how prices are calculated. I want to show the price next to BET YES or BET NO. I am basically trying to work from UX backwards to how the market should work:
I previously had the idea that everyone would provide liquidity which means that rather than having already a price for betting, the traders would post their prices and their orders would be matched. So instead of simple buttons, I would have to maintain an order book.
This is annoying to implement and bad UX.
If I have a simple algorithm to determine the price, an automated market maker, and am willing to lose money, then everyone could execute their trades immediately, improving UX.
Anyway, interesting paper. Still on page 3, but already wanted to share.
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).
reply
30 sats \ 4 replies \ @ek OP 24 Aug
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
26 sats \ 2 replies \ @ek OP 24 Aug
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
This looks interesting.
Is it live yet
reply