Working groups A working grou… an independent retrospective.On 1 June 2026 a ranked Snapsh…-governance-operating-costs) .

The community and the core tea…he-village-and-the-mission) ).In Raemon's account the missio… anybody could have done them.His prescription is separate m…obol describes and maps roles.

How Caper approaches this Cap…ls) rather than an org chart.A caper's treasury can pass an…r than a hierarchy inside one.

Why DAOs decompose Token-wei…e authority to spend inside it (in grants, the elected domain allocators of the Questbook (/wiki/dao-governance/tooling/treasury/questbook) -run programmes at Arbitrum and Compound), and the token base retreats …es rather than direct control.

Frameworks and tooling The de…n.org (https://aragon.org/) ). Since March 2026 its Linked Accounts feature shows several such accounts as one organisation while each keeps its own permissions ( DAO treasury management (/wiki/dao-governance/concepts/treasury/dao-treasury-management) ). - Colony (/wiki/dao-governa…her than bought from a vendor.

Working groups A working grou…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 (https://radix.wiki/ideas/dao-working-group-framework) . Working groups keep governance…-governance-operating-costs) .

The community and the core team 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 (https://metagame.substack.com/p/roleocracy-on-importance-of-autonomy) , 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 (https://www.lesswrong.com/posts/yGycR8tFA3JJbvApp/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 (/wiki/dao-governance/tooling/membership/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.

Working groups A working grou…s the reference implementation. It runs, and in 2026 it cut its own structure back. From 2022 it ran three working groups (https:…ns.domains/dao/) that requiresd three-of-four signatures (the… plus an appointed secretary). In December 2025 the DAO delayed steward elections (https://discuss.ens.domains/t/path-forward-on-working-groups-for-term-7/22107) so the stewards could support an independent retrospective. On 1 June 2026 a ranked Snapshot vote, EP 6.44 (https://snapshot.box/#/s:ens.eth/proposal/0xe4e1c052b2ea4f640cab27ddec326df6290d8996a9219b60cda4c4d4509f5f9a) , 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 (https://discuss.ens.domains/t/meta-gov-working-group-term-7-meetings-thursday-4pm-utc-bi-weekly/22280) , chosen in a Snapshot election (https://snapshot.box/#/s:ens.eth/proposal/0xa736ce4411be14ceaab141989ac271ce1ca96aee6d3ac26bb893ec3c898385d0) that closed the same day. The ENS basics site still listed three groups when checked on 15 September 2026. Budgets are approved by the w…-governance-operating-costs) .

How Caper approaches this Cap…l economic stake in it, and a VOTEDIVEST proposal to castsell that stake in the other caper's governanceposition back down – so a parent caper (such as $CAPER) can seed and steerunwind a network of capers by holding and voting their tokens, not by sueconomically, 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-capervising internal pods its capital and its exit, never a ballot. Because every caper carries…r than a hierarchy inside one.

Pods A pod is the primitive u… and many SubDAOs in practice. The pattern outlived the product. Metropolis no longer ships pods tooling: metropolis.xyz (https://metropolis.xyz/) is a parked listing offering the domain for sale, app.metropolis.xyz has no DNS record at all, and the contracts repository (https://github.com/0xmetropolis/contracts) has not been pushed to since March 2023 – the organisation that owns it (https://github.com/orgs/0xmetropolis/repositories) now builds token-launch tooling instead. All checked 26 August 2026. What survives is the primitive rather than the vendor: a Safe (/wiki/daos/infrastructure/safe-dao) with a membership layer over it, which is what Zodiac (/wiki/dao-governance/tooling/frameworks/zodiac) and the framework stacks below assemble directly.

Frameworks and tooling The de…anding over the keys ( zodiac.wikieco (https://www.zodiac.eco/) , formerly zodiac.wiki/) ). - Metropolis (Orca) and Safe Safe (/wiki/daos/infrastructure/safe-dao) – the multisig-and-membership… groups are actually built on. Metropolis (Orca), which named the pattern, has wound its pods product down; the layer is now assembled from Safe plus a permissions module rather than bought from a vendor.

Trade-offs and risks Decompos… – 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 (/wiki/dao-governance/concepts/analysis/council-dissolution) .

Concept Modular sub-organizati…ormerly MakerDAO) (/wiki/daos/organizations/stablecoins/sky-dao) Endgame "Stars"; ENS DAO (/wiki/daos/organizations/infrastructure/ens-dao) worki…mon tooling Safe (/wiki/daos/organizations/infrastructure/safe-dao) mult…mbership/dao-legal-structures)

SubDAOs A SubDAO is a semi-au…l example is Sky (/wiki/daos/organizations/stablecoins/sky-dao) (rebrand…divided rather than dissolved.

Working groups A working grou…e token. ENS DAO (/wiki/daos/organizations/infrastructure/ens-dao) is th…ance 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 (/wiki/dao-governance/concepts/analysis/dao-governance-operating-costs) .

Pods A pod is the primitive u…as a Gnosis Safe (/wiki/daos/organizations/infrastructure/safe-dao) mult… and many SubDAOs in practice.

Concept Modular sub-organizati… multisigs, Zodiac (/wiki/daos-governance/tooling/frameworks/zodiac) Roles, Aragon (/wiki/daos-governance/tooling/frameworks/aragon) , Colony (/wiki/daos-governance/tooling/frameworks/colony) , … Governance models (/wiki/daos-governance/concepts/fundamentals/dao-gov…ibutor compensation (/wiki/daos-governance/concepts/treasury/dao-contrib…, Legal structures (/wiki/daos-governance/concepts/membership/dao-legal-structures)

Why DAOs decompose Token-weighted voting (/wiki/daos-governance/concepts/voting/token-weighte…ve decentralization (/wiki/daos-governance/concepts/fundamentals/progres…es rather than direct control.

Working groups A working grou…; the compensation (/wiki/daos-governance/concepts/treasury/dao-contrib…ance problem in its own right.

Frameworks and tooling The de…meworks: - Aragon (/wiki/daos-governance/tooling/frameworks/aragon) –…org/) ). - Colony (/wiki/daos-governance/tooling/frameworks/colony) –…) with a reputation (https://docs.colony.io/) system that weigh…oldings. - Zodiac (/wiki/daos-governance/tooling/frameworks/zodiac) –… groups are actually built on.

Trade-offs and risks Decompos…the attack surface (/wiki/daos-governance/concepts/analysis/dao-securit…r to why DAOs fail (/wiki/daos-governance/concepts/analysis/how-daos-fa… – not a guarantee against it.

How Caper approaches this Cap…y 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 (/wiki/foundations/what-is-a-caper) , 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 (/wiki/governance/proposals) – 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 federat…r than a hierarchy inside one.

Concept Modular sub-organization of a DAO – decomposing a single large collective into smaller, semi-autonomous units so coordination scales Core forms SubDAOs (own token + treasury), working groups (budgeted teams, no separate token), pods (a multisig + membership layer) Motivation Token-weighted voting over every operational decision does not scale; delegation and specialisation move work to focused units Reference example Sky (formerly MakerDAO) (/wiki/daos/organizations/stablecoins/sky-dao) Endgame "Stars"; ENS DAO (/wiki/daos/organizations/infrastructure/ens-dao) working groups Common tooling Safe (/wiki/daos/organizations/infrastructure/safe-dao) multisigs, Zodiac (/wiki/daos/tooling/frameworks/zodiac) Roles, Aragon (/wiki/daos/tooling/frameworks/aragon) , Colony (/wiki/daos/tooling/frameworks/colony) , Metropolis (Orca) pods Related Governance models (/wiki/daos/concepts/fundamentals/dao-governance-models) , Contributor compensation (/wiki/daos/concepts/treasury/dao-contributor-compensation) , Legal structures (/wiki/daos/concepts/membership/dao-legal-structures)

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 (/wiki/daos/concepts/voting/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 (/wiki/daos/concepts/fundamentals/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 (/wiki/daos/organizations/stablecoins/sky-dao) (rebranded from MakerDAO in August 2024 (https://www.theblock.co/post/313235/makerdao-mkr-sky-dai-stablecoin-usds) ), whose Endgame (https://sky.money/) 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 (https://spark.fi/) , 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 (/wiki/daos/organizations/infrastructure/ens-dao) is the reference implementation. It runs three working groups (https://basics.ensdao.org/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 (https://docs.ens.domains/dao/) 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 (/wiki/daos/concepts/treasury/dao-contributor-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 (https://metropolis.mirror.xyz/ozkx0ZMwIzyahRJiQKpNv_8r7vAhOo-8tucjONhXJHI) – popularised the term, defining a pod as a Gnosis Safe (/wiki/daos/organizations/infrastructure/safe-dao) 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 (/wiki/daos/tooling/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 (https://aragon.org/) ). - Colony (/wiki/daos/tooling/frameworks/colony) – organises work into hierarchical domains (sub-teams) with a reputation (https://colony.io/) system that weights influence by contribution rather than raw token holdings. - Zodiac (/wiki/daos/tooling/frameworks/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 (https://www.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 (/wiki/daos/concepts/analysis/dao-security-and-governance-attacks) . - 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 (/wiki/daos/concepts/analysis/how-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 (/wiki/foundations/what-is-a-caper) from birth – a standalone DAO with its own bonding-curve token and treasury. Coordination between capers is then expressed as governed proposals (/wiki/governance/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. 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 (/wiki/governance/proposals) as any other decision. The coordination is a market of capers rather than a hierarchy inside one.