Para Oracle

[KillariDev]

Para Oracle (PO) is an oracle that is build on top of Augur protocol. PO has its own disputing rules on deciding on the outcome. However, if the dispute grows big enough (this can be decided by time, by monetary value, by number of participants or by other means), PO will give up on its powers to Augur's oracle. After Augur oracle's disputing protocol is triggered, PO will resolve to the outcome that the Augur's Oracle results in.

Augur ecosystem can support multiple PO's at the same time, all with their own disputing rules and parameters. In an optimistic scenario, a PO's can resolve in a really short time span.

An example how a simple Keynesian Beauty Contest Para Oracle could work:

• When the market is ongoing, PO will report its OI and pay the fees to Augur normally
• When the Augur market is finalized, the market creator will report on the Augur market
• Keynesian Beauty Contest disputing process on Para Oracle is started right after the markets reporting is started
• When PO's Keynesian Beauty Contest succeeds on deciding the outcome, the market resolves and users can redeem their shares for DAI
  • Augur's core market goes on as normally and CAN resolve into different outcome than PO did
• If Keynesian beauty contest reaches total value at stake X or it takes too long to resolve, PO will halt its disputing process and feed the staked REP into Augur's disputing process. Then Para Oracle waits until Augur disputing process resolves and release funds according to the Augurs outcome
  • If Po's disputing process takes too long (but not long enough that we want Augur to decide on the outcome), PO can extend Augur's market resolution time by staking REP on the Augur's market.

[pgebheim]

This proposal is likely to be important for the future development of Augur in a few scenarios.

• Allowing the addition of a parameterized Oracle, or system of Oracles which are governed by REP holders, so that Augur can evolve with the needs of the community.
• Opening up the design space for Oracles to take advantage of Augur Core's forking design to act as a backstop for other dispute systems.
• Allowing reporting to potentially exist on Layer2 chains.

The first and foremost use case for the proposed system work be to speed up oracle resolution, and to correct some of the rough edges Augur v2 reaolution is currently encountering re: the cost of disputing.

I'm very in support of this idea, and will be adding a bit to the discussion in terms of implementation details and architecture for accomplishing various objectives. I'd love to hear other takes on the overall system during this process to make sure it meets the needs of the wider community.

[nuevoalex]

Why does the core Augur market get created before the PO market rather than only creating the core market on demand when the PO resolution process has to fail over?

Assuming we need the core market initially the exact rules of when the PO market extends Augur core. In any case it would seem the core market could resolve before the PO market which would be bad if the PO dispute ended up reaching its time limit or threshold.

[KillariDev]

The on-demand market creation is not aligned with current disputing rules. Current disputing rules would make such market invalid. The original concept of PO was intended to be a module that aligns with Augurs rules. Ofcourse the rules can be changed and then we can support such JIT markets.

The initial reasoning for banning such markets on Augur was they are all parasitic and harmful for the oracle, and we can easily defend agaist them just by banning them. However, if the PO behaves nicely (reports OI and pays fees ahead of market creation), then I don't see why reporters couldn't allow such markets.

I dont understand your second point, PO can never resolve after Augur as it would query augurs market if its resolved or not. Augur markets resolution is ALWAYS the upper bound for PO.

[pgebheim]

My suggestion here is we lobby reporters tk change this to make markets created Just in Time. By arguing for the better model we get a much more open system and I don't believe it is actually problematic.

I will write a proposal for this under the conditions of the ParaOracle.

[pgebheim]

I feel like its worth referencing this implementation of the symbiotic augur oracles -- #10726