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.
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 (in grants, the elected domain allocators of the Questbook-run programmes at Arbitrum and Compound), 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.
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.
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, and in 2026 it cut its own structure back. From 2022 it ran 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 required three-of-four signatures (the three stewards plus an appointed secretary). In December 2025 the DAO delayed steward elections so the stewards could support an independent retrospective.
On 1 June 2026 a ranked Snapshot vote, EP 6.44, chose "Metagov only" over keeping all three groups, merging Ecosystem with Public Goods, or replacing the groups with a coordination layer. Term 7 began on 1 July 2026 with one working group and three stewards, chosen in a Snapshot election that closed the same day. The ENS basics site still listed three groups when checked on 15 September 2026. Budgets are approved by the whole DAO in a funding window, then the group spends inside that envelope without further token votes.
The Radix DAO is adopting working groups from the start. Its Working Group Framework is one of 21 documents the DAO will ratify in a single constitutional vote, and it sets one to three Stewards per group on six-month terms, reporting progress and spending monthly; any engagement worth 2,500 $USDC or more needs a formal request for proposals. Groups are still established one at a time, each with its own charter and elected Steward. radix.wiki follows the framework on its Working Group Framework card.
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.
Working groups are the cost centre most DAOs report as “governance”. ENS’s published budgets, including what its structure cost while paused for a retrospective, are worked through on DAO governance operating costs.
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.
The pattern outlived the product. Metropolis no longer ships pods tooling: metropolis.xyz is a parked listing offering the domain for sale, app.metropolis.xyz has no DNS record at all, and the contracts repository has not been pushed to since March 2023 – the organisation that owns it now builds token-launch tooling instead. All checked 26 August 2026. What survives is the primitive rather than the vendor: a Safe with a membership layer over it, which is what Zodiac and the framework stacks below assemble directly.
SubDAOs, working groups and pods divide a DAO by function. The founder of the DAO MetaGame, who writes as peth, argues for dividing it first by what members come for (Roleocracy: On Importance of Autonomy & Well-defined Roles in DAOs, 2023). He takes the distinction from a 2019 essay by Raemon on the forum LessWrong about the rationalist community in Berkeley, which calls the two groups the village and the mission (The Relationship Between the Village and the Mission).
In Raemon's account the mission faces outward and has to hold people to standards, so it “cannot offer psychological safety”; the village exists to look after its own members and has to succeed on those terms, not as a recruiting ground for the mission. He argues the two are easier to run separately, with at least two status ladders rather than one, though the village draws its energy from the mission it formed around, and that even a village needs some barrier to entry because it cannot look after everyone.
MetaGame, which peth founded in 2019, ran without that split at first. It started as a direct democracy with one person one vote and no defined roles, and he reports long group discussion of details one person could have settled in minutes, while routine tasks went undone because anybody could have done them.
His prescription is separate meetings for the community and the core team, with entry to the core team conditional on a record of contribution and on no objection from its existing members; named roles, each with a champion and a deputy; and roles re-pledged each season, when other members may apply for them. The community's check is a motion against a role holder, which the core team decides. For tooling he recommends Hats Protocol over Sobol, a role-mapping tool, because a hat can carry an actual permission, such as a multisig signing right, where Sobol describes and maps roles.
The decomposition patterns are supported by a layer of DAO frameworks:
Decomposition trades one hard problem for several smaller ones. The gains – focus, faster execution, contained failure, and clearer accountability – come with real costs:
Modular structure is best read as an answer to why DAOs fail at scale – not a guarantee against it.
The risk that gets written about least is the one at the end. Decomposition is almost always specified without a closing clause, so a body that has outlived its mandate keeps its budget and its permissions until somebody spends governance capital to shut it down. How that is done in practice – the dissolution proposal type, what happens to unspent budget and mid-flight obligations, and where the mandate goes afterwards – is covered in council dissolution and governance unwinding.
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 DIVEST proposal to sell that position back down – so a parent caper (such as $CAPER) can seed and unwind a network of capers economically, not by supervising internal pods. What it cannot do is vote the stake: the VOTE kind that would have cast one caper's treasury ballot inside another died with the escrow voting system and did not return, and vote() admits only an account it checks against the caller. A parent's influence over a sub-caper is its capital and its exit, never a ballot.
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.