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

[GraemeB]

TL : DR

This forum post puts forward an idea of using conditional tokens to facilitate DAOs working with other DAOs to swap tokens and fund new projects.

Let’s take a scenario. DAO A wants to partner with DAO B to create a new product which benefits both DAOs.

For example’s sake, we need to satisfy the following requirements:

• DAO A gets a pre-negotiated amount of DAO B’s tokens.
• DAO B gets a pre-negotiated amount of DAO A’s tokens
• The team responsible for building and managing the new product requires a pre-negotiated amount of funds from both DAO A and DAO B to do so.

Using the conditional token framework, we can create a token representing successful funding of the new products wallet by both DAO A and DAO B. It would look like:

YES - “Will DAO A invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?” && YES - “Will DAO B invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?”

How do we create a token redeemable for collateral only when the two conditions have been met?

First things first let’s create a condition representing DAO A providing funds to the new project’s wallet.

“Will DAO A invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?” This question should have two outcomes, “Yes” and “No”.

We will need to create a condition for this question for DAO B.

“Will DAO B invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?” With the same outcomes of “Yes” and “No”.

Now with these two conditions and the magic of the conditional token framework, we can do something special.

DAO A can send the negotiated amount of stable coins to the conditional token contract specifying the ID of condition “Will DAO A invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?” to produce the negotiated amount of conditional tokens representing:

YES - Will DAO A invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?"

And

NO - Will DAO A invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?"

Next step would be for DAO A to “split” the negotiated amount of conditional tokens representing, “YES - Will DAO A invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?”, by the condition “Will DAO B invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?”.

The result would be DAO A possessing the negotiated amount of conditional tokens:

“YES - Will DAO B invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?” && YES - Will DAO A invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?"

And

“NO - Will DAO B invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?” && YES - Will DAO A invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?"

And

NO - Will DAO A invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?"

What does DAO A do with these tokens?

Well, they keep

NO - “Will DAO A invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?”

And

“NO - Will DAO B invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?” && YES - Will DAO A invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?".

But send:

“YES - Will DAO B invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?” && YES - Will DAO A invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021?"

To the wallet address of the new product team.

Now DAO B goes through the same process, so it has the same conditional token set as DAO A but in the amount that it has agreed to fund the new project. Suppose DAO B decides to send its conditional tokens representing successful co-operation to the new product team. In that case, it will mean that the wallet owners representing the new product will be able to redeem the conditional tokens for stable coins.

However if one of the DAOs does not send through its conditional tokens or does not send through the amount negotiated, then the project will not be able to redeem their conditional tokens for collateral but the DAOs would.

But wait, how does this facilitate token swaps between the DAOs?

The DAOs can mint outcomes as before, but they use their projects token as collateral.

DAO A and B go through the same process as above to mint conditional tokens. Instead of using a stable coin as collateral, they use their token respectively and send the conditional token representing successful funding of the new product to each other. This way, if the new project’s funding is successful, both DAOs may redeem their conditional tokens for the other DAOs token. Of course, the swap of these conditional tokens would need to occur before sending tokens to the new project’s wallet.

Conditional tokens can facilitate very granular and nuanced agreements. A token can represent every point of a contract. Moreover, they can be structured so that all conditions need to be met to be redeemed for collateral. Of course, the wording of these conditions would have to be very specific and much like how regular legal contracts require lawyers to draft them, I’d imagine that legal professionals working in the blockchain space will craft these conditions to ensure their interpretation is watertight.

**A caveat to this is one could argue that "Will DAO A invest the negotiated sum of stable coins into the new project’s wallet before 28th of February 2021? would not resolve to true because technically this is only possible when the tokens have been redeemed. I believe that it will require structuring the conditions in a way which is far more programmatic than natural language. Something that would look for a specific amount of conditional tokens, from a specific wallet address and sent to a specific wallet address before a specific time.

[cemfd]

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.

[wei]

the dao is good for the community，I hope you’re right

[LuukDAO]

Hey! This article may help spark the conversation here: https://twitter.com/PrimeDAO_/status/1371501823983562754

[auryn_macmillan]

Early conversations with the PrimeDAO folks is actually what inspired this

[zhansheng3]

I would expect I’ll probably be comfortable supporting a consensus of many others to support
IF that broader consensus also develops.