Contributor Payment Guidelines

In DEP 3, real work in a DAO is paid — per task, through the Kambria DAOs Framework. This page explains what gets paid, how a task becomes payable, and how it's settled. The detailed tables live in the DAO Workbook (Pay-Per-Task Scheme, Workplan, Contributions, Cashbook) and in the framework (Paying Contributors); this page ties them together.

1. What contributor payment is — and isn’t

You are paying for a result that was scoped, priced, and approved beforehand. It complements KAT recognition; it never replaces it.

2. Where the money comes from

Contributor payments come from the DAO's $3,000 seed, within the contributor-payouts part of the Budget Plan. The Master Plan allocates it; the Pay-Per-Task Scheme lists each payable task, its Definition of Done, and its rate. Nothing is paid before the Master Plan is approved, and the scheme changes only by a proposal and a DAO vote.

3. How a task becomes payable

Define → Do → Verify → Settle.

1. Define. The task, its Definition of Done, and its rate are set in the Pay-Per-Task Scheme (part of the Master Plan).
2. Do and submit. A contributor completes the task and logs the deliverable, with evidence, in the Contributions tab.
3. Verify — the three checks. The lane owner, the DAO Lead, and a DAO Facilitator each confirm the deliverable meets its Definition of Done. When all three confirm, it is Verified — an objective state, not one person's call. Nobody verifies their own work.
4. Settle. Verified tasks are paid per task, in USDT, through the framework (Microjob), settled once per cycle — not by a per-payment vote. The Cashbook mirrors the on-chain payout.

Binding rule: once a deliverable is verified and confirmed to the DAO, the amount is owed — no single reviewer can reverse it, and it is paid even if the contributor later leaves the DAO.

4. Rates — fair and public

• Same task, same rate for everyone; rates are public in the Pay-Per-Task Scheme, set before assignment.
• The total of all rates stays within the budget.
• Treat rates as pilot rates — modest, and labelled as such.
• Shared deliverables split the fixed rate by Share (summing to 1); the total doesn't increase, and each person is paid their share directly.

5. Payment vs KAT

They co-exist: a paid task can also earn KAT. Being paid doesn't reduce KAT, and earning KAT doesn't create a payment claim. A deliverable is paid once — no double-paying.

6. Safeguards

• Budget-bound. Payouts never exceed the plan; when the budget is spent, no further payouts until re-approved.
• Separation of duties. Do ≠ verify: the three checks are three different people, and no one signs off on their own work.
• Transparency & co-audit. The Workbook is visible to all members, who can review and question any payout in the DAO's Discord channel; the framework's payout ledger is on-chain.
• Conflict of interest. Anyone with a personal stake in a payout steps out of verifying it.

7. Roles

Worked examples

For real, filled examples, see the example DAO Workbooks — the Pay-Per-Task Scheme and Contributions tabs of the Capacity Exchange DAO and Heritage Kitchen DAO workbooks show real tasks, rates, and verified/paid deliverables end to end.