Much has been said about the idea of 'cryptocurrency Lego', especially in terms of decentralized financial systems, where cryptocurrencies are programmable currencies and programmable components are combinable when done well. The software industry has a rich history of composability approaches (and the code reuse associated with them). So when you start to think of money and the capabilities around it (lending, loaning, etc.) as programmable components, the next natural step is to look at how these various components associated with cryptocurrency can be put together in new and unexpected ways.

With this in mind, what is a DAO (Decentralized Autonomous Organization)? In my experience so far, DAOs are online discussion groups that have, at best, a shared pool of funds and a governance system to help determine how to use those pools. But the real promise of DAOs is that they can be programmable organizations in the same way that cryptocurrencies are programmable currencies.

The concept of programmable organizations brings with it the ability to create composable, reusable organizational structures and capabilities.

While DAOs are ostensibly made up of people (or other DAOs, bots, or ......), at their core, DAOs are different from any other population in that they are managed through code. In programmer-speak, we interact with DAOs through APIs or application programming interfaces. In decentralized blockchain-based systems, these APIs take the form of functions that can be called publicly on smart contracts. While the DAO is programmed by humans (and sometimes other programs), the real functionality of the DAO is its smart contracts. Everything else is, as the Orca protocol team likes to call it, SocialWare (a system based on human trust run manually by humans).

DAOs are essentially programmable components that perform functions through APIs.

What are these capabilities? What is an API?

In terms of programmable systems, right now, most DAOs consist of two things.

Membership lists Shared wallets / vaults Discussions happen in Discord, meetups happen at conferences, groups start writing code, designing things, tweeting, etc., but the essence of most DAOs - to distinguish them as DAOs from online clubs - boils down to these Two functional areas. Today's DAOs implement code to manage memberships and spend money.

So what does it mean that the components that can manage members and wallets are composable?

Publicly accessible functionality for membership management (joining, leaving, etc.) and multi-party wallets (voting, executing transactions, transferring funds). Standardized interfaces for these functions (names of records, inputs and expected outputs) so that multiple implementations can be interchanged. A standardized set of invocation conventions, so that each set of functions or interfaces does not require a completely different interaction. This has the advantage of allowing different types of modules to be substituted for each other or managed in the same way. It also means that calls can be linked together in a way that the interface creator did not plan. A historical example of a calling convention like this is that tools for UNIX-based systems almost always read text from their input and output text, thus allowing them to be linked together with pipes. The Zodiac team has done some excellent work in creating proposed standards for composable DAO behaviors, similar to the conceptual approach of aspect-oriented programming.

While we are now discussing composability in the context of behavior, composability also applies to data. For example, the Orca protocol implements a DAO consisting of many DAOs (called Pods). each DAO can have zero or more DAOs as parents in a graph of theoretically infinite size and complexity. At the top level, a DAO consists of all its members recursively, whether they are humans, DAOs/Pods, or other identities associated with bots, etc.

Now that we have a simplified view of what most DAOs are and what composability means for them, you may think it doesn't sound exciting that the world of human collaboration is far richer than simply the ability to form teams, raise and spend money. The truth is, these People Lego's we've built so far aren't very useful. What else do they do but exist? Not much, and while the humans in DAOs may be busy and very productive, creating art, music, companies, online materials, or trying to save the planet, DAOs themselves are superficial and almost featureless.

The next step in DAO composability is to extend the functionality of the DAO itself, and to extend the surface area of the DAO API accordingly.

My approach is to start by implementing a concrete instance, iterate over that instance, and then move to another instance. After some concrete implementation, the pattern emerges. Let's explore one possible example: customer service.

Imagine that a new DAO, SupportDAO, is created to service customer support tickets for a Web3 company, which might be a for-profit organization whose members are customer support experts and have built a discipline around handling online customer support at scale. metrics for customer support, almost all of which are easy to measure (see examples below).

SupportDAO has members and a shared vault, so it can implement standard interfaces for these high-level functions in a composable generic DAO ecosystem, but what else can SupportDAO do? At the core of its API is the ability to provide customer support tickets from a ticketing system to it to resolve those tickets and then make payments based on the successful resolution of those tickets.

How does a DAO (or company) pay another DAO for processing customer support tickets without trust? Payments are made based on an agreed set of KPIs. For example, the payment might be for the following functions.

Number of tickets processed Time to resolve the issue Time to first contact Percentage of resolved work orders versus unresolved closed work orders Average age of queued work orders Customer NPS etc. The fact that these are measurable and can be integrated either on-chain (probably not) or via a prophecy machine means that SupportDAO can run as an autonomous, trustless component rather than being manually orchestrated by humans for payment, which is an admittedly naive and superficial view of the design, but I find it exciting.

A DAO-enabled API like this would be composable, and any organization building an application or service could evaluate plugging it in and having new customer support capabilities, rather than building its own customer support organization, and more importantly, if the API is standardized (or even de facto), multiple supporting DAOs could compete in real time to provide better, faster service to each organization while (or even anonymously) sitting behind the API.

Customer support is just one of the areas that can be achieved through smart contracts and standardized APIs. As we explore the future of decentralized organizations and collaboration models that look more like federations of small teams than monoliths, more interfaces and automated collaboration mechanisms will emerge.

