Have an Oracle create a utxo like I do in tornado factory, where all the money in an n-of-n utxo goes, at first, to the Oracle, and where each key in the n-of-n is actually a 2-of-2 “sharded key,” where a statechain operator has one shard and the Oracle has the other. People can pay 10k sats to the Oracle to “buy” one of his or her shards. With it, the buyer contacts the statechain operator and obtains a cosignature on a tx that gives them the right to withdraw 2 10k-sat increments of the money from the n-of-n utxo (per my tornado factory protocol), except their withdrawal txs are not valid unless the Oracle says the result is a Yes (or No, if the user bought No). I will call these “right to withdraw” keyshards RTWs and those are what you’re buying and selling in these markets.
The above idea relies on the assumption that you can only withdraw using your signature if the Oracle announces a result in your favor. I think it’s possible to achieve this via adaptor signatures, but it sounds easier to me to do so via connectors which the Oracle must create. To sell your RTW to someone, you list your keyshard for sale and sell it to the highest bidder, who then contacts the statechain operator and gets a signature for a withdrawal tx whose timelock is smaller than the one on the signature of the withdrawal tx of the prior holder (i.e. you). When the Oracle announces the result, he or she creates connectors allowing only the Yes people or only the No people to withdraw, and then they do so. The ones who currently hold the RTWs (per the statechain) get to withdraw first because their timelocks expire first.
A problem with this idea is this: the market might favor one side so heavily that not all of the opposing side’s RTWs get sold. In that case, the market maker (i.e. the Oracle) ends up with a bunch of irredeemable RTWs and will incur a loss on his or her investment unless he or she announces a result that favors the side that (probably) lost. So this messes up the incentives. I think I can partly fix this by separating the role of the market maker from the role of the Oracle, who, on an unrelated note, can publish the connectors for free by making them v3 transaction outputs where the buyer has to pay the fee for their creation in a subsequent tx that simultaneously consumes them.
Assuming I adopt the above partial fix, it’s only a partial fix because the market maker can still end up with a bunch of irredeemable RTWs, but at least he or she can’t cheat by announcing a false result (because the Oracle is a different person with different incentives). I think it just means this model is only profitable if you create markets where all the RTWs are likely to get bought – i.e. markets that are split roughly 50/50 from the start – and that’s fine.
It might not even be true that initially-50-50 markets are the only markets that will be profitable to create; I suppose a market maker can sell the popular side’s RTWs for any price, and just charge a price that makes him or her profitable even if he or she only sells Yes RTWs (or only No RTWs). If the values accrued by these Yes RTWs go up on the open market, the buyers of the “popular side’s” RTWs can still make a profit too by selling them to other people, and I think that works even if no one ever buys the opposing side.
Another problem [**EDIT: I don’t think it’s a problem anymore, keep reading] with this idea is that I don’t think it makes sense for the value of an RTW to ever exceed 20k sats. They are only a right-to-withdraw 20k sats at most. But I guess that’s fine; they just cost (presumably) around 10k sats at first and then rise and fall within a range whose minimum is 1 sat and whose maximum is 20k sats. And markets are weird, there might be situations where someone is willing to pay more for an RTW than they’ll actually be able to redeem it for, solely for bragging rights or because they think someone else will buy it for even more money later.
Also, a positive that just occurred to me with this model is this: I’ve already conceived a way (called Insured Statechains) to give users a real unilateral exit from a statechain, so that they do not lose money even if the statechain operator colludes with a prior holder to doublespend your money. And I think I can apply that model to this idea. The insurer just needs a way to recover his money in one of two cases: either (1) you won and got your payout, or (2) you lost so you don’t get a payout.
The first case seems easy to resolve the same way I already resolve it: have your payout be the second output of a transaction that sends the insurer his money back, so that he only gets his money back if you get your payout. But then I need a second way for him to get his money back; which seems solvable with a connector: if you lose, just have the tx that consumes the winner's corresponding connector only be valid if it creates a connector whose existence proves the insurance-purchaser lost. Then have a second way for the insurer to get his money back, namely, in a tx that consumes the second connector.
Since the insurer can recover his money in either of the above-listed two cases, the statechain users do not have to trust the statechain operator in order to exit with their money (assuming they win); and this means the only new trust assumption in this model (beyond bitcoin’s standard ones) is that the Oracle must give an honest result. He is trusted to do this by the insurance provider and by all users. But I think that's okay; it's still just one new trust assumption beyond the base layer's trust assumptions, and that, I think, is as good as polymarket does on the particular issue of "what are the trust assumptions." (Actually it's better, because bitcoin has better L1 trust assumptions than ethereum does.)