Prediction markets are composed out of two things. First a mechanism to create tradable asses (shares/tokens) that gain in value if a specific event does happen or does not happen. The second component is a market place to trade those tokens. You could use a regular continuous double auction (simple sorted order book of bids and asks for one trading pair)
However - if you have ever traded cryptocurrencies you are well aware of the limitations and inefficiencies of such markets. Simplest example is a market with three trading pairs: ETH:BTC, BTC:USD and USD:ETH. Often you find situations where simple arbitrage is possible or at least the spread for one market is very big although a competitive spread could be constructed by the other two markets.
When we look at prediction markets this problem gets even bigger because the goal of prediction markets is to make more events tradable and this phenomenon occurs only in low liquidity markets when no one is incentivised to do arbitrage/market making. However, even if we would have those market makers it would be more favourable if this mechanic task is automatically done by the market place because this would increase the value people can get for their trades that do provide information.
There has been academic research on this topics …
Features we should have:
- Trader lock down assets € of A.
- During a trading period they can make any kind of trades that consist of bid and offers of assest in A
- After each trading period anyone can try to find a solution to this optimization problem of trades.
The solution should contain most importantly a single price for each asset and it should not violate any trades. If orders are set at a specific price (buy 100 ETH at $4) then the solution also have to include the quantity if the ETH price should be exactly at $4. However - the goal would be to make the solution in data size as small as possible. In addition it should contain the total trade volume and finally some a merkle root of all the trades with the state change this trades triggers as leaves. Building up the tree it should sum up the trade volume and make sure that all assets traded in total are equaling out.
With this structure it would be easy to check this merke root given the clearing prices and the needed trade volumes. Now everyone could challenge this result. If it is technically valid they can only challenge it by submitting a new result with higher volumes. If the merke root is not valid then it should be easy to challenge it. Challenges could be: a trade is not included although it should be given the clearing prices. The aggregates balances sheet of assest is not all 0 (assest are lost or created out of thin air in this trade result). The addition of trade volume in 2 trades is not correct.
The problem that I see is that if might need ln(n) challenges to prove that a given root is wrong - it would be nicer if one challenge would do it.
A more technical description will follow.