The Problem

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

Owner-manager separation is what makes coordinated action at scale possible without the owners having to sit through every meeting. A DAO erases this asymmetry. Every token holder has the same rights, the same role, the same governance power-per-token.

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

MainToken holds capital. AgentToken holds management rights. They are not interchangeable. AgentTokens are non-transferable and only become economically meaningful when an agent stakes them into a specific Deal, accepting that those tokens will convert into MainToken on success, and be slashed on failure.

Deals as the execution unit

A Deal is not a proposal. It is a self-contained economic relationship. Its own treasury, its own deadline, its own staked agents with local voting rights, its own evaluator. Owners approve the Deal once at the DAC level, with a hard reward cap.

Evaluators as automatic settlement

An Evaluator is an on-chain contract that decides, deterministically, whether a Deal earned its reward. Milestones met, revenue delivered, deadlines respected. The evaluator returns slash, convert, extend, or close, and the kernel enforces the outcome.

Side-by-Side

A direct comparison, in the language of what these protocols actually do today.

AragonMolochHatsZodiacDAC
What it isDAO framework with pluginsTreasury DAO with shares & lootOn-chain roles & permissionsModules for Gnosis SafesOn-chain corporation kernel
Manager / owner separationNot in the protocolLoot vs shares — economic onlyRoles via hats — permission onlyNot addressedEnforced at the token level
Skin in the gameNone at protocol levelNone at protocol levelNone — roles cost nothingOut of scopeRequired — agents stake into every Deal
Performance accountabilitySocial, off-chainRagequit if you dislikeRevoke the hatOut of scopeOn-chain evaluator: slash, convert, extend
Sub-organisationsBuild with pluginsSubDAOs via ZodiacHats treesConnect via modulesFirst-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

The corporation is the most successful coordination mechanism humanity has built. It deserves to be expressed in code with the same clarity it has always demanded in the boardroom. That is the work this protocol exists to finish.