Much has been said about the idea of 'cryptocurrency Lego', especially in terms of decentralized financial systems, where cryptocurrencies are programmable currencies and programmable components are combinable when done well. The software industry has a rich history of composability approaches (and the code reuse associated with them). So when you start to think of money and the capabilities around it (lending, loaning, etc.) as programmable components, the next natural step is to look at how these various components associated with cryptocurrency can be put together in new and unexpected ways.

With this in mind, what is a DAO (Decentralized Autonomous Organization)? In my experience so far, DAOs are online discussion groups that have, at best, a shared pool of funds and a governance system to help determine how to use those pools. But the real promise of DAOs is that they can be programmable organizations in the same way that cryptocurrencies are programmable currencies.

The concept of programmable organizations brings with it the ability to create composable, reusable organizational structures and capabilities.

While DAOs are ostensibly made up of people (or other DAOs, bots, or ......), at their core, DAOs are different from any other population in that they are managed through code. In programmer-speak, we interact with DAOs through APIs or application programming interfaces. In decentralized blockchain-based systems, these APIs take the form of functions that can be called publicly on smart contracts. While the DAO is programmed by humans (and sometimes other programs), the real functionality of the DAO is its smart contracts. Everything else is, as the Orca protocol team likes to call it, SocialWare (a system based on human trust run manually by humans).

DAOs are essentially programmable components that perform functions through APIs.

What are these capabilities? What is an API?

In terms of programmable systems, right now, most DAOs consist of two things.

Membership lists Shared wallets / vaults Discussions happen in Discord, meetups happen at conferences, groups start writing code, designing things, tweeting, etc., but the essence of most DAOs - to distinguish them as DAOs from online clubs - boils down to these Two functional areas. Today's DAOs implement code to manage memberships and spend money.

So what does it mean that the components that can manage members and wallets are composable?

Publicly accessible functionality for membership management (joining, leaving, etc.) and multi-party wallets (voting, executing transactions, transferring funds). Standardized interfaces for these functions (names of records, inputs and expected outputs) so that multiple implementations can be interchanged. A standardized set of invocation conventions, so that each set of functions or interfaces does not require a completely different interaction. This has the advantage of allowing different types of modules to be substituted for each other or managed in the same way. It also means that calls can be linked together in a way that the interface creator did not plan. A historical example of a calling convention like this is that tools for UNIX-based systems almost always read text from their input and output text, thus allowing them to be linked together with pipes. The Zodiac team has done some excellent work in creating proposed standards for composable DAO behaviors, similar to the conceptual approach of aspect-oriented programming.

While we are now discussing composability in the context of behavior, composability also applies to data. For example, the Orca protocol implements a DAO consisting of many DAOs (called Pods). each DAO can have zero or more DAOs as parents in a graph of theoretically infinite size and complexity. At the top level, a DAO consists of all its members recursively, whether they are humans, DAOs/Pods, or other identities associated with bots, etc.

Now that we have a simplified view of what most DAOs are and what composability means for them, you may think it doesn't sound exciting that the world of human collaboration is far richer than simply the ability to form teams, raise and spend money. The truth is, these People Lego's we've built so far aren't very useful. What else do they do but exist? Not much, and while the humans in DAOs may be busy and very productive, creating art, music, companies, online materials, or trying to save the planet, DAOs themselves are superficial and almost featureless.

The next step in DAO composability is to extend the functionality of the DAO itself, and to extend the surface area of the DAO API accordingly.

My approach is to start by implementing a concrete instance, iterate over that instance, and then move to another instance. After some concrete implementation, the pattern emerges. Let's explore one possible example: customer service.

Imagine that a new DAO, SupportDAO, is created to service customer support tickets for a Web3 company, which might be a for-profit organization whose members are customer support experts and have built a discipline around handling online customer support at scale. metrics for customer support, almost all of which are easy to measure (see examples below).

SupportDAO has members and a shared vault, so it can implement standard interfaces for these high-level functions in a composable generic DAO ecosystem, but what else can SupportDAO do? At the core of its API is the ability to provide customer support tickets from a ticketing system to it to resolve those tickets and then make payments based on the successful resolution of those tickets.

How does a DAO (or company) pay another DAO for processing customer support tickets without trust? Payments are made based on an agreed set of KPIs. For example, the payment might be for the following functions.

Number of tickets processed Time to resolve the issue Time to first contact Percentage of resolved work orders versus unresolved closed work orders Average age of queued work orders Customer NPS etc. The fact that these are measurable and can be integrated either on-chain (probably not) or via a prophecy machine means that SupportDAO can run as an autonomous, trustless component rather than being manually orchestrated by humans for payment, which is an admittedly naive and superficial view of the design, but I find it exciting.

A DAO-enabled API like this would be composable, and any organization building an application or service could evaluate plugging it in and having new customer support capabilities, rather than building its own customer support organization, and more importantly, if the API is standardized (or even de facto), multiple supporting DAOs could compete in real time to provide better, faster service to each organization while (or even anonymously) sitting behind the API.

Customer support is just one of the areas that can be achieved through smart contracts and standardized APIs. As we explore the future of decentralized organizations and collaboration models that look more like federations of small teams than monoliths, more interfaces and automated collaboration mechanisms will emerge.