Paying Contributors & Operating Costs

Once a cycle's revenue is split, money leaves the DAO along two different paths, depending on what it's for. Keeping them separate is deliberate — they behave differently.

Path 1 — Paying contributors for their tasks (Microjob, pay-per-task)

Members are paid for the tasks they complete, from the Microjob pool. The name to hold onto is pay-per-task — and it's worth being precise about what it does and doesn't mean, because it's easy to read the wrong way.

• Pay-per-task, not pay-per-time. The contrast is with a traditional job, where you're paid for your time — hours worked, or simply showing up. Here you're paid for a completed, qualified deliverable. Time spent, effort, and hours online don't earn anything on their own; a finished deliverable that passes review does.
• A "task" is an end-to-end deliverable — not a chore handed to you. Each task in a DAO's scheme is a whole, checkable outcome with a clear Definition of Done: a heritage-keeper profile documented and approved, an online class run end to end, a partner signed. It is not "whatever small job came your way." This is the misreading to avoid — pay-per-task is not payment for assigned odd jobs; it is payment for carrying a deliverable through to done.
• Doing more doesn't mean earning more — completing qualified deliverables does. Picking up lots of small activity, staying busy, or lending a hand around the DAO does not, by itself, earn more. What earns is completed, reviewed-qualified deliverables, at the scheme's rate. Ten half-finished things earn nothing; one deliverable taken to done earns its rate. Helping others and covering gaps is real and valued — it is recognised through KAT, and if you carry a lane-mate's deliverable all the way to a qualified done, that deliverable is paid, because pay follows the deliverable, not the name it was assigned to. What does not hold is "I did more tasks, so I'm owed more" when those tasks aren't qualified deliverables.
• Pay-per-task and the lane model are one thing seen twice — not alternatives. It's tempting to think "each lane has deliverables, and delivering earns payment — that's something other than pay-per-task." It isn't. A lane owns a stream of end-to-end deliverables; pay-per-task is simply how those deliverables are priced and paid. The lane model says who owns what; pay-per-task says what a completed deliverable pays. A lane's deliverables are its paid tasks.

How it appears in the proposal — the Pay-Per-Task Scheme. In its master plan, each DAO defines a Pay-Per-Task Scheme in their DAO Workbook: one row per paid task, tied to a lane, with its Definition of Done (what "qualified" means), a rate, a basis (per profile, per class, per partner, per milestone…), and how many are planned. That row is the end-to-end deliverable, priced. A member's pay is then the rate of each qualified deliverable they complete — no more, no less; and because each task carries a planned count, the scheme is also what keeps "more activity" from meaning "more budget". The task's task_id links the Workplan (the plan), the Pay-Per-Task Scheme (the price), and the Cashbook (the record), so a deliverable, its done-state, and its payment stay one thread.

How this is settled. Payments settle per cycle, not the moment a task finishes. Across a cycle, members complete their deliverables; the ones completed and reviewed as qualified are the ones that get paid. At the cycle's payout the Operator builds the contributor allocation — who is owed what, drawn from those qualified deliverables at the scheme's rates — the framework computes each amount and an allocation record, and the payout is run as below. (Paying each task the instant it finishes isn't used in DEP 3 — settling a cycle's reviewed, qualified deliverables together is safer and cleaner.)

A verified deliverable is owed. Only reviewed-qualified deliverables are paid — but once a deliverable is verified and confirmed to the DAO, it is owed, and it is paid at the cycle's settlement regardless of whether the contributor is still active in the DAO. The allocation the Operator builds is drawn from verified deliverables, and a verification, once complete, is not something a single person can undo. This protects contributors: work that was done and checked gets paid.

Shared deliverables. Where a deliverable was done by more than one person, the Operator pays each contributor their recorded share directly, from the deliverable's single rate — not one lump to a representative. The split is the one submitted with the deliverable and confirmed to the DAO; the framework produces a per-person payout for each, exactly as it does for individually-owned deliverables.

Path 2 — Operating costs (via a treasury vote)

Costs that aren't tied to one person's task — a venue, a tool, a community micro-grant — come from the Treasury pool, not through pay-per-task. These are released by a DAO vote, with the funds going to the DAO Lead or treasurer to spend against receipts. This path exists because operating costs don't attach to a single contributor, so per-task logic doesn't fit them.

How a payout is executed

For this first live cohort, Kambria runs the payout as a managed process: the framework prepares the payout and a human-readable summary — total USDT out, number of recipients, the largest recipients — and Kambria executes it with manual checks alongside, so no one is short-changed while the framework proves itself. Each payout is recorded on-chain and the log stays visible.

Longer term, the payout is authorised by the DAO itself — prepared by the Operator, then approved by the DAO's signers on its XDAO multisig treasury before it executes on-chain and the cycle is marked Executed. DEP 3 is the run that gets the framework ready for that.

[Image] Screenshot sequence: "Contributor Allocation" → "Propose Payout" summary → XDAO approval → "Executed" status.