From Rough Consensus to Autonomous Execution: How I Learned to Appreciate DAOs
Why I think DAOs do matter in the path towards decentralised governance.
When I joined the Arbitrum Foundation over two years ago, I was brought on to focus on education and research. It fits with my background as a technical academic who enjoys teaching online and in-person workshops.
However, just three days into the role, everything changed.
Blockworks ignited a fire in the DAO that quickly consumed the mindshare on the forum and twitter. It eventually led to delegates rejecting AIP-1 that was supposed to fund the Arbitrum Foundation and establish the entire DAO’s governance framework.
It was a full-blown governance crisis and certainly a memorable introduction to the world of DAOs.
In the aftermath, I volunteered as tribute to take on the task of governance and help set the DAO up for long-term success.
But as an academic at heart, I kept circling back to some fundamental questions:
Why do we have a DAO?
Why should anyone — including myself — care?
Is it interesting or novel in any meaningful way?
Finding answers to these questions was not easy.
I had somehow gone from solving technical problems to navigating people problems. Many ex-colleagues questioned what I was doing with my time.
Over time, I’ve found my own answers to these questions.
This short post is my attempt to articulate the rationale behind why I believe DAOs are important tools for governance despite the many challenges they face.
The same individuals who sparked that controversy are now working full-time for the ArbitrumDAO via Entropy Advisors. Remarkable to witness someone quit their job and join forces with us because they also believe in Arbitrum’s digital sovereign nation vision.
Story: Governing Open Source Software
The story begins with publicly available software.
It is common for developers to make their code available on Github with the intention to allow anyone to:
Read the code,
Understand the code,
Deploy a local instance of the software.
Anyone can modify the code and submit their patch upstream to the main project’s Github via a pull request.
This raises an important question:
How should publicly available code be governed?
Someone must be responsible for reviewing a pull request and deciding whether a patch should be merged into the main codebase.
Nearly all open source projects start off with a small team of developers. But as a project grows in significance, a governance process must be established to allocate responsibility and accountability. This is commonly formalised through a file called CODEOWNERS.
CODEOWNERS defines who is responsible for which parts of the code base including specific directories. This makes it easy to identify the decision makers for any given section of the project. They should review the pull request, leave comments, and decide whether the code should be merged.
In some projects, especially for politically sensitive ones like Bitcoin or Ethereum, decision making is still heavily guided by social consensus. Code owners often see their role not as gatekeepers, but as reviewers who ensure that changes reflect the broader community’s intent.
Bitcoin Core’s decision to rename CODEOWNERS to REVIEWERS reflects this philosophy and more accurately reflects the role of code maintainers. The reviewers file was eventually removed because of complaints that the notifications were very annoying for reviewers, lol.
Keep in mind though — even if a patch is merged into the main codebase, that doesn’t guarantee the code will be used in production.
Only One Meaningful Deployment of the Software?
In the land of crypto, it is often the case that there is only one meaningful deployment of the software.
Anyone can download the code, run a local copy, and send transactions, but it isn’t meaningful beyond acting as a test network.
Launching a meaningful deployment of the software takes a Herculean effort to gain traction and sustain relevance over time. That’s why there’s only one Bitcoin, one Ethereum, one Arbitrum One, one OP Mainnet, one Solana, and one Avalanche.
There are times when the same software is used to deploy an entirely new network and the code is designed to make this easy to do. This is fundamental to the rollup-centric roadmap, the forking of blockchains, and the launch of new L1 blockchains.
Yet, despite sharing a common codebase at inception, each deployment tends to evolve independently. Over time, the code that underpins the live instance often diverges based on the unique need and priorities surrounding its ecosystem.
Blockchain Governance And Consensus Rules
Of course, going back to the problem of governance, this brings up one of the most important questions in blockchains:
How is the live deployment of the software governed?
There are many components of a blockchain network that requires some form of governance and decisions to be made including:
What version of the code should be used?
What is the genesis block?
What is the software’s configuration settings?
This is often referred to as the consensus rules for a blockchain network. All users must reach consensus on the same shared set of rules and users will run software that they believe faithfully enforces those rules. If different versions of the software implements conflicting interpretations, then this can cause a fork and users will end up on divergent views of the blockchain.
In the context of rollups, however, the model is slightly different. Users are not responsible for enforcing the consensus rules. Instead, it is the responsibility of a smart contract suite, commonly referred to as a validating bridge, which holds all user deposits. What matters in rollups is the state transition function which dictates access control, the validity of transactions, and how users can safely exit during an emergency.
In both cases, whether blockchains or rollups, we still need a process to collectively decide what rules should be enforced. This brings us to the challenge of governing systems that may secure billions, if not trillions, of dollars in assets.
As we will see, it is far from a straightforward problem to solve.
Towards Decentralised Governance
The philosophy of progressive decentralisation encourages projects to gradually transition control from a single authority (like the founding team) to the wider community as a network grows in importance.
There are many reasons a founding team may choose to step back and relinquish control: from limiting legal liability to recognising that their influence has waned as others in the community step up to lead key work-streams.
After all, Satoshi Nakamoto was fearful that Bitcoin usage with Wikileaks could be destructive. He described it as kicking the hornet’s nest and the swarm was headed for him. He stopped posting on the forum within a few days after those messages.
In many cases, the explicit goal is to build a system that can thrive beyond the founding team’s remit and can take on a life of its own into the long-term, hopefully for the next hundred years or more.
To date, there are two approaches to enable the community to take the reigns on governance:
Rough consensus. Everyone signals they want to upgrade and this activates a flag day.
Explicit voting. Participants cast a vote and the outcome is determined by the final tally.
Interestingly, both approaches, are opposite ends of the spectrum, as one embraces ambiguity and informal agreement while the the other depends on a formal and measurable consensus that seeks explicit confirmation.
Let’s take this opportunity to explore all three approaches to better understand the rationale that has led to the rise of decentralised governance including why DAOs are interesting.
Single Authority & Single Point of Failure
All projects begin with a single authority who coordinates the upgrade of the network.
The reasons are straightforward: only the core team understands the code base, the community is small with limited stake, and there is a need for rapid iteration to address bugs and add features.
This was true for Bitcoin too.
It was common for Satoshi Nakamoto to announce a software upgrade and inform node operators that they should upgrade in a timely manner. This was communicated on the mailing list, the bitcointalk forum, and the relevant IRC channels.
However, eventually when a blockchain network reaches a certain size and significance, the community needs to decide how it should be governed into the long-term.
Why is this necessary?
The common answer —because decentralisation—is often invoked, though the term is frequently overloaded and imprecise.
In my opinion, it is important to eliminate single points of failure in decision-making and to ensure all stakeholders who depend on the network’s success have a voice in deciding how the live system develops overtime.
At some point, the live deployment of the software should become bigger than the core team and this is essential for long-term resilience of the system.
Rough Consensus & Hot Potato
One approach to governing a blockchain project is rough consensus. It has become the de facto standard in Bitcoin near the end of Satoshi Nakamoto’s term and certainly by the time he handed control to Gavin Andresen.
This model gained prominence during the Bitcoin Block Size War, where it served as a key defence to fend against hostile governance takeovers. It also played central role in Ethereum’s response to TheDAO hack, when the Geth client offered users a choice: upgrade to the hard fork chain or continue running the original chain containing the stolen funds.
But what is rough consensus?
It is a decision making process in which no single party can (or wants to) single-handedly dictate the software version used for the live deployment of the network. Instead, each party independently signals a willingness to upgrade, a flag day is set, and each party is expected to upgrade their software by that date.
The entire process resembles a game of hot potato — no one wants to be seen as initiating the upgrade, but everyone wants to agree that the upgrade should happen. When the potato falls into their hands, they can issue their signal before passing the potato onwards.
The greatest challenge, and some would argue, the greatest strength of rough consensus, is the ambiguity around how to assess the relevance or weight of a given signal.
For example, during the Block Size War, numerous Bitcoin companies expressed support for the upgrade, but the signal lacked overwhelming influence and ultimately failed to push the desired upgrade on Bitcoin.
This ambiguity is intentional.
It serves as a defence against hostile governance takeovers. By keeping it unclear who is making the final decision, participants maintain plausible deniability and are under no obligation to upgrade. In this sense, it makes the upgrade difficult to exercise, by design.
This reflects a broader expectation: reaching global consensus to change the system should be rare and it should become increasingly more difficult as time goes by.
Voting Systems and Self-Enforcing Autonomy
A voting system represents the opposite end of the spectrum from rough consensus. It favours explicit rules, formal procedures, and measurable outcomes over ambiguity and informal agreement.
The system has a predefined list of eligible voters and each voter is assigned an explicit voting weight. Voters are required to cast their vote within a specified time window and the final tally determines the community’s decision.
We say the voting system is autonomous when it operates entirely on a public blockchain and it has the authority to unilaterally enforce software upgrades.
There are several autonomous voting systems that are already live:
Ethereum’s proof of stake protocol allows validators to vote in real time to adjust the block gas limit, directly influencing network parameters.
Tezos, known as a ‘self-amending’ blockchain, enables token holders to vote on protocol upgrades focused on economic rules,
The Cosmos SDK includes a governance module that allows token holders to propose and vote on software upgrades affecting a specific chain.
And most relevant for this discussion: DAOs on Ethereum. These organisations can coordinate proposals, assign voting rights to token holders, and self-enforce upgrades to the smart contracts they govern. All on-chain without relying on external actors.
It can be argued that all the examples above — from Ethereum’s proof of stake protocol to governance systems built around on-chain voting — fall under the broad definition of a Decentralised Autonomous Organisation (DAO).
What unites them is a critical ingredient: a defined set of voters can decide an upgrade should occur and the software itself enforces that decision.
In this model, authority is not merely a signal, but it is automatically executed through the code.
Which Approach Is Superior?
Both rough consensus and on-chain voting are mechanisms to measure the community’s intent to upgrade the software.
It is not necessarily the case that one approach is inherently better than the other. The key difference lies in the source of control for executing changes and there is a nuance in this distinction.
We can broadly categorise two sources of control:
Social consensus with off-chain enforcement.
Upgrades happen when all participants voluntarily choose to run new software.
Control is ultimately held by the individuals or entities running the nodes.
On-chain authority with autonomous execution.
Upgrades are encoded as permissible actions within the protocol itself.
Control is enforced by the software based on pre-defined rules and vote outcomes.
It just so happens that:
Rough consensus aligns naturally with social consensus with off-chain enforcement,
On-chain voting only really works when used to upgrade components that do not rely on off-chain coordination such as smart contracts on public blockchains.
This is why DAOs have found product market fit. The voting system not only records intent, but it can also directly enforce the upgrade of a suite of smart contract ensuring the agreed changes are executed.
ArbitrumDAO. The voting system can unilaterally upgrade the smart contracts that hold all funds in Arbitrum One. It is the smart contracts that are responsible for enforcing the rules and they will ignore any off-chain actor who is not running the correct version of the software.
This brings us to one of the most important takeaways for decentralised governance systems:
Social consensus ultimately overrides on-chain authority.
No matter how autonomous or trust-minimized a system claims to be, if a devastating vulnerability emerges in a suite of smart contracts, then the last-resort option is to hard-fork the underlying public blockchain.
Interestingly, the Optimism documentation outlines an approach to entice Ethereum validators to soft-fork the L1 in order to unfreeze fends held in the bridge in the event of a critical failure. This proposal sparked significant controversy at the time including a blog post by Vitalik Buterin to caution against overloading Ethereum’s social consensus.
Are DAOs actually interesting?
Yes — they are interesting and very useful.
To summarise why:
Relinquish control. DAOs offer a practical mechanism for founders to step back and transfer authority to stakeholders who are better positioned to govern the project over the long term. This enables a more sustainable and decentralised model of stewardship as the ecosystem matures.
Specific domain. DAOs are designed to govern a specific domain — typically a suite of smart contracts — and they do so with clear, enforceable authority. This form of governance can operate autonomously on a public blockchain and remains independent of broader social consensus.
Explicit nature. The on-chain voting system makes clear whose opinions count in an upgrade and how much influence each participant has. In many cases, voting power is proportional to token ownership, with weight measured by the number of tokens held. However, this isn’t a requirement, as alternative models can be explored such as proof-of-personhood with one-person-one-vote, are increasingly explored.
Beyond software. Many DAOs have expanded their scope beyond just governing software deployments. They now manage ecosystem treasuries, establish organisational hierarchies through popular vote, and even exercise authority over legal entities, such as BORGs (Blockchain-Oriented Responsible Governance structures).
DAOs are far from perfect, but they remain one of the most promising tools we have for coordinating governance over a suite of smart contracts.
That said, they still have many problems.
A recent twitter thread has captured a range of opinions on why DAOs have “failed” to date. In my view, the biggest issue is perception: DAOs are often seen as toxic or adversarial environments which discourages thoughtful and sustained participation. This ends up with an adverse selection problem as valuable stakeholders who should be involved simply avoid it.
To be fair, many of these problems stem from the expanded scope that DAOs have taken on beyond governing software upgrades. They have budgets, organisational structures, and community politics, each introducing their own set of political and coordination problems.
Yet, even if DAOs simply focused on software upgrades, governance would still be far from straightforward. As the Bitcoin Block Size War made clear, even changing a simple configuration can become deeply controversial when the stakes are high.
I believe this can be fixed, but to do so, we need to acknowledge the problems and potential ways to solve for them. I have covered some of this in a recent talk and I hope to write more soon. 😋
What do you think about the AI entering DAOs and generally the world of governance?
If governance is framed as a game, it feels that DAOs/explicit governance/voting would be a bad idea because there would most likely be a dominant strategy, and the space for plurality would likely diminish.
On the other hand, with rough consensus since the game is not well-defined; the dominant strategy would be harder because the meta-game of signalling/championing/information dispersal needs to be factored in. It feels like there would be a wide range of interests that could express themselves in this system.
Best article about DAO I read for a while. From a practical xp to theory. And for once putting a practical definition of DAO as governing Open Source. Can you extend on why "DAOs have found product market fit."