it's going to be binary markets only at first however
so literally just "Will X happen?" and you can buy YES or NO shares.
If you want to buy YES shares, someone else needs to buy the same number of NO shares. The price only differs. So if I think X is going to happen with a chance of 90%, I would buy YES shares for 90 sats each since I'll get 100 sats per share on expiry if I win. So a profit of 10 sats per share.
This means someone else needs to buy the same number of NO shares but for a price of 10 sats each. They'll win 90 sats per share.
A market evolves since you'll be able to sell your shares to others (at a different price you bought them). So you could sell X of your YES shares to someone else at 95 sats per share and exit the market with a profit of 5 sats per share before the market concludes.
If I did the math right, the market should stay solvent in any of such cases.
I also intend to use HODL invoices for these trades. So your sats for buying shares will only be sent if there is actually a counterparty available.
Also, I'll hold the funds. So it's going to be fully custodial. I'll ship on regtest first until I am super sure there are no bugs - at least no critical ones.
Looking forward to it
How do events get originated?
reply
Oh, great question, forgot to mention some things around that: You can simply create ones but I'm wondering if they should be approved by me first since if two parties can't agree on the outcome of the event, I'll have to step in as arbiter of truth. If the event is not easily verifiable, it's going to be hard.
I'm also thinking about requiring a bond which the party will lose that I decided has lost if the parties don't achieve consensus. So there is incentive to be honest since hopefully, I'll be able to tell who is the real winner easily anyway.
reply
That oracle issue is tricky. It certainly doesn't seem like manually doing it would scale very well.
Essentially instituting a fee for disagreeing, gets you into a very interesting area of experimental economics. There are lots of circumstances where people are willing to pay their own money to make someone else lose theirs. As an irrational sports fan myself, I can imagine being willing to pay the fee to make sure someone didn't win a big reward (in certain circumstances).
That said, the bond approach is generally considered to be the incentive compatible approach.
reply
It certainly doesn't seem like manually doing it would scale very well.
Yes, but hopefully, I'll be able to find a better solution if this becomes a problem. A easy solution would be to limit market creation. So not many decisions required.
There are lots of circumstances where people are willing to pay their own money to make someone else lose theirs.
Yes, I can see that. But in this case here, only the loser would pay the fee. So you can't pay money to make someone else pay money afaict in this bond model 🤔
reply
Oops. Pardon my morning brain.
The bond is basically just the fee for making you look up the outcome. That's a great solution, because you can keep increasing it as volume increases, if you need to.
reply
The bond is basically just the fee for making you look up the outcome.
Exactly :) But I hope these will be just edge cases. I hope that 99.9% of trades will simply agree in the outcome and move on.
Something interesting is if it would ever happen that there are different agreements within the same event. If markets are clearly determined, this should never happen right? Someone who is right would never vote that they lost on purpose, right?
Basically, I am trying to circumvent the need for an automated oracle by making the incentive as bad as possible to not be honest. Because I have no idea how to create an automated oracle, especially if I want to allow user-generated markets, haha
reply
Someone who is right would never vote that they lost on purpose, right?
I wouldn't think so, but mistakes happen. If the parties get a warning message that there is disagreement on the outcome and they will lose their bond if they are wrong, that gives them a chance to make sure they entered the right answer.
If both parties agree on the wrong outcome, it would be pretty weird, but I guess that's their right.
If I'm understanding, there will probably be multiple instances of the same event, right? Each bet is just between two people, so if 20 people want to bet on a particular event there would have to be a bunch separate bets. You could link the outcomes of all these events and use a majority agreement as the oracle, instead of a consensus.
reply
If I'm understanding, there will probably be multiple instances of the same event, right? Each bet is just between two people, so if 20 people want to bet on a particular event there would have to be a bunch separate bets. You could link the outcomes of all these events and use a majority agreement as the oracle, instead of a consensus.
Yes, you're understanding right.
I could use a majority agreement, but I already have a timing problem with the "P2P oracle": how long should the timeout be, when one party will simply win because their counterparty didn't show up?
If I use a majority agreement, that gets even more complicated for not enough benefit imo.
And that could definitely introduce risks of oracle abuse. Something I want to avoid as much as possible.
I also like to keep the P2P vision alive, even though it will be a centralized service :)