Why DAOs Change Everything

This essay is exploring an experimental idea.

Markets are engines of progress and wealth. They are the reason humanity is so well off relative to historical norms. In contrast, economic central planning doesn’t work. It has been tried many times throughout history and never creates prosperity.

But if markets are such a great environment for increasing production and innovation, how come companies are run through central planning? Ultimately, the shareholder and CEO decide how the company is run. We have markets outside of companies, but is there a way to have a market INSIDE a company?

In other words, if countries can harness markets to generate amazing companies… can companies themselves also harness markets to generate amazing products?

Decentralized Autonomous Organizations (DAOs) provide a path forward.

The startup community has long known the importance of iteration speed. There are two common-sense reasons why iteration speed is important.

1. Every time you iterate, you get a chance to compound your progress. You are making a decision from a point of superior information and standing in the market.
2. You can think of an iteration as a small bet.You won’t win every bet, but when you do, the payoff is asymmetric.

But iteration speed doesn’t scale with headcount (labor) or capital expenditures. Huge companies like Google have a hard time using all of their talent and cash reserves to innovate and release new products.

This is because the top-down nature of company org-structures creates iteration bottlenecks. It is a consequence of central planning.

• There is no market mechanism to pick winners and losers within the company.
• The respective benefits and consequences of wins and losses are not internalized to the risk takers and executors.
• There is no internal pricing mechanism to determine optimal resource allocation within the company.
• Adding more people makes it harder for decision makers to coordinate with their team; and adding more money makes it harder for them to generate the same % ROI.

These factors affect iteration because they either:

1. Insulate decision makers from market feedback, causing them to not start from a place of superior information from the last iteration; or
2. Slow execution (and hence iteration) speed, i.e. introducing bureaucracy, adding communication overhead, etc.

As teams scale, these problems become worse. Employee #1 at Google might have doubled the company’s productivity, whereas employee 50,000 might as well not exist.

Small companies can scale well, but they quickly hit an inflection point at which they start to see diminishing returns on added resources.

Generally speaking, a well run company will either try to move the inflection point to the right or raise the asymptote.

However, at some point, the organization will hit capacity. This is because those at the top have limits in their ability to lead. At some point, they cannot generate enough new, well-informed ideas, and execute them well.

Ultimately, shareholders are the bottleneck.

Imagine a “perfect manager”. This manager has unlimited good ideas. Although she cannot implement them all herself, she is able to check other people’s work with perfect accuracy and speed.

The optimal strategy for this manager would not necessarily be to hire a team to implement her plan. As a team grows, the effort required for coordination scales exponentially. There is also significant overhead with employment.

Ideally, she would write thorough specifications for the product plan and then pay people if they successfully submit the work she needs permissionlessly. In order to do this, she would need to make her project open source.

However, if all of these conditions were met, she would no longer have any bottlenecks on the implementation side. The limiting factors would be budget and the rate at which she could write her great ideas.

In this case, implementors are not insulated from the market. They must compete on price, quality, and speed. If they do so successfully, they get paid. If they fail, they don’t.

Any knowledge work implementation can be done in this way for properly structured open source projects.

In fact, this can be performed recursively. Code can implement a design based off of a product feature built to accomplish a strategy. All of this can be, in theory, commissioned permissionlessly and asynchronously.

In doing so, there would be no implementation bottleneck. The only constraints would come from the top.

Again, shareholders are the bottleneck.

And even a perfect manager at the top in an ideal scenario would be constrained by his or her own human capacity. And to make matters worse, there are no perfect managers.

This is why we need to subject those at the top to market forces. The shareholders can replace the CEO, but there is no way to introduce competition to the job of the shareholders without buying out their interest.

In other words, there is no way for the role of shareholder to be performed permissionlessly… Or is there?

Enter the DAO.

DAOs enable you to fork the shareholder base. This is a permissionless way for anyone to compete as a shareholder. However, in order for this to be maximally effective, certain conditions must be met.

• The entire “business” must be on-chain. A fork must have a fully equivalent offering to the original, plus the modifications added by the new shareholders.
• There must be no network effect or economies of scale giving advantage to the original. There must be no lock-in to the original version.
• Application state must be included in the fork.This is an extension of the previous point.
• There must be minimal friction in activating the fork. It must be easy for consumers to choose which version they prefer.
• Users must be able to activate the fork without needing to trust its developers. A hidden benefit of scale is increased trustworthiness.

As an example, imagine there was a social network developed by a DAO. If this social network ran on AWS with a proprietary database and backend, it couldn’t be forked in a meaningful way.

Even if the forkers had access to the source code, it would be extremely difficult to find early adopters for a new social network with no users or data.

Even if users could easily import their existing social graph and data into the forked app, they may not want to provide this information to an unknown developer or execute unaudited code.

But let’s take for granted that you could trust the code. What would this give us?

All of a sudden, you can have a sort of market validated A/B test for any part of the company. If a developer wants to add Snapchat-style stories to the social network, they can create a fork that does just that. Users can “install” that fork and continue using the app as usual. In doing so, they are voting with their feet.

As their usage grows, successful forking DAOS can get compensated with an increased stake in the original DAO and changes can be merged upstream. Or, if negotiations fail, the respective projects can diverge and hard-fork away from each other.

This is new dynamic has profound consequences. From the developer’s perspective, iterations were performed permissionlessly. Since there is no limit or bottleneck to the amount of forks that can be created, the shareholders are no longer a bottleneck. The iteration process, which generates compounding growth, has been parallelized and will scale linearly with the amount of resources provided to it.

So what needs to be built to enable this? I call the idealized version of such a system “the perfect app”.

To get an understanding of what the perfect app would be, we can look to the best app that currently exists: The Web Browser.

The web browser is the best app because it is a thin layer that harnesses the market to provide functionality to its users. The web browser doesn’t really have any use by itself, but it contains rails for companies to iterate on independently and permissionlessly.

Switching between web apps is fast and seamless—enabling competition. Executing code in the web browser environment is secure—promoting trust. It is easy to develop for—increasing speed. These were all innovative features of their day.

Despite limiting what web apps can do relative to native apps, the number of things users can do on a web browser is vastly higher than the number of things they can do on a computer without a web browser.

But web browsers do not enable an optimal forking environment.

• Backend source code is close source
• Databases (containing application data and the social graph) are proprietary
• Companies operate private (physical or virtual) servers to enable functionality
• Some web apps depend on offline processes
• Users cannot fully trust apps with their data

“The perfect app” is like a web browser, but optimizes and provides rails for forking.

In this design, the web browser doesn’t have general Internet access and is instead built on top of an end-to-end encrypted peer-to-peer communication system. This guarantees that the entire application is open source. Application state lives on the front-end (since there is no backend) and therefore can be trustlessly provided to a forked version of the app. In order for this to work, apps need to be run inside of peer groups. Installing a new app into a group would then also port over the social graph. This provides a seamless way to fork and develop social apps. My thesis is that innovation inside of this ecosystem would be orders of magnitude higher than that of the modern web.

I will be writing more about this platform over the coming weeks. If you are interested in helping build it, please reach out (DMs open).