Money: Pay-Per-Task Scheme, Budget Plan, and the Cashbook

Three tabs handle the DAO's money off-chain: the Pay-Per-Task Scheme (what each task pays), the Budget Plan (how the $3,000 seed is allocated), and the Cashbook (what actually moved). Together they mirror what the framework does on-chain — the framework stays the source of truth for money; these keep the plan and the record around it.

Pay-Per-Task Scheme

Before a DAO can budget or pay anyone, it defines what its paid tasks are and what each one pays. That's the Pay-Per-Task Scheme — the DAO's approved menu of paid tasks, each with a rate.

For each task you set a task_id, its scope and lane, the task, its Definition of Done (what "qualified" means), a rate in USDT, the basis (per task, per member, per session, per milestone), and how many are planned. The budgeted amount computes itself (rate × planned).

This is pay-per-task: what a member is owed follows the tasks they complete, at the task's rate — not a flat wage. Contributors are paid for completed, reviewed-qualified tasks, settled once a month through the framework's Microjob pool. The scheme is set in the DAO's proposal and changes only by a new proposal and a DAO vote. Its budgeted total is what feeds the contributor-payouts side of the Budget Plan.

Screenshot: the Pay-Per-Task Scheme tab (task_id · lane · Definition of Done · rate · basis · # planned · budgeted). Source: the DAO Workbook template.

Budget Plan

The Budget Plan shows how the DAO's $3,000 seed — its capital for the agreed collaboration — is allocated. It has two parts, matching the two ways money leaves the DAO:

1. Contributor payouts — pulled from the Pay-Per-Task Scheme and totalled by lane. This is the money that pays members for their tasks, through the framework.
2. Operating costs — everything not tied to one person's task: tools, hosting, a venue, community micro-grants, on-chain fees, a contingency reserve. Each line names the Cashbook expense category it will log under, picked from the same list the Cashbook uses, so plan and actual line up. This money is released by a DAO vote to the DAO Lead or treasurer, against receipts.

The plan then totals both against the seed: total planned = contributor payouts + operating costs, checked against the $3,000, with the buffer left over shown and a plain "within seed?" flag. Because the seed is released monthly across execution, a phasing table lets the DAO spread the plan across the months so each tranche is planned, not guessed.

Keeping the two parts separate matters: they travel different paths (the framework for payouts, a treasury vote for operating costs), and a DAO that blurs them loses the thread of who was paid for work versus what was spent to run things.

Screenshot: the Budget Plan tab (A · contributor payouts by lane · B · operating costs · C · summary vs seed · D · monthly phasing). Source: the DAO Workbook template.

Cashbook

The Cashbook is the only ledger, and it records what actually happened. The Budget Plan is the intent; the Cashbook is the actuals. It mirrors the framework's on-chain records and the DAO's wallets and accounts rather than replacing them. The Bookkeeper keeps it, within about three days of each money movement.

One line = one money movement, on one date. Each line records:

• What and why — a date (one date, never a range), a description with its purpose (no lump sums), a Ref # (the task_id for a payout; FUND-, TRF- or EXP- numbers otherwise), and the lane.
• Which way it moves — the transaction type: Inflow adds to the balance, Outflow subtracts, and Internal transfer moves money between holders (for example treasury → DAO Lead, or USDT → a local bank account) without changing the DAO's balance.
• Who paid and who received — From and To, named exactly, so the Cashbook always knows who is holding the DAO's money.
• How it's classified — an income or expense category, and the funding source the money sits in or is spent from:
  • Seed (Kambria LP) — spent per the Budget Plan, not split.
  • Restricted sponsorship — a partner's ring-fenced program money, spent only on what it was given for, not split.
  • Earned revenue — the DAO's share of revenue after the framework's split.
• What was approved — the XDAO vote that released an operating cost, the Budget Plan line it was spent against, or, for a payout, the deliverable_id in Contributions.
• The amount — in the currency actually paid, with the FX rate actually received for any non-USDT line; the USDT value, in, out, and running balance compute themselves. A fee or conversion loss is its own line, never hidden inside a transfer.
• The evidence — a link to the supporting document in the DAO Drive and its type: an on-chain transaction, a receipt or invoice, a bank or e-wallet screenshot, a payment-confirmation email CC'd to the DAO group email, or a signed agreement. Where no receipt exists (an informal vendor or transport), the line says so and the reason goes in Notes.

An Auto-check column flags any line that is incomplete — a missing category, From/To, FX rate, or document, a duplicate Ref #, or a payout without its task_id — and shows ✓ when the line is clean. Four DF audit columns (audit status, audit note, audited by, resolved date) let the DAO Facilitators record their review on the line itself. A line marked OK is never edited afterwards; a mistake is fixed with a correcting line that names the original.

Below the ledger, five blocks do the checking:

1. Month-end checks — every Status must read OK before the monthly close: no open auto-checks, every line audited, custody matching the balance, contributor payouts equal to the Verified & payable total in Contributions, restricted sponsorship not overspent, and seed spending within the Budget Plan.
2. Custody — who is holding the DAO's money right now (the XDAO treasury, the DAO Lead, any other wallet or account), what each should hold, and the actual month-end balance from a screenshot or the treasury page.
3. By funding source — what came in, went out and remains in each of the three pots.
4. Budget vs actual — spend by expense category against the Budget Plan, so a DAO sees where it is under or over.
5. Income by category — which activities bring money in, separating funding (seed, restricted sponsorship) from what the DAO regenerated.

These rules come from auditing the DEP 2 Cashbooks: the gaps that took the longest to resolve were transfers recorded as spending, lump-sum and date-range lines, unexplained FX differences, and missing receipts. The template now catches each of them at entry.

Screenshot: the Cashbook tab (ledger with Auto-check and DF audit columns · month-end checks · custody). Source: the DAO Workbook template.