Why DAC
The DAO experiment has produced extraordinary infrastructure and a remarkably consistent failure pattern.
For more than a decade, the crypto industry has been building decentralized organizations. Aragon shipped a clean, audited framework. Moloch v3 produced elegant treasury mechanics. Hats Protocol gave on-chain roles real teeth. Zodiac made governance modules composable across any Gnosis Safe. Tens of billions of dollars sit safely in DAO treasuries built on these tools today.
And yet, when one looks at what those organizations have actually accomplished: how much capital has been productively deployed, how often the people doing the work get paid fairly and quickly, how many of the largest DAOs ship products at the speed of their best peers in traditional venture, the picture is harder to defend.
The frameworks are not broken. The model on top of which they were built is.
The Pattern
The story repeats itself, almost regardless of the specific protocol underneath.
Treasuries grow large. Productive deployment of those treasuries lags badly. Voter turnout collapses; the figure cited everywhere is that more than 90% of token holders never vote on anything. Governance attacks become a recognised category: activist holders accumulate cheap tokens, push dissolution votes, extract treasury value at a discount to NAV.
The actual work gets done by a small core team operating off-chain, with on-chain governance acting as a slow ratification layer for decisions already made in private. “Decentralization theatre” is now a term used inside the same DAOs that practice it.
This pattern is not produced by bad people, bad code, or bad luck. The frameworks themselves are well engineered, well audited, and used responsibly. The pattern is produced by something more fundamental: the architectural premise that all of these frameworks share.
A DAO is an account that votes can tell what to do.
A treasury contract holds the assets. A governance process produces decisions. When a decision passes, the treasury executes whatever the proposal said: send these tokens, call this function, install that plugin, change this parameter.
The proposal is the unit of work. The vote is the decision. The treasury is the asset. Every token holder occupies the same role: owner, manager, voter, all at once. There is no contractual difference between the holder who deposited capital and the contributor who is supposed to deliver the work.
Real organizations have not worked this way for several centuries. There is a reason for that.
What Real Organizations Actually Do
In every productive organization at scale, two groups of people are deliberately treated differently.
Owners provide capital and hold ultimate authority. They benefit from the company's success and bear the risk of its failure. They do not run the day-to-day. They cannot, as there are too many of them, they are too dispersed, and their information is too thin to make timely operational decisions.
Managing actors — executives, operators, project leads, the people whose names go on the deliverables — do run the day-to-day, and they are compensated and disciplined by a different mechanism. They have skin in the game on the work itself: bonuses tied to performance, vested equity that can be clawed back, reputations that follow them between firms, professional consequences for failed projects.
The key insight
What the Frameworks Have Already Tried
The leading DAO operating systems have all noticed the gap. Each has reached toward closing it. None has actually closed it, because the gap is not at the level of features that frameworks add. It is at the level of primitives that the OS kernel must enforce.
- Moloch v3 introduced loot. Non-voting shares that confer economic rights only. Elegant, but loot does not stake the operator's capital against any specific piece of work.
- Hats Protocol gives revocable on-chain roles. Wearing a hat costs the wearer nothing. There is no economic exposure attached to the role.
- Aragon OSx has plugins with permissions, but every plugin ultimately calls back into the DAO with EXECUTE_PERMISSION. The framework does not know what the call is for.
- Zodiac is explicitly plumbing. Modules and modifiers for Gnosis Safes. It does not pretend to have economic primitives.
Each is excellent at what it does. None is what is missing.
What is missing is a kernel that knows the difference between the people who put up money and the people who put up themselves, and that automatically settles rewards and consequences between them based on real performance.
The Three Primitives
A DAC is structured around three primitives that no DAO framework has, and that none of them can add as a plugin.
Two tokens, two roles
Deals as the execution unit
Evaluators as automatic settlement
Side-by-Side
A direct comparison, in the language of what these protocols actually do today.
| Aragon | Moloch | Hats | Zodiac | DAC | |
|---|---|---|---|---|---|
| What it is | DAO framework with plugins | Treasury DAO with shares & loot | On-chain roles & permissions | Modules for Gnosis Safes | On-chain corporation kernel |
| Manager / owner separation | Not in the protocol | Loot vs shares — economic only | Roles via hats — permission only | Not addressed | Enforced at the token level |
| Skin in the game | None at protocol level | None at protocol level | None — roles cost nothing | Out of scope | Required — agents stake into every Deal |
| Performance accountability | Social, off-chain | Ragequit if you dislike | Revoke the hat | Out of scope | On-chain evaluator: slash, convert, extend |
| Sub-organisations | Build with plugins | SubDAOs via Zodiac | Hats trees | Connect via modules | First-class child DACs through DACDeal |
A Note on Composability
DAC is not closed, and not meant as a replacement for the ecosystem it inherits from. A DAC's treasury can hold any ERC-20. A TreasuryDeal can spend through Permit2 into a Gnosis Safe. An AgentToken holder can wear a Hat for off-protocol credentialing.
What DAC does not do is collapse its kernel into the DAO model. The boundary between owners and operators, the staking-and-slashing economics, the kernel-enforced reward cap, the evaluator vocabulary — these are the protocol's load-bearing decisions.
Choosing the Right Tool
If the goal is community governance over a token-voting on parameter changes, treasury custody for a public good — an established DAO framework is the right tool. Aragon, Moloch, Hats, and the broader Tally and Snapshot ecosystems are mature, audited, and well understood.
If the goal is an organisation where capital and execution must be aligned by the protocol itself, where AI agents and human contributors will both act as managing partners with shared context and learning loop, where work needs to ship fast and be paid for fairly — none of the existing frameworks were built for that. DAC was.
In summary
Further reading
The Problem
Why DAOs fail by design and the structural decision behind DAC.
Protocol
The philosophy of DAC: dual tokens, Deals, evaluators, and fractal structure.
Architecture
A first-principles tour of the protocol's contract boundaries and module system.
About
History, founder, roadmap, $DAC token utility, and treasury allocations.
GitHub
All public repositories, issues, and roadmap discussions.
BaseScan
Explore deployed contract transactions and state on Base Sepolia.