The Architecture
of DAC

A protocol is a set of decisions made early and lived with for a long time. The most important decisions in DAC are not in the whitepaper or the marketing. They are in the shape of the contracts: where the boundaries fall, what each piece is allowed to know, and what it cannot.

The kernel is small on purpose. Power lives at the edges, where it can be replaced.

The protocol is built like an operating system, not a monolith. There is a tiny core that does almost nothing on its own, and a set of well-typed boundaries that everything else plugs into. This is what makes a DAC something you can audit in pieces, extend without rewriting, and trust at the parts that matter most.

The Four Boundaries

Every DAC is composed of four cooperating concerns, each with its own contract and its own clearly defined responsibility.

This separation is not aesthetic. It means an auditor reviewing treasury safety does not have to simulate governance to do their job. Each contract can be reasoned about, tested, and improved on its own terms.

The kernel is a router. The treasury is a ledger. The schema is a policy. The manager is a dispatcher. None of them try to be all four.

Deals and Evaluators. Two Risks, Separately Trusted

A Deal in DAC is not one contract. It is an assembly: a state shell, an execution contract, an evaluator, and a per-deal staking token that gives participating agents fast local voting rights inside the Deal.

The most important architectural decision in this assembly is that the deal module and the evaluator module can come from different sources.

Trust stratification

A DAC can pair a standard treasury deal with a custom oracle-driven evaluator from a third party, without the deal module needing to understand oracles. Or it can pair a novel deal type with a boring, well-audited milestone evaluator. The kernel deploys them independently, and both modules must mutually agree on compatibility before they are wired together.

Above all of this sits a hard ceiling: a kernel-enforced reward cap, set by DAC governance at deal approval time. Even if both the deal contract and the evaluator contract were entirely compromised, rewards cannot exceed the limit the DAC approved.

An evaluator can slash. An evaluator can convert. An evaluator cannot mint money the DAC did not authorise.

Existing Tokens. Governance Without Forcing the Holder

The hardest case in real-world deployment is not the new DAC with a fresh token. It is the live token, with thousands of holders scattered across DEXes and cold wallets, that wants to install governance without forcing every holder to do anything.

The primary path

Every proposal opens a window during which a snapshot oracle publishes the underlying token's holder distribution as a Merkle root. Unwrapped holders vote with Merkle proofs. Wrapped holders vote through their wrapped balance. Both channels anchor to the same proposal reference. No one is forced to wrap, and the long tail keeps its voice.

The fallback

If the oracle fails to publish, or is deactivated, the proposal does not freeze. After a bounded warmup, it falls back into wrapped-only voting with a clean vote state. An adversarial or broken oracle cannot indefinitely block governance. There is always a path through.

Wrapping should be a privilege of the engaged, never a tax on the absent.

A small but consequential detail: qualification thresholds for proposing are expressed as percentages of current voting supply, not absolute amounts. As supply changes, the threshold scales automatically. Governance does not need to vote about its own knobs every time the token does something normal.

Speed Without Anarchy. The Challenge Model

Inside a Deal, governance is local. Staked agents-actors have fast voting rights over their own treasury. They do not need to wait for a full DAC vote to do their work.

The natural question is: what stops a Deal from going rogue? Two answers.

First, the kernel-enforced cap. A Deal can only touch capital that the DAC has already approved for a specific tranche. Reward limits are set at the DAC level. Slashing is on-chain and deterministic.

Second, the challenge model. Certain classes of deal proposals are DAC-challengeable. While a deal proposal is voting normally inside the Deal, the DAC can open a bounded challenge against it. While the challenge is unresolved, the deal proposal cannot execute.

A challenge is a speed bump, not a stop sign.

This is deliberately not a veto. A veto would give the DAC unilateral kill authority over any Deal proposal, which collapses straight back into the failure mode we built DAC to escape. A challenge is bounded in time, used at most once per proposal, and visible to everyone the moment it is opened.

Modules. The Kernel Defines the Physics

The kernel ships with one module: the core module. It exposes two deal kinds and two evaluator kinds.

The core module is not privileged. Any DAC can approve any module through governance, and a new module ships as new contracts without any kernel changes. The kernel defines the lifecycle, the permissions, the routing, and the caps. Modules define the behaviour.

The kernel defines the physics. Modules define the chemistry. Communities choose which chemistry to allow into their organisation.

What This Means for Agents

The protocol is described as agent-native, and the phrase carries weight only if the architecture earns it. It does, because of four things the kernel provides directly.

• Clear treasury ownership — An agent holds an AgentToken, stakes it into a Deal, and becomes a voting participant in that Deal's local governance with Permit2 spend approvals at exact amounts and short expiry.
• Real skin in the game — Staked tokens are at risk. The agent's voting power inside the Deal is proportional to its stake. Bad behaviour is punished by the same mechanism that gave the agent its authority.
• Automatic, verifiable rewards — Evaluators return deterministic outcomes. Rewards unlock on-chain without human signatures. The kernel enforces the reward cap.
• Permission to form sub-organisations — Through DACDeal, an agent or group of agents can spawn a child DAC for a specific initiative. The parent approves once. The child operates within its own scope.

This is the interface an agent runtime can actually use as a first-class participant. The agent is not pretending to be a human; it is a member of the corporation, with the same rules as any other member.

The Principles Underneath

The architecture is not a list of features. It is a list of decisions held in tension with each other, each one constraining the others until what remains is coherent.

• The kernel routes; it does not accumulate cross-cutting concerns.
• Treasury commitments live in one place, not scattered across deal contracts.
• Modules extend behaviour without privilege.
• Deal modules and evaluator modules can come from different sources.
• Governance thresholds are percent-based, so they remain meaningful as supply changes.
• Every passed proposal has a validity window, so no decision ever lurks indefinitely.
• Native and existing-token DACs share the same kernel interfaces.

None of these principles is novel on its own. The discipline is in holding all of them at once.

Where This Goes

A DAC is the smallest viable unit of an on-chain corporation. The interesting question is not what a single DAC can do, but what a network of DACs makes possible.

When a parent DAC funds a child DAC through a Deal, with an evaluator measuring the child's performance, capital flows toward what works. When agents move between DACs as managing partners, taking their reputation and their stake with them, organisations become liquid in a way they have never been before.