In the previous post in this series, we laid out an argument that for DAOs to realize their potential as composable building blocks, they need to evolve to be truly programmable entities whose contracts implement the core functionality of each respective DAO. We described an example, SupportDAO, whose mission is to provide customer service for Web3 applications and protocols, and we discussed a possible programmable interface for SupportDAO which would allow the DAO to accept customer support cases to be processed, process the cases, and be paid based on successful resolution of those requests.

Now let’s discuss how to enhance the composability of such a DAO and lay the groundwork for an emerging set of patterns for composability in DAO protocols.

SupportDAO’s interactive capabilities can be generalized. While SupportDAO is 100% concerned with accepting and resolving support requests, its behavior and interface is a specific implementation of a general idea. SupportDAO does the following:

1. reads work requests from a queue
2. processes the requests (by resolving support issues)
3. provides a decentralized, impartial mechanism for evaluating the work (an Impact Evaluator)
4. gets paid for that work on a per-request basis

While we expect the actual work (step 2, processing support requests) to be performed by humans outside of the scope of the smart contract itself (by helping other humans resolve problems with the product or service in question), steps 1, 3, and 4 are both possible to automate in a smart contract and form a pattern applicable to any process involving a list of tasks to be completed, some 3rd party organization agreeing to complete the tasks in exchange for compensation, and a decentralized, impartial evaluator for each task which can be used to determine the quality and value of the work done on a per-task basis.

While the interface we described when we introduced SupportDAO is simple enough to easily understand and implement, creating a generalized interface would mean any code that knows how to talk to SupportDAO could also interact with other DAOs whose job is to process task lists in exchange for compensation.

The following diagram (source) illustrates the participants and data flow of this generalized module of task processing, evaluation and payment.

This is of course a high level, abstract representation of the interactions such a DAO would support. The real implementation would require a mix of fairly complex smart contracts implementing mechanisms designed to reward positive behavior in the system among all participants covering issues such as requestors committing/locking tasks to the system to be worked on so they don’t get handled outside the system, some sort of vetted oracle and Impact Evaluator design to properly reward the service DAOs, etc.

When the right APIs have evolved through iterative design and testing, contract interfaces would be created for this style of interaction as has been the case with many of the inventions in the Ethereum ecosystem, including ERC721, ERC20, ERC1155, EIP5005, and many more.

While we’ve explored ideas for programmability, interoperability and composability of a specific style of DAO (incentivized task processor), there are many other domains to explore, design, and document. Social groups, product producing organizations, infrastructure providers, and others all represent rich and varied types of interaction which could be modeled and generalized into composable interfaces.