How to facilitate DAO to DAO co-operation using Conditional Tokens

Knowledge Base Archive
,
2

Hi Graeme,

We (Curve Labs) are already working on using Conditional Tokens for DAO to DAO relations, focussing on enabling a Joint Venture*(JV) for our first proof of concept, instead of a Token Swap as you have described. There are several areas that we’ve been researching that we’d like to share.

*For the purposes of this prototype we define a Joint Venture as two parties co-funding a multisignature wallet for the purposes of creating a mutually benifical project.

We have broken the DAO to DAO (D2D) prototype into the following stages:

1) Negotiation
This stage is a currently under-discussed aspect of the D2D process (as highlighted in focus of discussion in this DAOTalk post regarding a D2D collaboration between dxDAO and GnosisDAO).

  • The proposers of the JV draft a proposal.
  • This proposal contains high-level goals of the JV, as well as certain parameters required by the negotiation protocol:
    • collaboration proposal summary / overview (e.g. link to external collaborative doc, other attachments)
    • proposal authors
    • DAOs involved
    • funding amount DAO1
    • funding amount DAO2
    • Co-funding due date (UNIX timestamp)
    • JV address (Gnosis Safe)
    • Oracle information (Ethereum Address, type of Oracle, other relevant information)

A checksum is also created for the document, via which each DAO can check the integrity of the proposed parameters. The questionIds needed by the conditional tokens framework for each question (‘will DAO1 fund the JV as described by the checksum 0x000000?’ & ‘will DAO2 fund the JV as described by the checksum 0x000000?’) will also be created.

  • Upon agreement, the D2D module outputs a sharable version of this proposal of the preliminary agreement which can be disseminated amongst the relevant DAOs.

2) Agreement

  • Both DAOs deploy treasury contracts via which they can interact with and hold conditional tokens (CTs). The deployment and initialization of the JV multisignature wallet to be funded is left to the DAOs to facilitate themselves.
  • The respective DAOs vote on the proposal** which, if it passes, triggers their respective treasury contracts to do the following***:
    • Create a condition (‘will DAO1 fund the JV as described by the checksum 0x000000?’) which is split into 2 positions (Y/N), which is subequently further split by a second condition (‘will DAO2 fund the JV as described by the checksum 0x000001?’).
    • Retain the CTs denoting the ‘no&no’ & ‘yes&no’ positions, and transfer the ‘yes&yes’ tokens to a prearranged multisig address which will be used to fund the JV (we’re planning on using a Gnosis Safe).

**If either vote fails, any stakes that have been sent to the negotiation contract are reimbursed. This process can be interated upon until an agreement is reached by both DAOs.

***In the case of a DAOStack DAO utilizing the multiCallGenericScheme, this can be done via a single proposal.

  • So long as no circumstances arise that cause one of the DAOs to be unable to send their CTs to the JV multisig, the Oracle contract - via a smart contract call - checks the balance of the multisig at the agreed upon time. If necessary (and agreed upon by both DAOs), the time limit for funding the JV can be extended via a smart contract call to the Oracle.
  • Once the time limit has passed and the balance has been checked, either the DAO or the JV multisig redeem their CTs.

There are multiple avenues of research and development that have to be done before D2D can be fully operational. We’ve broken the field down into these primitives, and we’re prototyping using simple instances of each:

  • ERC1155 interfacing

Due to contract addresses having to implement the ERC1155Reciever interface to accept and send CTs, we are currently working on creating a treasury contract via which the DAO can interface with and hold CTs. In the case of the JV, the only component of the DAO that interfaces with the conditional tokens framework is this contract. Since this opens up a possible attack vector, our focus is on keeping the code as minimal and controlled as possible, with focus being on access control.

  • Treasuries

Different DAO architectures will require treasury contracts with different specs and functionality: as this prototyping work is being done on behalf of PrimeDAO, we are developing for DAOStack. Future development will be partially focussed on making this mechanism as DAO-agnostic as possible by offering templates for DAOs with different architectures / design patterns, such as Aragon and Moloch.

  • Oracles

As CTs rely on an Oracle to report the final outcome of the condition, different forms of agreement may rely on different types of Oracle (see API3’s distinction between first- and third-party Oracles), perhaps due to the location of the data that is being read (on- or off-chain), or the type of data (objective vs subjective information).

  • Interfaces

We are currently working on a roadmap for a D2D interface, the first iteration of which would be to create an interface via which the proposal template and parameters can be generated and uploaded to IPFS. We are also working on specs for an ERC1155 / D2D blockexplorer interface, via which proposals (and their status) can be easily checked.

We’re currently actively developing on these ideas, and would be really interested to hear any feedback or ideas you have. If you want to look into our research more in-depth, here’s a link to a research report we published in January.

2 Likes