Contributor Payment Guidelines

 

Manual, task-based payment for qualified deliverables

DEP 2 is run on regeneration handled manually — DAOs earn, track, and reinvest by hand, and only in DEP 4 does contributor payment become automated (Microjob-style per-task payouts). This page is the manual, DEP 2 version of that model: how a DAO can pay a contributor for a specific, budgeted, qualified piece of work, in a way that is transparent, fair, and forward-compatible with DEP 4 automation.

Contributor payment is used where a Working Group's approved budget is deliberately allocated to human-capital / milestone work (most commonly in the KAT Tokenomics DAO, whose regeneration is systemic and indirect rather than revenue-generating).

 

1. When This Page Applies

Use these guidelines whenever a DAO wants to pay a contributor from its seed fund for a defined task or milestone — for example:

• Building or configuring a framework, dashboard, or smart-contract prototype (KAT Tokenomics DAO)
• Producing a specialized deliverable that needs dedicated, skilled effort (research, design, development, writing, translation, structured documentation)
• Any WG task where the Master Plan / WG proposal has explicitly reserved budget for contributor payouts

If the contribution is general participation, governance, voting, casual help, or community activity, it is recognized with KAT, not paid. See Section 4.

 

2. What Contributor Payment Is — and Is Not

The DAO Funding Guide states there are no salary payments and no financial rewards to members. Contributor payment does not break that rule, because it is neither.

Contributor payment IS	Contributor payment is NOT
Payment for a specific, defined deliverable	A salary, wage, or retainer
Budgeted in advance inside an approved WG envelope	A general "reward" for being a member
Released only after the deliverable is qualified	A payment for effort, attendance, or time
Tied to clear qualification criteria	Discretionary or automatic
Recorded as a "Contributor payout" in the Cashbook	A transfer outside the DAO's tracked budget

In short: you are paying for a result that was scoped, priced, and approved beforehand — the same logic DEP 4 automates. It complements KAT; it never replaces it.

 

3. Where the Money Comes From

Contributor payments are funded only from a Working Group's approved budget envelope, within the DAO's $3,000 USDT seed fund — no new or separate money is created.

• The Master Plan must allocate an envelope to the relevant WG.
• The WG proposal must state that part (or all) of that envelope is for contributor payouts, with the tasks, deliverables, and rates listed (see the Task & Payment Table, Section 5).
• Every payout is logged in the DAO Cashbook under the expense category "Contributor payouts."

No task can be paid before the Master Plan and the funding WG proposal are approved.

 

4. The Pay-Per-Task Model (aligned with DEP 4)

DEP 4 pays contributors per task at defined rates. DEP 2 does the same thing by hand, in four steps:

1. Define the task — a clear unit of work with one deliverable.
2. Set the qualification criteria — what "done and acceptable" means.
3. Set the rate — a fixed amount (in USDT) agreed in the WG proposal.
4. Pay on qualification — release payment only after the deliverable passes review.

A task may be a one-off (e.g. "design the KAT dashboard mockup") or a milestone in a larger deliverable (e.g. "Milestone 2 of 4 — testnet contract deployed"). Milestones are just tasks with their own deliverable, criteria, and rate.

Contributor payment vs KAT — quick guide

	Contributor Payment	KAT Recognition
Nature	Financial (USDT)	Symbolic / non-financial
Trigger	Qualified, budgeted deliverable	Any recognized contribution
Source	Approved WG envelope	KAT framework (post-completion)
When assigned	After the deliverable is qualified	After proposal / activity completion
Can they co-exist?	Yes — a paid task can also earn KAT	Yes

5. The Task & Payment Table (defined in the WG proposal)

Each WG that intends to pay contributors includes a Task & Payment Table in its proposal. This is the "menu" of payable work and its prices — approved by the DAO before any assignment.

Task ID	Task / Deliverable	Qualification criteria	Rate (USDT)	Funding source
KTD-FA-01	Draft KAT Framework application doc	Complete, follows template, reviewed by WG Lead	60	FA WG envelope
KTD-DB-02	Dashboard MVP mockup (Figma)	All required screens; matches agreed scope	90	Dashboard WG envelope
KTD-DB-03	Testnet smart contract — deployed & verified	Deploys on testnet; passes agreed test cases	120	Dashboard WG envelope

(Full KTD samples are provided separately — see the KTD Contributor Payment Samples.)

Rules for the table:

• Rates are fixed and public before assignment — same task, same rate for everyone.
• Total of all rates must stay within the WG envelope.
• Add a Notes column for dependencies or evidence expectations where useful.

6. Task Assignment (who does what, by when)

Once the Task & Payment Table is approved, the WG maintains a Task Assignment & Payment Tracker (a tab in the DAO Tracking Spreadsheet). Every payable task gets a row:

Column	What goes in it
Task ID	From the Task & Payment Table
Task / Deliverable	Short description of the unit of work
Qualification criteria	Copied from the Task & Payment Table
Rate (USDT)	Agreed amount
Assignee	DAO member who took/was assigned the task
Assigned date	When it was taken/assigned
Due date	Agreed deadline
Submission link	Link to the deliverable + evidence (in DAO Drive)
WG Lead qualified	✔ / date — first-line review
DAO Lead approved	✔ / date — budget & scope confirmed
DF released	✔ / date — compliance check & payment released
Payment date / Tx ref	On-chain tx link or transfer reference
Status	Assigned → Submitted → Qualified → Paid (or Needs revision)

• Tasks can be self-claimed (open to DAO members) or directly assigned by the WG Lead — the DAO decides which.
• One person should not hold more open tasks than they can deliver by the due dates.

