Programmable organization and DAO composability

Much has been said about the idea of ​​”currency Lego”, especially when it comes to decentralized financial systems, where cryptocurrencies are programmable money, and programmable components, done well, are composable. The software industry has a rich history of composability approaches (and code reuse associated with it). So when you start thinking of money and the capabilities around it (lending, lending, etc.) as programmable components, the natural next step is to see how these various components related to money can be used in new and meaningful ways Put together in unexpected ways.

With this in mind, what is a DAO (Decentralized Autonomous Organization)? From my current experience, DAOs are online discussion groups with at best a shared treasury and a governance system to help determine how those treasuries are used. But the real promise of DAOs is that they can be programmable organizations, just as cryptocurrencies are programmable money.

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

Although a DAO is ostensibly made up of people (or other DAOs, robots, or…), at its core, a DAO is different from any other group of people in that it is governed by code. In programmer parlance, we interact with DAOs through APIs or application programming interfaces. In a decentralized blockchain-based system, these APIs take the form of publicly callable functions on smart contracts. While a DAO is orchestrated by humans (and sometimes other programs), the real function of a DAO is its smart contracts. Everything else, as the Orca Protocol team likes to call it, SocialWare (systems run manually by humans based on human trust).

DAOs are essentially programmable components that perform functions through APIs.

What are these abilities? What is an API?

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

  • Member list
  • Shared wallet/vault

Discussions take place in Discord, meetups take place in conferences, groups start coding, designing things, tweeting, etc., but the essence of most DAOs – what separates them as DAOs from online clubs – boils down to these two a functional area. Today’s DAOs implement code to manage membership and spend money.

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

  • Public access to member management (joining, leaving, etc.) and multi-party wallets (voting, executing transactions, transferring funds)
  • Standardized interfaces for these functions (documented names, inputs, and expected outputs) so that multiple implementations are interchangeable.
  • A standardized set of calling conventions so that each set of functions or interfaces does not need to interact in a completely different way. This has the advantage of allowing different types of modules to replace each other or be managed in the same way. It also means that calls can be chained together in ways that the interface creator didn’t plan on. 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, allowing them to be chained together with pipes.

The Zodiac team has done some excellent work creating a proposed standard for composable DAO behavior, similar to the conceptual approach of aspect-oriented programming.

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

Now that we have a simplified understanding of what most DAOs are and what composable means to them, you might think that doesn’t sound exciting, the world of human collaboration is much more than simply building teams, raising and spending The power of money is much richer. In fact, these People Legos we’ve built so far aren’t very useful. What do they do besides exist? Not much, and while the humans in a DAO may be busy and very productive, creating art, music, companies, online material, or trying to save the planet, the DAO itself is superficial and features little in the way.

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

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

Imagine a new DAO, SupportDAO, created to service customer support tickets for a web3 company, possibly a for-profit organization whose members are customer support experts and built around handling online customer support at scale Discipline, I chose this example because the industry has developed a semi-standard set of measurable KPIs for customer support, almost all of which are easy to measure (see examples below).

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

How can a DAO (or company) trust another DAO to pay another DAO to process a customer support ticket? Payments are made against an agreed set of KPIs. For example, payments might be the following functions:

  • Number of tickets processed
  • problem solving time
  • time of first contact
  • Percentage of resolved tickets to open closed tickets
  • Average age of queued tickets
  • Client NPS
  • and many more

These are measurable and can be integrated on-chain (probably not) or through oracles, meaning that SupportDAO can operate as an autonomous, trustless component rather than being manually coordinated by humans to make payments, which is an admittedly naive and superficial take on 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 have new customer support capabilities instead of building their own customer support organization, and more importantly, if The API is standardized (even de facto), and multiple backing DAOs can compete in real-time to provide better and faster service to each organization, while sitting (even anonymously) 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 organization and collaboration models that look more like coalitions of small teams than monoliths, more interfaces and automated collaboration mechanisms will emerge.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-08-04 10:27
Next 2022-08-04 10:28

Related articles