DAO MASTER PLAN PROPOSAL — [DAO NAME]

A DAO's master plan is the first real act of ownership in the cohort: the point where the shared model becomes this DAO's concrete shape. This proposal is the narrative and the strategy; the concrete tables live in the DAO Workbook, linked from each section. Draft it with your DAO Facilitator, self-check it against the DAO Proposal Qualification Checklist before you submit, then submit it through XDAO for the cohort to vote on.

Workbook: [link to this DAO's Workbook (DAO Workbook Blank Template)]  ·  Self-check: DEP 3 · DAO Proposal Qualification Checklist  ·  DAO Facilitator: [name]  ·  Date: [date]

 

Part 0 · The Project & the Collaboration

For a participant‑proposed DAO, start here: the project your DAO is built around, and what a DAO can realistically do to scale it. Everything after — the Objective, lanes and workplan — flows from this, not from the project in the abstract. (An operator/model DAO built around a platform rather than an external project can keep this short: describe the platform and the community it serves, then go to Section 1.)

 

The project

• Project name & what it does: [1–2 sentences — the working solution and the community it serves]
• How it meets the criteria (the same criteria you applied under — state them plainly, with evidence):
  • An innovation solution in hand — [the solution is already in use, by whom, for how long, and the evidence it works — links, outputs, numbers]
  • Regeneration proven — [how the project sustains itself, with records that it has actually happened — earned income, sales, memberships, sponsorship — not a plan]
  • A local community — [who the community is, roughly how large and active, and how they take part]
  • Practical conditions — [reliable internet for the team; cryptocurrency not banned where members are]

 

The collaboration a DAO can do (feasibility)

• The boundary — what stays with the project's people: [what the cooks / practitioners / makers keep doing, and what the DAO does not ask them to become. The boundary protects the community and keeps the project itself intact.]
• What the DAO amplifies: [the directions of work a DAO of ~10–20 can own — reaching new people, telling the story, running online sessions or events, building partnerships, producing content. This is the concrete collaboration the cohort delivers.]
• Value & IP: [value flows through the framework. Note the IP this DAO will produce and how it's handled — what work you expect to create (a collection, content, artworks…), how the originating community is credited where the work draws on their knowledge, and whether you'll anchor it on-chain. The DAO amplifies; it does not take ownership of what the community created. See the IP Framework for DEP 3 DAOs. (An operator DAO that produces no standalone work can note "no IP produced".)]
• Why it's feasible in a cohort: [it divides into a few owned lanes, has a natural onboarding lane, is runnable by ~15 people over the cohort, and has real revenue paths — so it's tested with real money, not in theory.]

From this collaboration, the rest of the plan follows: Section 2 turns it into an Objective and lane Key Results, Section 3 into lanes and members, Section 4 into a workplan, Sections 5–6 into the pay‑per‑task scheme and budget. See the worked Example (Participant‑Proposed): Heritage Kitchen for a filled Part 0.

 

1 · DAO Overview

Who this DAO is and the project it scales.

• DAO name: [name]
• Type: [Operator DAO — members run a platform/flow others create value on · or · Practitioner DAO — members create the value themselves]
• The project / solution it scales: [one line — the fuller treatment is in Part 0]
• Mission (one line): [what scaling this solution through community means for you]
• DAO Lead: [person_id / name]  ·  Kambria Facilitator: [name]
• Project team in the DAO: [how many of the originating project's team take part — together no more than the DAO's quorum threshold (currently 34%), so the DAO stays community-governed]

→ Define in the Workbook: DAO Master tab (identity, KDF addresses, file library, nodes/partners).

 

2 · Objective & OKRs

How this DAO knows it's succeeding. In DEP 3 that is the scaling of impact — not revenue.

The DAO Objective (the three axes). State what scaling impact means for this solution, on each axis, with a target:

