Implementable Tools to Extend DAO Interaction Patterns in D2D Research Phase 2
This piece is the first output of the 2nd DAO2DAO research workcycle between Token Kitchen, BlockScience and Curve Labs, funded by PrimeDAO. While our previous research digest and associated literature review and community report focused on an early exploration of DAO conceptual models and real-world precedents in foreign relations, this workcycle focused more on exploring recurring systems patterns, then selecting a few for further detailed review and potential implementation. Article by Cem F Dagdelen, Jeff Emmett, Max hampshire, Shermin Voshmgir, and Michael Zargham.
Introduction
Our aim in this research cycle was to dive deeper into a few promising mechanisms for further research & potential development for the PrimeDAO ecosystem in particular, as well as D2D interactions more generally. We have identified joint ventures and the co-funding of research as some of the highest leverage areas for DAO2DAO collaboration, for which we are exploring two collaboration mechanisms for further implementation research: (1) the Proposal Inverter and (2) the Conditional Tokens Framework.
The structure of this research digest is as follows:
- Recap of D2D Research Workcycle #1
- Recurring Systems Patterns & Mechanism Design
— 2.1. Co-Funding Research: The Proposal Inverter
— 2.2. Joint Ventures: The Conditional Tokens Framework
1. Recap of D2D Research Workcycle #1
In the first phase of this DAO2DAO research collaboration, we identified that new metaphors are needed to describe phenomena in the Web3 world, so we can do justice to the range of opportunities that arise with new technology that might be hard to describe otherwise. In our first research cycle we examined conceptual frameworks for DAOs using different metaphors:
- DAOs as a non-state actor in International Relations framework
Taking a nation state perspective of the world, we identified DAOs as a new class of non-state actors in the context of international relations. We proposed that “DAOs, in their institutional structure, have more resemblances with nation states and global markets than with firms. This resemblance has less to do with size or scale of DAOs than the fact that they can operate without being embedded in a higher-level institution that enforces particular interaction patterns, for example a shared legal jurisdiction to serve as a backstop for conflict resolution.” - DAOs as Networked Islands
A DAO can also be described as a new form of autonomous virtual island. Just like the networked islands of history, despite their isolated context, have been catalysts of trade and cultural exchange, DAOs today have a social formation within their island and also with other networked islands, where trade and exchange are just being negotiated in the context of novel parallel financial systems.
In the first phase of our research we focused on scoping the overall research framework landscape, identifying suitable analogies and terminologies while examining a set of existing frameworks and new primitives applicable for ongoing applied research.
We produced the above diagram to explain the structure of complementary research & development initiatives, and the different layers (and timescales) of innovation that they lie on. Research processes necessarily require large amounts of work to go from theory to practical implementation, but this work lays critical foundations to later deployments. We must be careful not to fall prey to the free-rider problem within our own R&D cycles.
We hope these research digests can provide building blocks in the process of creating (to quote Samo Burja) “intellectual legitimacy” for these unfolding concepts that exist on the frontiers of crypto-institutional design. Our focus in workcycle #2 was to balance theoretical analysis with practical implementation directions. For this reason, this first digest will focus on promising mechanisms identified in our research, and following digests will present further discussion on theories of DAOs & the firm and how to represent and understand DAO power structures.
Before we deep dive into the early findings of our phase 2 research, as a reminder, here’s a summary of our phase 1 research:
Summary of Conceptual Models for DAO2DAO Relations
We first described the history of DAOs from a cybernetics and Web3 perspective defining terms such as autonomy, automation, and decentralization. We then proposed a few conceptual models to understand DAOs from an institutional economics perspective introducing an interscale model for institutions (the micro-, meso-, and macro level and their feedback loops) and defining the type of relationships between agents (DAO members) and institutions (inter-DAO or DAO2DAO). We looked at characterizing DAOs on a spectrum of five attributes: (i) transaction costs, (ii) information availability, (iii) sovereignty, (iv) trust level, and (v) rigidity.
We also stated that this framework lacks an important attribute relevant in the context of DAOs: Power Structures — as the concept of power structures did not fit into the spectrum framing of the model presented for identifying a type of DAO. Power structures are “relational” and not well modeled as a spectrum, but could instead be represented with the directed graph formalism. We will address this topic in more detail in an upcoming digest. To conclude, we examined existing concepts in International Relations and what analogies and research questions would be relevant to D2D relations.
Summary of D2D: Towards Decentralized Negotiation Protocols
Curve Labs based their research on the concept of negotiation and its reduction through formalized or non formalized norms, rules, and institutional frameworks such as social groups, firms and bureaucratic institutions, or — as applicable in Web3 — distributed and automated consensus protocols as in the case of DAOs. They further identified a number of coordination mechanisms between DAOs for various purposes such as (i) strategic communication, (ii) co-funding of research, (iii) co-funding of development, (iv) any other type of joint venture, (v) a common monetary policy, (vi) polycentric governance/policy design. They identified that the Conditional Tokens Framework (CTF) introduced by Gnosis (which was developed in the context of prediction markets) can also be adapted to the context of more complex D2D collaborations. They outlined a protocol for D2D collaboration that allows for iterative negotiations and shared funding via an escrow smart contract, a prototype of which will be presented in this research cycle (read more in Section 2 of this digest). As topics of further research, they identified the need for an oracle taxonomy or third party oracle services for common good scenarios, or futarchy use cases which might arise if multi-outcome conditions are to be utilized by the mechanism. They also identified security concerns and safety mechanisms of larger D2D interactions in “utilizing conditions relating to (e.g.) the price of different assets, which may open up attack vectors akin to those seen over the past year involving flash loans, negatively impacting the wider ecosystem.” They also identified the need for “insurance primitives” or capping conditional payouts in D2D agreements which may help to mitigate these risks. Proper modelling of the creation and mitigation of honeypots and wider vulnerabilities are an area for interesting future research.
2. Recurring Systems Patterns & Mechanism Design
In this section we will move towards more concrete applied research concepts and implementation details for use in PrimeDAO and beyond. Through the course of this research cycle, our teams have discussed a large number of mechanisms, primitives, and assemblages that could suit various interactions in a DAO2DAO landscape. Our aim in this section is to surface the range of tools we have thus far identified, and particular use-cases where they could be helpful. We will then dive deeper into a select few primitives/assemblages that showed particular promise in further research & potential development for the PrimeDAO ecosystem in particular, as well as D2D interactions more generally.
The non-monopolistic nature of DAOs offers massive leverage to both individuals and organizations in the shared use of contributors, resources, and knowledge generated in this new area of web3. Shared access to open source R&D produced in initiatives like this PrimeDAO collaboration (likewise in the 1Hive community, this Gitcoin Grants research collaboration, and more) provide knock on effects that contribute to the knowledge, education, tooling, and infrastructure of robust cryptoeconomic design patterns that are a necessity for a future underpinned by this technology. For that reason, we have identified joint ventures and the co-funding of research as some of the highest leverage areas for DAO2DAO collaboration:
- Co-funding of Research: Traditional academic and corporate research efforts are often siloed, incentive misaligned, and result in a massive waste of resources in repeated experiments and results that are not openly shared (particularly negative results). The structure of early research initiatives in DAOs have replicated some of these problems, such as KPI or OKR-based progress tracking which are often counterproductive in research paradigms, where exploration offers higher payoff than execution. While it is understandable that different tracking and proposal systems are required for different research & development modalities, so far the tooling we see in the DAO landscape focuses more on the KPI-based approach suited to developers scoping the construction of a pre-specified prototype. This places an undue burden of administrative overhead on the researcher, who has a significantly more challenging task to lay out the expected KPIs & results of an inherently unknowable research process. In section 2.1 below, we will examine early ideas for a “Proposal Inverter” mechanism, which aims to reduce the administrative overhead of a research team collaborating among DAOs.
- Joint Ventures: In the analogue world a joint venture refers to a separate legal entity that is created by two or more institutions where the parties to the venture have some form of shared governance, ownership, shared risks & returns. This could be done for various reasons of entering new geographical markets, lines of business, mutual research, by sharing risks and resources with other existing institutions. However setting up such ventures comes with considerable administrative overheads and legal costs involved to ensure contract security. In the web3 space, with the growing ease of DAO tooling for deployments, joint ventures often end up with a whole new DAO-based organization for proper coordination. While this is acceptable in the right context, it can also create additional administrative overhead for collaborators who would be better suited to tools supporting a joint venture between DAOs, rather than having to create a new organization custom to that purpose. For this reason, the second assemblage we suggest in section 2.2 below for further discussion & possible deployment is the Conditional Tokens Framework.
2.1 “Proposal Inverter” Mechanism
The nascency of DAO tools has developed somewhat siloed, non-standardized proposal systems that incur large transaction costs in information and attention from their contributors. Early DAO experimentation has focused mostly on humans coordinating within (or without?) an organization, but this new tool offers us an opportunity to flip that on its head.
What if we could build tools so that instead of people collaborating to support a DAO, DAOs can collaborate to support their contributors?
A future of increasing DAO2DAO interaction patterns will require more seamless collaboration on joint initiatives, particularly those with shared benefits like open source research or other public goods. It is to this end we consider the “Proposal Inverter” mechanism. The proposal inverter is a funding primitive that enables multiple groups or individuals to collaborate on common proposals, inverting the typical Proposal/DAO relationship to facilitate cross-DAO initiatives, such as co-funding shared research.
The Problem With DAO Tools
DAO proposal processes today can require multiple networks, tokens, protocols, and schedule timelines, which can compound in difficulty when collaborating with multiple DAOs at once. Current DAO tools incur heavy administrative costs, with tasks like KPI setting, proposal writing, payroll & funds management, communications and community interfacing chipping away at time available for productive deep work. Contractor teams have to develop their own HR & administrative processes just to manage the overhead of a handful of DAO collaborations.
To mitigate these issues, we suggest the Proposal Inverter payment mechanism. This mechanism provides “decentralized HR” functionality for ongoing cross-DAO initiatives, with semi-automated payment flows & pre-negotiated contracts. It allows a trusted group of contractors to be funded by multiple DAOs for continuous work, with funds allocated per context-appropriate policy. By re-introducing some of the administrative capacities typically handled by HR departments in firms, we reduce the overhead for contributors from having to manage these tasks for each DAO they collaborate with, freeing up large amounts of productive work capacity.
This tool inverts the current research funding process: rather than the burden of proof be on the proposer to state what will be done and request funds from the community, this kind of arrangement fosters an “agreement by default” nature of the contract, with a pre-negotiated arrangement on behalf of the contractors for a shared allocation policy (e.g. X% of the funds per month), and a pre-negotiated agreement among one or more DAOs to fund the initiative (which could even be facilitated by a Conditional Token agreement — more on this in section 2.2).
In this scenario, the burden of proof lies with the DAO in choosing whether to opt to refrain from funding the proposal when it is no longer delivering value for the community. This inversion of the burden of proof is reminiscent of the difference between consensus (where everyone agrees on a proposal) with consent (where no one objects to the proposal). Accountability for useful outputs will still remain, but the advantage is that contractor teams working on exploratory or open-ended projects on longer timelines do not need to repeat bureaucratic proposal processes for different DAOs on a monthly or bi-monthly basis. Ultimately, it is proposed as a lower overhead funding mechanism for continuous work that delivers shared benefits to multiple groups.
Stacking Primitives into Assemblages
We have identified several stacked primitives within this one assembled mechanism, which we will discuss in further detail below. We believe these primitives and mechanisms could be combined in multiple ways to form varying types of Proposal Inverters for differing use cases.
Level 1: Basic “Flow Wallets”
This first primitive is a wallet that acts like a simple fund splitter, allocating its entire funds all at once among whitelisted contractors according to a static allocation policy. This would allow incoming payments to be split among N contractors per the agreed-upon policy. The term “flow wallet” stuck in our discussions, as this primitive would essentially turn funds in these wallets from stocks into flows, fundamentally changing their nature. Tools of interest that already exhibit some of this functionality include the Disperse App.
Example: Three trusted contractors of the DAO split a one-time $5000 payment according to their previously agreed static allocation policy of 50%, 25%, and 25% of the total funds, earning them $2500, $1250 and $1250 respectively.
Level 2: Rate-limited “Flow Wallets”
This primitive combines the simple fund-splitting Flow Wallet introduced above with a standing reserve and a “leaky integrator” function to include temporal flows into the payments mechanism. You can think of a leaky integrator like a bucket of water with a small hole in the bottom, or a dam that rate-limits the outflow of water. New water (i.e. funds from a DAO) can flow into the top of the bucket/dam, which flows out over time according to the static allocation policy decided by contractors. Tools of interest that already exhibit some of this functionality include Sablier, Superfluid, and the Commune App.
Example: Three trusted contractors of the DAO split 20% of the total funds available per month according to their previously agreed static allocation policy of 50%, 25%, and 25% of the monthly funds. If total funds available were $25,000, the monthly outflow would be $5000 and the allocation per contractor would be $2500, $1250 and $1250 respectively.
Level 3: Rate-limited Dynamic Allocation “Flow Wallets”
This third mechanism integrates the functionality of the previous two primitives, as well as including a dynamic allocation policy through the introduction of a bonding curve, which manages access rights to a portion of the monthly funds allocation. This mechanism enables a dynamic allocation policy among available contractors, as well as revenue sharing agreements and more complex interactions between DAOs, contractors, and even external agents who wish to delegate tokens to signal support for work they see as valuable. In a proposal with productive outputs, these staking agents could potentially also receive a portion of the revenue generated by those outputs. Tools of interest that already exhibit some of this functionality include The Graph’s delegator role, and this new cadCAD model on revenue-sharing bonding curves.
Example: Three trusted contractors of the DAO split 20% of the total funds available per month according to the dynamic allocation policy of the bonding curve. Contractor 1 holds 50% of the bonding curve tokens, contractor 2 holds 25% and contractor 3 holds 25%.
If total funds available were $25,000, the monthly outflow would be $5000 and the allocation per contractor would be $2500, $1250 and $1250 respectively. Note that the bonding curve greatly reduces the negotiation barrier to more entrants, and also encourages discovery and financial support of productive research teams (in this context).
Benefits of the Proposal Inverter concept
Persistent, cross-DAO semi-automated payments infrastructure
This tool offers a payment funnel that lasts longer than one workcycle and incorporates inputs from more than one funding group. It could also help to manage semi-automated payment flows between multiple groups of trusted contractors and DAOs, significantly cutting down on administrative barriers to productive work.
Funding shared research initiatives
As one of many examples, the massive amounts of funding pouring into the private research of AMM & bonding curve functionality would be FAR better spent coordinated into open research initiatives that provide results of this research to multiple open DAOs and organizations, rather than individually wealthy organizations carrying out this research for products aimed at capturing the benefits of this new technology for community empowerment. Promising research directions exist for dynamic and generalized bonding curves using a Token Engineering design methodology, but the costs of coordinating research teams are often beyond a single organization. Using the Proposal Inverter and Conditional Tokens Framework introduced in this digest, we aim to facilitate shared funding and benefits of collective research initiatives.
Supporting Community Management & Care Work
In early discussions with members of the 1Hive community, the Proposal Inverter was identified as useful for other contributor roles that are difficult to specify tasks in advance. Support roles, community management and care work are often “invisible” when they are carried out properly, and the needs for these roles are often changing and difficult to specify in advance, making them similar to research initiatives which don’t fit well in the “checkbox labor” modality more suited to concrete deliverable outputs. If trusted community management workers were to also employ this new tool, perhaps the Proposal Inverter could help to recognize and support these mission-critical community resources by providing them with predictable cash flows to enable contributors to focus on work rather than applying for and managing funds on a recurring basis — especially when contributing to multiple DAOs at once.
Economies of Scale in DAO/Squad Specialization
This tool holds the potential to unlock economies of scale by allowing groups of contractors who operate between multiple DAOs to specialize and then cross-support each other as needed, with governance and resource flows streaming more effortlessly between them. In other words, these collaborations could support not only shared research foundations, but also shared community processes, infrastructure and contributor base.
Funding a collective liquidity pool
Let’s say two different protocols have recently launched new stablecoins and want to incentivize deep liquidity for them. Both are willing to offer rewards for people who provide liquidity to their individual pools. If the developers and community of these two protocols are aligned and mutually beneficial to each other, a path is opened towards a collaboration. They also know that if they can collectively incentivize a metapool that includes their stablecoins and the three other highly liquid stablecoins (as in 3crv pools, for example), they can achieve a higher liquidity. Moreover, they can do that with a better efficiency in terms of capital allocation because instead of spending their treasury for individual pools, they can create a shared pool of funding for incentivizing their common pool. With the Inverter, these two protocols can pool their tokens together and decide on the distribution policy for incentivizing their collective Curve metapool. Then, the liquidity providers can stake their LP tokens on this shared pool to claim rewards for both of the two tokens.
Early Days of Exploration
This tooling is in its early stages of research and modeling, and there is work needed to flesh the above concepts out further. Additional functionality such as time locks (i.e. vesting periods) and imposed frictions (i.e. exit tariffs) could be introduced to prevent exploitative pump & dump behavior, as suggested in design patterns proposed by the Commons Stack. Additional features, like giving DAOs signaling power to rank priorities in a research group’s backlog could also be integrated using tools like TokenLog, which has implemented quadratic token voting to prioritize Github task backlogs.
The continued use of modeling and simulation tools to inform DAO decision-making is a trend likely to increase, meaning as an industry we need to increase our focus on research, education, and tooling to keep up with the coming demand. We are already seeing DAOs make data-driven policy choices — notably, 1Hive recently modeled and validated their dynamic $HNY issuance policy in cadCAD, not only improving their native token ecosystem, but also laying the foundation for more rapid exploration of simulated token supply dynamics in other DAO ecosystems.
Our aim with the Proposal Inverter is to make it easier to co-fund and collaborate on important research initiatives like these, while cutting down on administrative overhead. We should continue to build and iterate tools that make it easier to collectively fund public goods. Within our own DAO ecosystems, public goods like research, education and community building are particularly important because we can use them to further leverage the effectiveness of DAOs as new institutional tools for social benefit.
2.2 Conditional Tokens Framework
Another key primitive that has been explored over this cycle is the Conditional Tokens Framework (CTF) as an enabler of DAO2DAO relations. We have successfully created a ‘Treasury’ smart contract prototype via which two DAOs can utilize the CTF to trustlessly co-fund a Joint Venture (represented by a Gnosis Safe multisig wallet), and plan to continue developing this prototype to create a piece of infrastructure for any DAO or multisig to utilize in the future.
Overview of the Conditional Tokens Framework
Originally developed by Gnosis to enable users of prediction markets to “maximize fungibility in deeper combinatorial markets”, Conditional Tokens allow for the trading of ERC20 assets on the occurrence of future events, acting essentially as tokenized escrow outcomes. The Conditional Tokens Framework can be used to transfer tokens on the outcome of:
- ‘Shallow’ conditions for questions with either binary or scalar outcomes, e.g. ‘will the price of ETH be above $2,000 on 12th March 2021 at midnight CET?’, or ‘will the price of ETH be higher or lower than $2000 on 12th March 2021 at midnight CET?’
- ‘Deeper’ combinatorial conditions reliant on the outcome of several conditions, e.g. ‘will the price of ETH be above $2,000 on 12th March 2021 at midnight CET && will the price of BTC be above $55,000 on 12th March 2021 at midnight CET?’
These possibilities are fundamental for enabling flexible DAO2DAO collaborations; by creating conditions based on the potential future actions of two DAOs, a mechanism can be created whereby DAOs can trustlessly create collateral-backed conditions, the outcome of which will decide whether or not this collateral can be redeemed by themselves or other parties.
Facilitating DAO Joint Ventures with the Conditional Tokens Framework
As outlined previously, numerous different formations and collaboration possibilities are opened up by the use of Conditional Tokens. Our first prototype for a simple DAO2DAO collaboration involves utilizing the escrow functionality of Conditional Tokens to facilitate the initial funding of a co-funded joint venture between two DAOs. For the purposes of this PoC, the ‘joint venture’ is represented by a Gnosis Safe, with members of each DAO as owners.
As previously detailed, and outlined in the diagram above, the steps to achieve a co-funded joint venture can be split into two distinct stages: negotiation and agreement. During the negotiation stage (an under discussed aspect of the DAO2DAO process, as highlighted by the focus of conversation here), a proposal for a joint venture is drafted by (most likely) members of each DAO, containing both a high-level overview of the collaboration and key information such as the amount that each DAO will commit to the joint venture, and by what date. This proposal is then parameterized via a web interface, and uploaded to IPFS. A checksum is also created for the information for verification by any members of the DAOs, should they choose to do so.
The agreement stage involves both DAOs voting on the proposal. If these votes pass, then both DAOs create an initial condition (a question regarding the funding of the joint venture) and supply collateral to back the positions (possible answers to this binary question in the form of ‘yes’ and ‘no’) via their treasury, which receives Conditional Tokens in return. They then subsequently create deeper conditions by ‘splitting’ one of their positions (e.g. ‘Will DAO 1 fund the JV? Yes’) by the other DAO’s condition, creating combinatorial positions (e.g. ‘Will DAO1 fund the JV? Yes’ & ‘Will DAO2 fund the JV? Yes’).
The key characteristic of the Conditional Tokens Framework (CTF) that is being utilized in this stage is the possibility of tokenizing all of the potential outcomes of a particular question, with the tokens representing the outcome that was reported to have occurred being redeemable for collateral later on; by creating deep binary conditions regarding whether two DAOs have co-funded a specified joint venture wallet, we are able to create a mechanism via which two DAOs can recover their side of the co-funding in case the other DAO does not follow through with its commitment. This is possible by transferring the Conditional Tokens representing the outcome of both DAOs funding the joint venture (in this instance, the ‘yes’ positions for each condition) to the allocated joint venture wallet, and keeping the other tokens (the ‘no’ positions). In the event that both DAOs do in fact co-fund the wallet, the tokens held by it can be redeemed for the underlying collateral used by both DAOs when creating the initial conditions. If not, these tokens are worthless, and the tokens held by each DAO representing all other outcomes can be redeemed for the underlying collateral.
Although it would be fair to point out that much of this could be achieved in a more simple fashion using traditional escrow smart contracts instead of CTF, Gnosis’ framework has several distinct advantages:
- Conditions (questions to be answered in the future) do not have to be decided or created simultaneously, allowing for the possibility of this mechanism being utilized in such a way that additional sub-conditions are added and finalized within the time window of their root condition being unanswered. Ultimately, this flexibility of timing and condition creation enables a more fluid way of structuring and engaging with negotiations between parties than traditional escrow smart contracts.
- CTF means that a new, bespoke escrow contract does not have to be written and deployed prior to a new collaboration, as parties merely have to interact with an already deployed token contract. Alongside lowering the coordination overhead, this method is far more gas efficient, saving money for users. Furthermore, this method means no single-use contracts are left on the chain, lessening unnecessary chain bloat.
- By tokenizing the potential outcomes of conditions, DAOs could transfer these tokens to other parties as: the scenario mapped above could be altered to include one DAO using some of its conditional tokens as a form of ‘prepayment’ to a subcontractor or team for doing some work on setting up the joint venture wallet and any additional preparatory work, which could then be redeemed at a later date.
Downsides to the Conditional Tokens Framework
There are a few disadvantages to CTF however, most notably the complexity of the codebase itself, as well as the lack of composability of the ERC1155 token standard, meaning that contract addresses that do not already implement ‘onERC1155Received’ and ‘onERC1155BatchReceived’ functions are not able to receive Conditional Tokens. This is an issue for the majority of DAOs, which are also unable to update their core treasury functionality (e.g. DAOStack’s ‘Avatar’ contract) to accommodate this requirement. However, the Treasury contract prototype was developed in order to sidestep this issue while retaining the advantages of the Conditional Tokens Framework by holding the Conditional Tokens for the DAO and allowing it to interact with the token contract.
Next Steps for the CTF
There are numerous avenues for future development, many of which can occur in parallel. Future development of the treasury involves repositioning the contract developed in our POC from being a module that each DAO independently deploys to being a single-instance piece of ‘common good’ infrastructure (much like Balancer’s V2 architecture, in which there is one monolithic vault with which AMM logic interacts, rather than multiple vaults each with their own logic). Multiple DAOs and smaller organizations (represented by multisignature wallets) will then be able to collaborate via the treasury without needing to deploy their own treasury contracts, significantly reducing coordination overhead.
The main role of this treasury would thus be to mitigate the issue raised by the CTF being an ERC1155 token, acting as an interface between the framework and organizations, as well as holding the conditional tokens for these organizations. This also raises the possibility of creating an avenue of funding for the DAO managing the treasury via a fee-based model similar to liquidity pools.
With regards to other aspects of DAO2DAO collaboration, work is being done on creating a web interface via which proposals can be constructed according to a shared standard, in order to bring conceptual clarity to the terms agreed upon by collaborating parties. This interface would parameterize key aspects of the agreement and provide an easy to share, formatted proposal to be shared, as well as validation checks for the information contained within the proposal. The need to “[structure] conditions in a way which is far more programmatic than natural language”, as pointed out by Graeme Barnes of Gnosis, is however a far larger research field ripe for future development, and dovetails with efforts to create formalized, human readable language for agreements.
Overall, the Conditional Tokens Framework is a powerful primitive for enabling collaborations between organizations represented by smart contracts, whether DAOs or smaller groups / squads with more ephemeral presence representing themselves on-chain via multi-sig wallets such as the Gnosis Safe. This prototyping cycle has shown that Conditional Tokens Framework can be utilized by DAOs that are created in accordance with current design patterns that make interfacing with the ERC1155 standard difficult. Subsequent work will continue on turning this prototype into a piece of common good infrastructure for the wider DAO ecosystem, in parallel with developing a web interface for standardized on-chain DAO2DAO and squad2squad collaboration agreements.
Conclusion
We started this digest with a recap of our previous research cycle, followed by a deeper look into a few recurring patterns and implementation details for the more promising primitives, mechanisms and assemblages identified to empower a future of DAO2DAO interactions. There is much more to be done in the further explorations of these concepts and tools, and we are interested in collaborations both in modeling and further development of these new D2D collaboration mechanisms.
We are eager to hear feedback from the PrimeDAO community and other groups as to the viability of the ideas discussed in this digest. We have plans to further develop these ideas and research, with the ultimate intention of building tools that are useful in the PrimeDAO ecosystem and beyond. We aim to ensure the tools produced are generalized to as wide a range of circumstances as possible. Please reach out if you’re interested to explore these concepts further with us!
PrimeDAO: 🕸 Site | 📄 Docs | 💬 Discord | 💭 Telegram | 🐤 Twitter | 📍 Forum | 📨 Newsletter
Curve Labs: https://twitter.com/curvelabs
Token Kitchen: https://twitter.com/tokenkitchen
Our previous research digest can be found here: Conceptual Models for DAO2DAO Relations
About BlockScience
BlockScience® is a complex systems engineering, R&D, and analytics firm. Our goal is to combine academic-grade research with advanced mathematical and computational engineering to design safe and resilient socio-technical systems. We provide engineering, design, and analytics services to a wide range of clients, including for-profit, non-profit, academic, and government organizations, and contribute to open-source research and software development.
