search

aragon / nest

A grants program to support the development of the ecosystem
https://aragon.org/project/grants
Creative Commons Zero v1.0 Universal
140 stars 78 forks source link

Aragon Oracle Manager and Futarchy Signaling Markets #158

Closed jpkcambridge closed 5 years ago

jpkcambridge commented 5 years ago

Aragon Nest Proposal: Aragon Oracle Manager and Futarchy Signaling Markets

Abstract

Futarchy, described as "Vote your Values, Bet Your Beliefs," offers a collusion resistant way for organizations to make decisions. By using prediction markets, participants are incentivized to evaluate a decision based on a given metric. For organizations aligned around given values, futarchy offers the promise of enabling well informed decisions without delegating power to the few. Futarchy offers the potential to be a liberating tool, and advancements in decentralized technology are allowing it to come to fruition. We seek to demonstrate and improve upon the Aragon Futarchy App, add an Oracle Manager App to Aragon, better understand futarchy in practice, and to educate the Aragon network and the public at large on the promise of futarchy by launching futarchy signaling markets for AGP votes.

Deliverables

Oracle Manager App

  1. UI mocks for Oracle Manager App
  2. Finalized Tidbit data-feed oracles (DataFeedOracleBase and MedianDataFeedOracle) with unit tests
  3. Oracle Manager App smart contracts
  4. Implemented Web UI
  5. Web UI integration with smart contracts
  6. Integration with Aragon Futarchy App
  7. Rinkeby Deployment

AGP Signaling Markets

  1. Signaling market specific UX/UI design
  2. Implementation of signaling market UX/UI
  3. Aragon futarchy app smart contract modifications for signaling markets (vs. decision)
  4. Tutorial videos and informational material on how to interact with the signaling markets
  5. Script or CLI to create new markets for each new AGP
  6. Oracle for AGP vote decision
  7. Oracle for ANT/USD price
  8. Oracle for DAI/USD price
  9. Oracle for ETH/USD price
  10. Rinkeby Deployment

Grant size

Funding: 130,000 DAI, split into chunks paid out over achieved deliverables. 4,000 DAI will be allocated towards funding the futarchy signaling markets. 1,000 DAI will be reserved for covering deployment costs.

Success reward: 30,000 ANT, given out when all deliverables are ready.

Application requirements

Development timeline

The development timeline will be the following one in regards to each deliverable:

June 2019

bingen commented 5 years ago

This is really exciting! Looking forward to have this implemented! Just a few small questions:

mikec commented 5 years ago

Thanks @bingen! I'm adding some more detail here that will hopefully answer all of your questions:

Tidbit Docs

We'll fix the generated docs site (create this issue to track). In the meantime, the current docs are here

Futarchy / Oracle Manager Integration

We would definitely like to create a DAO Kit with Futarchy and Oracle Manager - we think that will help make repeatable deployment of this model easier for us and for other developers in the future.

I'll describe our current thinking for the architecture of a Futarchy/Oracle Manager DAO, to hopefully clarify what we mean by "integration with Aragon Futarchy app". We're certainly open to feedback on this:

In this DAO model, the Futarchy App will rely on the Oracle Manager App to provide a final price resolution for all scalar markets. We will probably have to modify the Futarchy contract here to use the Oracle Manager App contract to create a new oracle instance. This oracle instance will provide the final resolution price point for a certain time in the future (the "price resolution" time). The Oracle Manager App is responsible for providing this price point...

The Oracle Manager App will have one or more price oracle addresses defined. On initial deployment of the DAO, these addresses can be provided. They can later be added/removed using IForwarder. For example, an "add" transaction creates a new vote on a Voting app, and the result of that vote determines whether the new oracle address gets added or not. So add/remove transactions are public and permission-less, but governance is forwarded to another app (voting, futarchy, etc). To provide the price resolution point to futarchy scalar markets (or any contracts relying on Oracle Manager), the Oracle Manager App contract will use the median or weighted average price from it's set of oracles.

To summarize, the flow of price data would be:

Data Providers (i.e. Uniswap Oracle, DutchX Oracle, centralized price provider)
 ---> Oracle Manager (stores a median or weighted average price)
   ---> Futarchy scalar markets (use median or weighted average price for final resolution)

Oracles for AGP Signaling Markets

As we considered your questions, we realize that we probably only need oracles for the AGP vote decisions and for the ANT/DAI price.

