We’ve developed a way to sharply reduce the duration of our market resolution period – from two months after a predicted outcome can be determined to as low as three days or less – and in a way that doesn’t sacrifice security.
Faster event resolution and the two-month vote period is something that’s been discussed a ton. Let’s address some of the issues surrounding it, why the two month period is in place, why many of the proposed solutions to speed it up are unlikely to work whilst maintaining security and the solution we’ve gravitated toward.
Why the two month period is in place:
The concept of having to wait multiple weeks to close a market would lead to less popularity of Augur, right? Maybe. You don’t have to wait: sell your shares. People sell shares for 10%+ counting spreads + fees + cc etc. all the time during regular wagers. <1% to get out early is very little compared to that. Making reporting happen quicker in practice isn’t too hard, but no one really knows that it’s actually needed: [economics + complete sets says it’s not needed, in practice however it’s likely a good thing]. It could probably be used to make things cheaper for market creators as well [as brought up by Micah in the Augur slack], which is another valid reason to implement it.
Ways that don’t work too well:
- Auto closing markets over n% for one outcome:
- With an order book this is easily manipulable by doing a trade for one outcome.
- That said, it doesn’t directly weaken security provided there’s a window to post a bond to force regular reporter resolution.
- The market “creation fee” to pay the minimal number of reporters for a market would be returned in the success case, part of trading fees still go to reporters so they continue to be able to provide security in auto-close fail cases.
- If reporters agree w/ auto-close bond poster loses the bond, if they disagree bond poster gets rewarded.
- Markets should be closed immediately once n reporters report or once y rep reports:
- For practical reasons, if you require a reporter to report on z events, say it’s 10, and the events get closed immediately after [randomly picking here] 3 reports, what if other reporters report first, then this reporter [who has to report on z] tries to report but can’t? The system has no good way to tell whether they were simply lazy/out of commission for whatever reason or whether they truly couldn’t get a report in in time. Note: even if not closed immediately this problem still arises in this schema.
- Depending on the size of n or y, we may be “using too much security than we actually need to” – if a person can always post a bond to enter the regular reporting process, using a high n or y up front wouldn’t make sense.
- Resolving this way limits security to a) unknown [in the case of n reporters report] or b) y/11Mth of the security we would currently have.
- Don’t want high value markets to be reported on with trivial security.
- Split reporting period into n week chunks, each reporter gets assigned a week:
- Almost the same security model.
- Isn’t cheaper in any sense.
- Faster resolutions, but “not as fast as it could be”.
To clarify: the security is in the ability to submit a bond and use the full effect of rep as security. There always needs to be the option of bonded backstops [the ability to challenge the reporting process, leaving us with a similar 51% attack model to bitcoin or Ethereum, with the ability to fork as well (and by fork we mean fork rep, not Ethereum)]. The security of the first round of reporting doesn’t really matter unless we used it to _actually_ resolve without the opportunity for use of the full security model with backstops. Without the backstops, the security model is essentially nil.
- “Given x resolution address resolving within y date then if bond hasn’t been posted within n days or hours then resolve”
- “Given oraclize.it, smartcontracts.com, or realitykeys resolution within y date then if bond hasn’t been posted within n days or hours then resolve, but if a bond is posted then use the full reporting backstops system”
Given that both of the workable solutions above are generalizable to the same thing, we can come up with a protocol for allowing a strong security model that includes the full backstops of reporting, whilst at the same time allowing quicker resolutions. Even if the quicker resolutions above were wrong 99% of the time, we’d still be adding more economic efficiency to the platform, which is a good thing.
Quick resolution process:
- Market creator chooses an address/contract that can resolve a market.
- If resolver doesn’t resolve by 3 days, anyone can basically push it into the regular reporting cycle.
- A bond poster can challenge within n, say 3 days of resolver’s resolution by pushing it into the regular reporting cycle and posting a bond.
- If the outcome of the challenge is the same as original and isn’t challenged again [so at this point we’re into the regular reporting system backstops], then the bond is lost as it was a waste of time/money.
- If the outcome of the challenge is the same and is challenged again (so backstop 1 here), the bond is returned.
- If challenge outcome is different and isn’t challenged again, bond returned + n profit.
- If challenge outcome is different and is challenged again (so backstop 1 here), bond returned.
We don’t want to have challenge outcomes after the first bond poster (so the regular backstops) affect bond return or profit because then it gets too complicated so we simply return the bond if the outcome is challenged again in the regular reporting backstops [which are 1) where everyone reports on a given event and 2) where the rep forks].
And that’s it! With this system we can now have events regularly resolving essentially immediately after the event occurs with a 3 day period to challenge the resolution before it’s made final as opposed to having to wait two months every time.