• Reach — [how many new people / communities; sessions or deployments run] · target: [ ]
• Depth — [return and continued use; real cases where the solution was applied] · target: [ ]
• Self-propagation — [the community carrying it onward — referrals, people who move from receiving to spreading] · target: [ ]

How success is measured. Numbers where they help, field notes where they don't. Revenue is recorded in full but is a signal, not the target.

Lane Key Results roll up to this Objective. Each lane sets checkable Key Results expressing its part of the Objective (defined per lane in Section 3 and in the Lane Proposals).

→ Define in the Workbook: OKR tab (DAO Objective on the three axes + each lane's Key Results). See the Measuring What Matters page for the framework.

 

3 · Scopes, Lanes & Members

How the DAO's work is owned. A lane is a pair; lanes group under a few scopes; every DAO has an onboarding lane.

Scopes (3–4): [name the broad directions — e.g. for CED: Growth · Activation · Operations]

Lanes (a pair each). For each lane: its scope, the two owners, what it owns (its boundary), and the decisions the pair can make without asking.

Scope	Lane	Owners (pair)	What it owns (boundary)	Decides without asking
[ ]	[ ]	[ , ]	[ ]	[ ]

(Include the onboarding lane — the pair who welcome new people and turn sign-ups into active contributors.)

Roles. DAO Lead: [person_id] · Kambria Facilitator: [name]. KDF roles (one person may hold several): Order Handler [ ] · Operator [ ] · Organizer [ ].

Floating contributors: how members who don't own a lane contribute across lanes.

→ Define in the Workbook: Owned Lanes & Roles tab (+ Roster). See the Owned Lanes Model and Member Roles & Contribution pages.

 

4 · Workplan

What each lane will actually do — as tasks anyone can pick up, each with a clear Definition of Done. This is where DEP 2's "didn't know how to plan the work" problem is answered: a task is not "do the thing", it has a checkable done-state and an owner.

• Per lane: [the main tasks/deliverables, each with its Definition of Done, owner, and dates]
• Cross-lane activities: when several lanes push toward one shared goal (a campaign, a launch), name the activity and how each lane contributes — so cross-lane work is concrete, not hoped-for.

→ Define in the Workbook: Workplan tab.

→ Resource — partner outreach. If a lane's work includes finding partners or sponsors, apply the DAO Partner Outreach Playbook (in your DAO's shared Drive, not on the public docs) — a ready runway with the partnership model, target-list format, outreach templates, and the outreach tools, using CED as a worked example.

 

5 · Pay-Per-Task Scheme

What the DAO's paid tasks are, and what each one pays. Contributors are paid per completed, reviewed-qualified task, settled monthly through the framework. Set here, changed only by a new proposal and a vote.

• Payment principle: pay-per-task — what a member is owed follows the tasks they complete, at the task's rate; settled once a month for reviewed-qualified tasks.
• The tasks and rates: [the approved menu — task, Definition of Done, rate, basis, how many planned]

→ Define in the Workbook: Pay-Per-Task Scheme tab.

 

6 · Budget Plan

How the DAO's $3,000 seed — its capital for this collaboration, released monthly — is allocated. Two parts:

• Contributor payouts: [total from the Pay-Per-Task Scheme, by lane — paid through the framework]
• Operating costs: [tools, hosting, venue, community micro-grants, on-chain fees, contingency — released by a DAO vote to the DAO Lead / treasurer, against receipts]
• Against the seed: [total planned vs $3,000; the buffer left over; monthly phasing across execution]

Budgeting principles: impact-first spending; receipts for every cost; transparent and visible to all members; the seed is starting capital for scaling impact, not a sum to be earned back.