7. The Payment Process (qualification chain)

Payment moves through a simple four-role chain. Separation of duties is the point: the person who does the work is not the person who qualifies, approves, or releases it.

Submit deliverable → Qualify → Approve → Release → Pay

DAO member → WG Lead → DAO Lead → DF (DAO Facilitator)

Step 1 — Submit (DAO member / contributor) The contributor completes the task and submits the deliverable + evidence (files, links, screenshots) into the DAO Drive, and pastes the link into the tracker row. Status → Submitted.

Step 2 — Qualify (WG Lead) The WG Lead checks the deliverable against the qualification criteria. Outcome:

• Qualified → mark ✔, pass to DAO Lead.
• Needs revision → note what's missing; contributor revises and resubmits. (A WG Lead cannot qualify their own task — a DAO Lead or another WG Lead qualifies it instead.)

Step 3 — Approve (DAO Lead) The DAO Lead confirms the payout is within the approved envelope, matches the approved rate, and is in scope. Marks ✔.

Step 4 — Release (DF — DAO Facilitator) The DF runs a final compliance check (budget remaining, evidence complete, no conflict of interest) and releases / co-signs the payment from the DAO treasury. Marks ✔ with the payment reference.

Only after all four ✔ marks is a task Paid.

8. Making & Recording the Payment

• Currency & method. Pay in USDT from the DAO XDAO treasury (multisig). Where a contributor needs fiat, record the USDT-equivalent and note the rate used (consistent with the Revenue Tracking & Audit guide).
• Cashbook. Log every payout as one line under expense category "Contributor payouts" — date, Task ID as the Ref #, amount, USDT value, supporting-doc link, input by.
• CC the DAO group email. Payment confirmations are issued on behalf of the DAO. CC your DAO group email (e.g. [email protected]) so every member has visibility and there is an auditable trail. Paste the email/thread link into the tracker and Cashbook.
• Evidence. Keep the deliverable, review notes, and on-chain/transfer screenshot in the DAO Drive folder.

9. Qualification Criteria — what makes a deliverable payable

A deliverable is qualified (and therefore payable) when:

✔ It matches the task definition in the Task & Payment Table. 

✔ It meets every qualification criterion listed for that task. 

✔ Evidence is complete and stored in the DAO Drive. 

✔ It is delivered by the due date (or an agreed, documented extension). 

✔ It is the contributor's own work (or properly attributed collaboration).

If any item fails, the task is Needs revision — not paid — until resubmitted and qualified.

10. Principles & Safeguards

• Budget-bound. Total payouts never exceed the WG envelope. When the envelope is spent, no further payouts until re-approved.
• Separation of duties. Do, qualify, approve, and release are four different people. No one signs off on their own payment.
• Fair & consistent rates. Same task = same rate for everyone; rates are public in the Task & Payment Table.
• No double-paying. A deliverable is paid once. It may also earn KAT, but not a second payout.
• Payment ≠ KAT. Being paid does not reduce KAT recognition, and earning KAT does not create a payment claim.
• Transparency. The Task & Payment Table, the tracker, and the Cashbook are visible to all DAO members, who can co-audit and raise questions in the DAO Discord channel.
• Conflict of interest. Anyone with a personal stake in a payout steps out of qualifying, approving, or releasing it.

11. Roles & Responsibilities

Role	Responsibility in contributor payment
Contributor (DAO member)	Takes the task, delivers on time, submits deliverable + evidence
WG Lead	Defines tasks/rates in the proposal; qualifies deliverables against criteria
DAO Lead	Confirms payout is within envelope, scope, and approved rate
DF (DAO Facilitator)	Final compliance check; releases/co-signs payment; supports accuracy
Cashbook Keeper	Records each payout in the Cashbook with supporting-doc link
All members	Co-audit the tracker and Cashbook; flag issues

12. Template and Sample

Contributor Payment Samples

 

13. Common Situations

• A task takes longer than expected. Agree a documented extension before the due date; the rate does not change.
• The deliverable is partially done. Pay only if the WG defined a milestone for that partial scope; otherwise it is Needs revision.
• Two people collaborated on one task. Split the fixed rate as agreed and recorded in the tracker before payment; the total does not increase.
• The WG Lead did the task. Another WG Lead or the DAO Lead qualifies it — never self-qualification.
• Envelope is nearly empty. Do not assign new payable tasks until budget is re-approved; use KAT recognition in the meantime.

14. Forward Compatibility with DEP 4

Keeping clean records now means your DEP 2 data carries straight into DEP 4 automation:

• The Task & Payment Table ≈ DEP 4 Microjob task definitions & rates.
• The Task Assignment & Payment Tracker ≈ DEP 4 assignment + payout ledger.
• The qualification chain (member → WG Lead → DAO Lead → DF) ≈ DEP 4's submit → qualify → pay flow, done manually.

Teams that run this cleanly in DEP 2 move into DEP 4's automated contributor payment with minimal friction.

Summary

Contributor payment in DEP 2 is:

✔ Task-based, not salary-based 

✔ Budgeted inside an approved WG envelope 

✔ Priced in advance in a public Task & Payment Table 

✔ Paid only on qualification, through a four-role chain (member → WG Lead → DAO Lead → DF) 

✔ Recorded in the Cashbook as "Contributor payouts," CC'd to the DAO group email 

✔ Complementary to KAT, never a replacement 

✔ Forward-compatible with DEP 4 automation

Questions? Ask in your DAO Discord channel or [email protected]. You're never alone.