An Introduction to Decentralized Autonomous Corporations (DACs)
In this discussion we will explain what exactly a DAC is, as well as diving into an in-depth example of how a simple AC might function in a real world scenario. The goal is to provide the reader with a functional understanding of DACs and an introduction to their potential applications and impact.
Decentralized Autonomous corporations (DACs), represent one of the most interesting and potentially disruptive applications of blockchain technology. DACs contain the power to automate and organize complex processes, systems and organizations (e.g. corporations) that previously would have been impossible to move outside of a human control structure. Additionally, a DAC allows for some specific and valuable benefits when compared with a human controlled model in a number of categories (security, trust, protocol, resilience, consistency) that’ll we will explore in more detail.
The topic of DACs is particularly interesting right now because while the theory of DACs has been around for some time, it has not been until the advent and adoption of Bitcoin–and more recently, Ethereum–and other blockchain technologies that DACs have started to move from the realm of theory into practice.
What exactly is a DAC?
At their simplest level DACs allow for much the same concept as the blockchain itself – that is the ability for individuals to collaborate, trade or otherwise transfer information via a system that provides a set of rules that are known and inflexible. While the blockchain itself is a way to store information (what addresses hold which units of currency), DACs allow for a more complex set of rules to be implemented amongst a group, especially around the control of resources (financial resources).
At their simplest level DACs are made up of two attributes: 1. Internal capital, and 2. A set of rules or governing protocol that controls its actions and the management of the internal capital.
One of the central attributes of Bitcoin and cryptocurrencies/blockchains in general is the level of trustless control given to each member of the network. Each member, via their private key, is the only one who has access to their funds, and is the only one who can move them out of their account. This can be contrasted with real-world systems where no matter how secure resources are held there is no way to completely eliminate the threat of theft, embezzlement, fraud or seizure.
The appeal of DACs is largely the same, except now we have a system of governance on top of the funds that can take a variety of inputs but still function in the same trustless way. The important difference between a DAC and just an algorithm or computer program as it exists today is the distributed nature of the system, which allows it to function as an independent entity and sole controller of a set of resources.
With the advent of Bitcoin and the advancement of blockchain technology it has now become possible to both create a ruleset that exists outside the control of any individual or physical location, and that has sole control over capital.
The Community Council DAC
To demonstrate what a DAC would look like in practice, let’s start with a simple but potentially practical example: imagine a simple community council (or perhaps homeowners association). This council is made up of the residents of the community who each pay a small fee each year for maintenance of their community and an elected board of community members who decide on where and how this money is to be spent.
Since at the most basic level, the DAC is simply a ruleset that owns assets, we can define our own DAC though the creation of a simple ruleset by which it will facilitate the management of our community.
In this case, the rules would be as follows:
Attributes: A unique private ID
Possible Actions: Pay yearly dues, vote for community board members, vote for proposals
Upon entry to the community and payment of their first yearly fee a community member would be assigned an ID. This private ID allows each community member to do two things: vote on elections (or proposals if they are a member of the board), and pay their yearly community dues. In practice this ID would be a private key that members would use to cryptographically sign transactions, however for the sake of this example it’s accurate enough to say that this ID works like a social security number and allows them to prove their identity to the community DAC for either of these actions.
Possible Actions: Submit a proposal, vote on a proposal
In our community DAC we have the concept of a board member. This is a normal member who has been elected (receiving a sufficient number of votes during the election period each year). Once elected this member receives two additional abilities:
- They can use their ID to submit a proposal (described in more detail below)
- When a proposal is submitted by any board member they can use their ID to vote on it.
Attributes: Description, Cost, Payee(s)
Proposals are the third piece of the puzzle that the community DAC needs to understand and track. Proposal are made of up three parts: the description, which could be any combination of text, videos and images describing the proposal (for example an argument to repave the main street of the community paved using a specific vendor). The community DAC doesn’t actually care about the contents of this description, as it will be reviewed by human community members and voted upon. However the DAC must securely store the proposal so that it cannot be changed, and can be accessed and viewed by any members of the community.
Next each proposal has a cost and a payee or series of payees. These are the actual actionable attributes of the proposal. If a proposal receives enough votes to pass then the DAC will transfer funds in the amount of the cost to the payees (or more accurately their payment addresses).
These three concepts: community members, board members, and proposals represent all of the objects that the community DAC needs to track. Next onto the DAC itself and what its set of rules and responsibilities looks like.
- Account of funds
- Record of members and their payment statuses (paid/unpaid)
- Record of board members
- Record of proposals and vote status (successful/unsuccessful)
- Receive payments from members
- Assign IDs to new members
- Track payment/non-payment status of each member
- Survey members once yearly for votes to elect board members
- Assign (or unassign) board membership once yearly
- Track proposal by board members
- Survey board members for votes on a proposal
- Release funds in the case of a successful proposal vote
The community DAC has substantially more than the above to track and manage, but let’s play out an example year to show how it would handle each of these responsibilities.
- For each member of the community, the DAC could check to see if a payment has been received from their ID.
- Check to see if a vote has been submitted for proposals and board member elections. If payment has not been received, notify the ID that the vote is invalid until payment is received.
- Count all votes at the end of a voting period. Reallocate board permissions based on elections and initiate proposals based on voting.
To put this in plain language: The DAC monitors its accounts or payments from members, and as long as it receives a payment from a member once a year it maintains a “paid” status for that ID. As long as a member of the community has a “paid” status they can vote in the yearly elections. Once a year the DAC allows for voting for a specific period of time. During this window any member of the community in good standing can submit a vote for a board member. At the end of this period the DAC assigns (or unassigns) board privileges as necessary to community members based on the outcome of the voting.
At any point during the year a board member can submit a proposal to the board. For example, let’s say the the main street of the community has fallen into disrepair and is filled with dead trees. Two board members then submit proposal to fix this. The first proposal (A) is submitted with a case for using two vendors to share the responsibilities and to pay each of these vendors 7,000$. The second proposal (B) makes a case for paying a single vendor 10,000$ to do the same work. At this point the members of the board get to review both the submitted proposals and any text, video or supporting documentation provided; talk amongst themselves in whatever format they prefer (or not!); and then vote. The DAC tracks each proposal independently so, members in theory should not vote for both or funds would be released to all three vendors. In our scenario proposal (A) ends up making a stronger case and it receives enough votes to pass while proposal (B) does not. Now the DAC places 7,000$ of the community funds to an escrow account that will release funds to the vendors when work has been approved by the community. The community has no incentive to cheat the vendors, because the record of their behavior is public and immutable and dishonest dealings would ward away future vendors. Similar incentives exist for the vendors.
We’ll be exploring the potential for DACs in future posts. One theme we care deeply about at Smith + Crown is governance of these complex systems – not regulation or committees or formal institutions but at a basic level, how decisions are made. The community is currently struggling with whether to increase the blocksize. Imagine the governance questions regarding DACs.