→ Define in the Workbook: Budget Plan tab. (Revenue the DAO earns is split by the framework's standard DEP 3 split — separate from this seed budget; see Categorisation & Revenue Split.)

 

7 · KAT Reward Framework

How the DAO recognises what isn't a paid task — welcoming, helping a lane, governance. On the KAT Reward & Privilege Framework 1.0: configure, don't redesign. Credits → Karma → KAT, settled monthly.

• What this DAO recognises: [the contribution types and stakeholders it credits — DAO members, and community contributors like guides, ambassadors, partners]
• Karma & tiers: [how standing builds; any privileges the DAO attaches, within the framework]

→ Define in the Workbook: KAT Config · KAT Credit Rules · KAT Karma & Tiers tabs. See the KAT in DEP 3 page.

 

8 · Rhythms & Coordination

How the DAO stays aligned. Weekly per-DAO check-in (each lane updates, blockers surface early); monthly All-DAOs Sync (each pair speaks to its Key Results); cross-lane activity plans when lanes move together. See the Operating Rhythm page for the full cadence.

 

9 · Timeline

The DAO's execution timeline, aligned to the program phases (Onboarding Jan · Execution Feb–May · Summary & Showcase Jun 2027). [key milestones and when]

→ Define in the Workbook: Timeline tab.

 

10 · Governance

How decisions are made. Proposals through XDAO (Approve / Reject / Request Changes); operational decisions by [e.g. 48-hour Discord poll]; changes to this plan or the budget require [quorum]. The project team holds no more than the DAO's quorum threshold (currently 34%), so no decision rests with the originating team alone. Master plan revision: [how amendments are proposed and voted].

 

11 · Dependencies & Risks

What this DAO depends on, and what could go wrong.

• Cross-lane / cross-DAO / external dependencies: [ ]
• Risks & mitigations: [name each risk and how you'll handle it — internet, crypto access, key-person, low activity, etc.]

 

12 · Documentation & Reporting

How the DAO keeps its record. Field notes alongside the framework's numbers; weekly lane updates; monthly contributor + KAT settlement; the end-of-cohort summary report, scored on the Proposal QA tab (qualitative 30 + quantitative 60 = 90 → tier → decision).

→ In the Workbook: Lane Weekly · Contributions · Cashbook · KAT Settlement · Proposal QA tabs.

 

13 · Readiness checklist (self-check before submitting)

• Objective set on all three axes, with targets; each lane has checkable Key Results
• Scopes, lanes and pairs defined, including the onboarding lane
• Workplan tasks each have a Definition of Done
• Pay-Per-Task Scheme rates set; Budget Plan within the $3,000 seed
• KAT configuration set (credit rules, karma, tiers)
• Project team within the quorum cap (≤34%)
• Practical conditions met (reliable internet; crypto not banned where members are)
• No overclaim — honest about what is proven vs to be tried; risks named
• IP handled — what the DAO produces, how the source community is credited, and whether it's anchored (or 'no IP produced')

(Self-check against the DAO Proposal Qualification Checklist before submitting — the same checklist Kambria uses, in its scored mode, to qualify the plan before the vote.)

 

Companion: Lane Proposal — [Lane name]

Each pair writes a short proposal for its lane, from this template. It's brief on purpose — the lane's detail lives in the Workbook; this states what the pair commits to. Drafted under the DAO Facilitator's guidance, using the lane's Launch Kit.

• Lane: [name]  ·  Scope: [ ]  ·  Owners (pair): [person_id, person_id]
• What this lane owns (boundary): [the continuing area of work that is yours]
• Decisions we make without asking: [the real decisions inside the boundary]

Our Key Results (our part of the DAO Objective — checkable outcomes we commit to):

• [KR 1 — axis, target]
• [KR 2 — axis, target]

Our workplan (the tasks we'll do, each with a Definition of Done):

• [task — done when …]

Our paid tasks (from the Pay-Per-Task Scheme — task + rate):

• [task_id — rate]

What we need (support, budget, dependencies on other lanes):

• [ ]

→ Define in the Workbook: this lane's rows in Owned Lanes & Roles · OKR · Workplan · Pay-Per-Task Scheme. Concept and boundaries: Owned Lanes Model page; the lane's Launch Kit for the running start. For a partnerships or partner-outreach lane, also the DAO Partner Outreach Playbook in your DAO's shared Drive.