The oracle contracts will implement IOracle. The Oracle Manager App contract will expect all oracles to implement this interface. We'll probably have to make some modifications to gnosis/pm-contracts resolve scalar markets with an oracles that implement this interface.

We may opt to deploy Oracle Manager with immutable oracle addresses and effectively disable add/remove. For a price oracle, we would have a single address which could, for example, be an instance of a Uniswap integrated price oracle contract.

Collateral for Futarchy Markets

At some point we'll have to choose what the collateral token will be for trading on the AGP Signaling Markets. ANT may make sense to be better integrated with the Aragon community, but DAI or ETH could also make sense to make the markets more easily accessible to a wider audience.

Uniswap

It would be great to have Uniswap as an option for a price oracle. There are issues with using Uniswap directly as a price oracle, as discussed here. We are watching what is being done with Polaris and could potentially utilize it for AGP Signaling Markets using the Aragon Oracle Manager App. If we had the time and it was high enough priority, we might even implement our own Uniswap price feed oracle and/or use fees from futarchy trading to incentivize the data feeds.

bingen commented 5 years ago

Thanks a lot for your explanations @mikec !

So add/remove transactions are public and permission-less, but governance is forwarded to another app (voting, futarchy, etc)

Wow, using Futarchy app to decide about Oracles used by Futarchy app... :open_mouth: haha

We may opt to deploy Oracle Manager with immutable oracle addresses and effectively disable add/remove

Hm, not so sure about this. What would happen if that initial oracle becomes useless or malicious for some reason? Like it has a bug and gets hacked or whatever... But I guess we can discuss this later.

mikec commented 5 years ago

@bingen yes, that would be quite meta :) We won't plan to do that for the Signaling Markets launch, but we do want to make it possible for other DAO's that install this app to do with IForwarder.

As for the immutability of the oracle for Signaling Markets price resolution, there are a few different approaches we've thought of, all with different tradeoffs:

1) Have 1 immutable oracle 2) Give our address permissions to change the oracle 3) Forward requests to change the oracle through a voting app instance

Option 1 is probably the most "decentralized" approach, but could be problematic if the oracle breaks. We could mitigate a broken/malicious oracle by redeploying the DAO and encouraging users of the original DAO to use the new one .. could call it a hard fork :)

Option 2 makes it easy for us to fix the broken/malicious oracle, but also puts a lot of control on us as the deployers of the DAO, which we are trying to avoid.

Option 3 Makes it relatively easy for users of the system to fix a broken oracle, and is potentially more "decentralized". But it requires us to deploy Signaling Markets with a native token (for voting), which we're trying to avoid due to the complexity of having to distribute the token.

Not necessarily something we need to decide immediately, but we should definitely discuss and finalize the approach before launch.

bingen commented 5 years ago

Would it make sense to have option 3 with each DAO that has a Futarchy app installed having its own instance of the Oracle Manager? (So, the Oracles would be shared, but the app itself would be an instance/proxy per DAO). This way each DAO could give permission to set the Oracle to its own Voting app (therefore using its own native token). I think this way would be more flexible, as each DAO could easily decide which Oracles to use, and the way they want to govern it.

mikec commented 5 years ago

@bingen, yes that makes sense - maybe that could be the setup for the Futarchy DAO kit. For the Signaling Markets DAO we may opt for a different setup since we're hoping to avoid deploying a native token, but using Futarchy/Oracle Manager/Voting definitely makes sense for a general DAO setup.

lkngtn commented 5 years ago

Option 3 seems the most appealing imo, it is super easy to have a native token and it can simply be a non-transferrable token that is distributed to specific community members initially which would need to coordinate in the event that there is some issue with the oracle. Sort of like a community multi-sig.

It also seems like something that would be trivial to decide on later, so we do a wider survey to help select between the three options?

mikec commented 5 years ago

@lkngtn a community multi-sig approach sounds good. We could do that initially and avoid having to deal with the complexities around a wider token distribution.

Also like the idea of surveying the community on this and other architectural decisions for the Signaling Markets launch.

LouisGrx commented 5 years ago

Hey LevelK team,

Thanks for these detailed answers. We’re happy to see this new proposal gathering the implementation of signalling markets for AGPs using Futarchy and the development of an Oracle Manager app. Both of these are very exciting.

The proposal fits the Nest philosophy very well as the deliverables you are providing here are either 1) complementing the Flock roadmap with the Futarchy implementation and 2) helping Flock teams deliver the Aragon Court with the Oracle manager App.

We’d like to see you submit a request for funding and will approve this first proposal.