Categorisation & Revenue Split

Estimated reading: 5 minutes 7 views

This page explains what happens to revenue once it's received: how it's labelled, and how it's divided.

Revenue categories

Every payment is tagged with a Revenue Category — for example Service or Product. Categories are chosen from a set list rather than typed freely, for a simple reason: it keeps reporting consistent across DAOs and makes splits predictable. A DAO's available categories are part of its configuration, set by its Organizer.

The split: dividing revenue into pools

When revenue is confirmed, the framework divides it according to the DAO's Split Configuration — a rule the DAO's Organizer sets in advance. The rule is:

Predefined — set once, before revenue flows, not negotiated per payment,
Versioned — any change is explicit and recorded, so past splits stay reproducible,
Deterministic — the same input always produces the same result.

The split divides revenue among pools. The framework supports up to six pool types; each DAO configures which pools it uses and what share each gets — so a simple DAO might use two or three, and a more complex one all six.

Pool	Who / what it's for
Microjob	Work contributors — funds pay-per-task payments to members who did the work (see Paying Contributors & Operating Costs).
Order Handler	Members who handled the orders behind the revenue — revenue sharing by attribution (see Order Handler Revenue Sharing).
Organizer	The DAO's organising role.
Dev Partner	A development partner's share, where one is engaged.
LP Holders	Fund contributors — those who put in seed capital or cash sponsorship (roughly 1 USDT ≈ 1 LP).
Treasury	The DAO's own reserve, for operating costs and future work.

The share to each pool is the DAO's decision, made in its master plan and set in the split configuration — not a number handed down by Kambria. What the framework guarantees is that whatever rule the DAO sets is applied automatically, identically, every time, and recorded.

[Image] Screenshot: the split configuration for a DAO (pools + percentages, with version).

A standard split for DEP 3

The framework supports up to six pools; each DAO configures which it uses and what share each takes, set in its master plan and changeable by governance. So the cohort's first live run stays consistent and comparable, Kambria provides a standard split every DAO works from.

What each pool is for

Pool	For
Order Handler	Members who bring in and handle orders (referral, sales, support) — split equally across the handlers on each order
Service Provider / Microjob	Members who deliver the service for the order (e.g. a CED session, a produced piece of work)
Dev Partner	The party that built and maintains the core platform the service runs on — used only where such a partner exists
Organizer	The organising role (currently Kambria)
LP Holders	Fund contributors (seed capital / cash sponsorship), pro-rata to LP held
DAO Treasury	The DAO's own reserve — operating costs and future work

On the Dev Partner pool

In DEP 3, projects keep their own IP and collaborate with the DAO on service — they do not license their product to the DAO (see IP Framework for DEP 3 DAOs). So a participant-proposed project is not a "Dev Partner" and does not take a licensing share of the DAO's service revenue: the project's return from the collaboration is the scaling of its own solution through the DAO and its community.

The Dev Partner pool therefore applies only where an actual development partner built and maintains the platform — as Kambria does for CED, the model DAO. Even there, the share behind that pool depends on a condition — the partner opening its codebase and the DAO co-owning the IP — that is not active in DEP 3 (Kambria still holds CED's IP). So for this cohort, the Dev Partner share is directed to the DAO Treasury rather than paid out as a licence.

The two standard configurations

Participant-proposed DAO (no Dev Partner) — the default. The Dev Partner share folds into the Treasury, which early on funds the push the DAO needs most: sales and marketing — Partner Outreach tools (LinkedIn Sales Navigator, Closely) and a referral programme.

Pool	Share
Order Handler	15%
Service Provider / Microjob	25%
Organizer	11%
LP Holders	15%
DAO Treasury	34%
Total	100%

CED (with a Dev Partner) — demonstrating the full structure. CED keeps the six-pool shape, so the framework's Dev Partner capability is shown in a real DAO. The Dev Partner pool is reserved to Kambria as the announced Dev Partner, but — because CED's IP is not yet co-owned by the DAO — that share is directed to the Treasury for DEP 3.

Pool	Share	Note
Order Handler	15%
Service Provider / Microjob	25%
Dev Partner	23%	Kambria (reserved); directed to Treasury in DEP 3 — IP not yet co-owned
Organizer	11%	Kambria
LP Holders	15%
DAO Treasury	11%	(+ 23% Dev Partner = 34% effective this cohort)
Total	100%

Closing a cycle

Revenue is split and paid out per cycle (weekly or monthly), not per individual payment. To close a cycle, the Operator selects the period, reviews the revenue items included, locks the total, and chooses the active split version. The framework then produces a cycle summary showing the gross revenue and the amount going to each pool.

[Image] Screenshot: the "Cycle Closing" view with the cycle summary (gross → each pool).