Programmable Organizations and DAO Composability

Much has been said about the idea of “money legos”, specifically with respect to decentralized finance systems. Crypto currency is programmable money, and programmable components done well are composable. The software industry has a rich history of approaches to composability (and, with it, code reuse). So when you start to think of money and the capabilities around it (borrowing, lending, etc.) as programmable components, a natural following step is to see how these various money-related components can be put together in new and unexpected ways.

In this light, what are DAOs (Decentralized Autonomous Organizations)? In my experience so far, DAOs are online discussion groups with, at best, a shared treasury and a governance system to help determine how to spend that treasury. But the real promise of DAOs is that they can become programmable organizations in the same way crypto currencies are programmable money.

And with the concept of programmable organizations, comes the ability to create composable, reusable organizational structures and capabilities.

Though a DAO is ostensibly made up of people (or other DAOs, or bots, or…), at its core, what sets a DAO apart from any other grouping of people is that it is managed through code. In programmer-speak, we interact with a DAO via an API, or Application Programming Interface. In decentralized blockchain-based systems, these APIs take the form of publicly callable functions on smart contracts. While DAOs are orchestrated by humans (and sometimes other programs), the real functionality of a DAO is its smart contract. Everything else is, as the Orca Protocol team likes to call it, SocialWare (systems run by humans manually based on human trust).

DAOs are essentially programmable components that perform capabilities via an API.

What are those capabilities? What are the APIs?

In terms of programmable systems, for now, most DAOs consist of two things:

  • Membership lists
  • A shared wallet/treasury

Discussions take place in Discord, meetups happen at conferences, side groups go off and write code, design things, tweet, etc. but the essence of most DAOs—what sets them apart as a DAO vs an online club—boils down to just these two areas of functionality. The DAOs of today implement code to manage memberships and to spend money.

So, what does it mean for a component that can manage members and a wallet to be composable?

  • Publicly accessible functions for both member management (joining, leaving, etc.) and multi-party wallets (voting, executing transactions, transferring funds)
  • A standardized interface (documented names, inputs, and expected outputs) to those functions such that multiple implementations are interchangeable.
  • A standardized set of calling conventions so each set of capabilities or interface doesn’t require a completely different style of interaction. This has the benefit of allowing different types of modules to stand in for each other or be managed in the same way. It also means calls can be chained together in ways the creators of the interfaces didn’t plan. A historical example of a calling convention like this is how UNIX based systems’ tools almost all read text from their input and output text, allowing them to be chained together with pipes.

The Zodiac team has done some great work creating proposed standards for composable DAO behaviors, similar in approach to concepts from Aspect Oriented Programming.

Though we’re talking about composability now in terms of behavior, composability applies to data as well. Orca Protocol, for example, implements DAOs composed 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 is composed recursively of all of its members, be they humans, DAOs/Pods, or other identities tied to bots, etc.

Now that we have a simplified view of what most DAOs are and what it means for them to be composable, you might be thinking that this doesn’t sound very exciting. The world of human collaboration is far richer than the simple ability to form groups and raise and spend money. Indeed, these People Legos we’ve built so far aren’t very useful. What do they do other than exist? Not much. Though the humans in the DAO might be busy and extremely productive, creating art, music, companies, online materials, or trying to save the planet, the DAOs themselves are shallow and almost featureless.

The next step in DAO composability is to expand the capabilities of the DAOs themselves and accordingly to expand the surface area of the DAOs’ APIs.

My approach to this would be to start with implementing a specific use case, iterating on that use case, and then moving on to another use case. After a few specific implementations, patterns will emerge. Let’s explore one possible use case: customer service.

Imagine a new DAO, SupportDAO, is created to service customer support tickets for web3 companies. This might be a for-profit organization whose members are customer support experts and have built a discipline around handling online customer support at scale. I choose this as an example because the industry has settled on a set of semi-standard measurable KPIs for customer support, almost all of which are easy to measure (see below for examples).

The SupportDAO has members and a shared treasury. In an ecosystem of composable generic DAOs, it could therefore implement standard interfaces for those high level functions. But what else does SupportDAO do? The core of its API would be functionality to feed it customer support tickets from a ticketing system to resolve and then to pay based on successful resolution of those tickets.

How does a DAO (or company) trustlessly pay another DAO for handling customer support tickets? By paying based on an agreed-upon set of KPIs. For example, payment could be a function of:

  • Number of tickets processed
  • Time to resolution
  • Time to first contact
  • Percentage of tickets resolved vs closed without resolution
  • Average ticket age in queue
  • Customer NPS
  • etc.

These are all measurable and possible to integrate either on-chain (probably not) or via oracles, meaning the SupportDAO could be run as an autonomous, trustless component vs manually reconciled by humans for payment. This is an admittedly naive superficial take at a design, but I find it exciting.

An API for a support DAO like this would be composable. Any organization building an application or service could evaluate plugging it in and having a new customer support function as opposed to building out its own customer support organization. What’s more, if the API were standardized (even de facto), multiple support DAOs could compete in real time to provide better, faster service to each organization all while sitting (even pseudonymously) behind an API.

Customer support is just one domain that could be implemented via smart contracts and standardized APIs. As we explore the future of decentralized organizations and collaborative models that look more like federations of small teams rather than monoliths, more interfaces and automated mechanisms for collaboration will emerge.

Subscribe to BlueYard
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.