FB Pixel
DAO Operations Excellence

The Kambria DAOs Framework (KDF)

Estimated reading: 4 minutes 8 views

Overview: What the Framework Does

The Kambria DAOs Framework is how a DEP 3 DAO handles real money without doing it by hand. When a DAO earns revenue, the framework receives it, records it, splits it by a rule the DAO set in advance, and pays out what is owed — and every step is visible on-chain, so nobody has to take anyone's word for the numbers.

The whole framework is one path, repeated for every payment a DAO receives:

Receive → Categorise → Split → Pay out → Record

  • Receive. Revenue arrives as USDT against a payment request, tagged to the DAO.
  • Categorise. Each payment is labelled by type (for example, service or product), so reporting stays consistent.
  • Split. A predefined, versioned rule divides the revenue into the DAO's pools — automatically, the same way every time.
  • Pay out. Those owed are paid directly, with amounts computed by the framework, through the DAO's treasury.
  • Record. Every receipt, split, and payout is logged on-chain and readable by anyone.

Three contracts do this work behind the scenes. Members don't interact with them directly, but it helps to know the names:

Contract What it does
Revenue Vault The DAO's receiving account. Revenue arrives here, tagged to the DAO, in USDT.
Revenue Splitter Applies the DAO's split rule to work out who gets what for a given cycle.
Payout Executor Sends the computed payouts out, in one controlled action, with a log.

Everything runs on Polygon, and in DEP 3 the framework works in USDT only. The DAO's treasury is an XDAO multisig — the DAO's own governed account (how spending is authorised in this cohort, and where it's headed, is covered under Key Concepts & Roles and Paying Contributors & Operating Costs).

 

Key Concepts & Roles

A few terms recur throughout this guide. This page defines them once.

 

The vocabulary

Term What it means
DAO Treasury The DAO's XDAO multisig wallet, which holds the DAO's funds. Longer term, it is the account that authorises splits and payouts (see A2, A5).
Revenue Vault The DAO's on-chain receiving account, where revenue lands before it is split.
Payment Request A request the DAO creates for a specific amount, which a customer pays. It carries the vault address, the amount, and a human-readable reference.
Revenue Category The type a payment is tagged as (for example, service or product), chosen from a set list so reporting is consistent.
Split Configuration The DAO's rule for dividing revenue among its pools. Set in advance, versioned, and applied automatically.
Pool A destination a share of revenue goes to — for example the Treasury, or the contributors who did the work (see A4).
Cycle A period (weekly or monthly) over which revenue is gathered and then split and paid out together.
Payout The transfer of what is owed, computed by the framework and executed through the treasury.
KAT / GT / LP Kambria's recognition and ownership tokens. KAT records contribution and standing (see KAT in DEP 3). GT is the DAO's governance token used for voting in XDAO. LP represents fund contribution — one form a revenue pool can pay to (see A4).

Roles in DEP 3

The framework organises its permissions by workflow into three roles. One person can hold more than one role — in a small DAO a single member may hold all three, while a larger DAO can spread them across different people — so these describe what a role can do, not how many people are involved.

Role What this role does
Order Handler Creates Payment Requests for the orders they handle; adds or removes co-handlers on an order they created; and marks an order completed once it's done.
Operator Manages and executes the distribution batches that split and pay out revenue, and executes Microjob (pay-per-task) payments.
Organizer Configures the DAO's framework settings — split rules, revenue categories, accepted tokens, LP treatment, and so on — and manages the DAO's members, including granting the Operator role.

Because this is the framework's first live cohort, Kambria currently runs the paying-out steps — distributions and Microjob payments — as a managed process, with manual checks. The one exception is a DAO's operating costs, which are released by a DAO vote (see Paying Contributors & Operating Costs). So for now the roles above prepare the work, and Kambria runs the actual movement of money alongside them while the framework proves itself.

Longer term, these actions are designed to be authorised by the DAO itself: prepared by a role, then approved by the DAO's signers on its XDAO multisig treasury — so authority sits with the DAO rather than any one person. DEP 3 is the run that gets the framework ready for that.

[Image] Screenshot: the KDF app role / permission view (Order Handler · Operator · Organizer). 

 

Articles

Next - DAO Operations Excellence The DAO Workbook

Powered By EazyDocs