A DAO that starts as one token holding one treasury and one voting queue eventually hits a wall: routing every hire, grant, and integration through a global token vote is slow, low-turnout, and swamps holders with decisions they have no context for. The response is modular structure – breaking the monolith into smaller units that own a slice of the mandate and act without waiting for the whole token base to weigh in. Three patterns dominate, distinguished mainly by how much autonomy and separate capital each unit gets: SubDAOs, working groups, and pods.

Why DAOs decompose

Token-weighted voting is a blunt instrument for day-to-day operations. Quorum is hard to reach, most holders rationally abstain, and a treasury of anonymous voters cannot supervise a design team or negotiate a partnership. Large protocol DAOs converge on the same fix that scaling human organisations always reach for: specialisation and delegation. A focused unit is given a budget, a scope, and the authority to spend inside it, and the token base retreats to setting mandates and ratifying budgets rather than approving every action. This is the operational face of progressive decentralization – power is distributed outward into units, not just downward over time.

The three forms sit on a spectrum of autonomy. A working group is an internal team on a budget – no separate token, funds flow from the parent treasury. A pod is a lightweight on-chain container – a multisig plus a membership layer – used to give any team custody and permissions without a governance overhaul. A SubDAO goes furthest: its own token, its own treasury, and its own governance, federated to the parent by shared infrastructure and economic ties rather than direct control.

SubDAOs

A SubDAO is a semi-autonomous DAO nested under a parent. It typically issues its own governance token, runs its own proposal process, and holds its own treasury, while remaining tied to the parent through shared reserves, product integration, and reward flows. The canonical example is Sky (rebranded from MakerDAO in August 2024), whose Endgame plan restructures the protocol into a network of SubDAOs it brands as Stars – each a self-governing unit with its own token that plugs into the core Sky Protocol for USDS liquidity and rewards. The first Star, Spark, spun a lending protocol (SparkLend plus a savings product) out of Maker and launched the SPK governance token.

The appeal is focus and blast-radius control: a Star can move fast and even fail without taking the parent down with it. The cost is token proliferation – every SubDAO adds a governance token to bootstrap, a treasury to secure, and a fresh surface for capture or apathy, so the coordination problem is divided rather than dissolved.

Working groups

A working group keeps decomposition lighter: a standing team with an elected mandate and a budget drawn from the parent treasury, but no separate token. ENS DAO is the reference implementation. It runs three working groups – Meta-Governance, ENS Ecosystem, and Public Goods – each led by three stewards elected to 12-month terms, with spending executed through a Safe multisig that requires three-of-four signatures (the three stewards plus an appointed secretary). Budgets are approved by the whole DAO in a funding window, then the group spends inside that envelope without further token votes.

Working groups keep governance surface small – one token, one treasury, delegated execution – at the price of weaker separation: the parent DAO retains direct control and the groups depend on it for legitimacy and funds. The same pattern appears as "guilds" or "committees" across many DAOs; the compensation and accountability of these teams is a governance problem in its own right.

Pods

A pod is the primitive underneath both patterns: a small, permissioned on-chain unit that can hold funds and act, without redesigning the whole organisation. Orca Protocol – now Metropolis – popularised the term, defining a pod as a Gnosis Safe multisig wrapped in a membership layer, where access is granted through membership NFTs that act like keycards. Pods can be composed – one pod can manage another's members, or membership can be gated on holding a token or passing a vote – so an organisation can assemble a shifting tree of teams without breaking the parts that already work.

Pods are structure without a new token: they inherit the parent's economics and simply carve out custody and permissions. That makes them the cheapest way to delegate, and the reason multisig-plus-membership tooling underlies most working groups and many SubDAOs in practice.

Frameworks and tooling

The decomposition patterns are supported by a layer of DAO frameworks:

• Aragon – its OSx stack supports nested DAOs and pluggable governance, so a parent can install sub-organisations as first-class on-chain entities (aragon.org).
• Colony – organises work into hierarchical domains (sub-teams) with a reputation system that weights influence by contribution rather than raw token holdings.
• Zodiac – its Roles modifier lets a DAO grant a pod or working group scoped permissions over the parent treasury (spend only these assets, call only these contracts), enabling delegation without handing over the keys (zodiac.wiki).
• Metropolis (Orca) and Safe – the multisig-and-membership base layer most pods and groups are actually built on.

Trade-offs and risks

Decomposition trades one hard problem for several smaller ones. The gains – focus, faster execution, contained failure, and clearer accountability – come with real costs:

• Fragmentation. Every new unit is another treasury to secure and another governance process to keep alive; capture or apathy in a SubDAO is still capture.
• Principal-agent drift. Delegating spend to a group weakens the token base's ability to supervise it; scoped permissions (Zodiac Roles) and budget windows mitigate but do not remove this.
• Token proliferation. SubDAO tokens dilute attention and liquidity and multiply the attack surface.
• Coordination overhead. Units that are too autonomous drift from the parent's mandate; too dependent, and nothing was really decentralised.

Modular structure is best read as an answer to why DAOs fail at scale – not a guarantee against it.

How Caper approaches this

Caper starts from the opposite end of the spectrum. Instead of one large DAO that later carves out sub-units and mints them tokens, on Caper every unit is its own caper from birth – a standalone DAO with its own bonding-curve token and treasury. Coordination between capers is then expressed as governed proposals rather than an org chart. A caper's treasury can pass an INVEST proposal to buy another caper's token, taking a real economic stake in it, and a VOTE proposal to cast that stake in the other caper's governance – so a parent caper (such as $CAPER) can seed and steer a network of capers by holding and voting their tokens, not by supervising internal pods.

Because every caper carries the same primitives, the structure is fractal: a caper can spin a division out as its own sub-caper – creating one is permissionless, so a team or the parent's treasury can bring it into being – back it with an INVEST stake, and that sub-caper can in turn spawn and fund units of its own, self-similar at every level. Each unit is a standalone economic entity: its bonding-curve token and treasury are its own P&L, rising or falling on its own results rather than being cross-subsidised on a parent's balance sheet. A parent's exposure is exactly its holding of the sub-caper's token plus its treasury share – so delegating a line of work means backing a unit that sinks or swims on its merits, not carrying it as an internal cost centre.

The result resembles a federation of SubDAOs, but decentralised from the start: there is no monolith to decompose, no separate working-group multisig to trust, and every cross-unit action – funding or voting – is an on-chain proposal weighted by the same canonical vote weight as any other decision. The coordination is a market of capers rather than a hierarchy inside one.