Payments

Paying outside addresses, members or another treasury from a treasury, against its own budget.

Payments (community sidebar) is for money that is not a task bounty: paying another community or a contractor for a service, paying a member for something outside any workgroup budget, or moving funds from one of your treasuries to another treasury or a float wallet. You pick the treasury that pays, list the recipients and amounts, and build one transaction that the treasury's signers approve on the signing page, exactly like a payout.

The Payments page

Pay from treasury — the wallet that pays, each listed with the workgroups currently routed to it. If the community has one treasury it is chosen for you; the picker shows the balance of the selected one.
Spending path — shown when the treasury offers more than one right now (see Spending paths); a lock-until treasury before its date shows a warning instead.
Recipients — one row per recipient (see below). Add recipient adds a row, the bin icon removes one. Rows are disabled until a treasury is selected.
Budget period — the month this payment counts against (see Budget period).
The summary card totals the payment, checks it against the treasury's balance and budget, takes an optional Memo (public on-chain text; the form allows 64 characters, shortened to 64 UTF-8 bytes when recorded), and holds Build payment transaction.

Recipients

Each row starts with what kind of recipient it is:

Community member — pick a member; their wallet is paid and their handle is shown on the transaction.
Another treasury — pick one of the community's other treasuries (greyed out while the community has only one). This is a transfer (see Transfers between your treasuries).
Float wallet — pick one of the community's float wallets (greyed out while none are registered). This is also a transfer: it funds a DEX/dApp float and is not charged to a budget.
Any address — paste a Cardano address on the community's network, for a contractor, another community or anyone else.

Then add assets one at a time with Add asset…: pick a token the treasury holds, enter its amount in the token's own units (10 GVTT, 2.5 ADA), and remove a line with the bin icon. Only tokens you add are paid; two rows naming the same address are paid as one output with the sum. Treasury Guild reads what the treasury holds from the chain, so no token needs to be registered.

Move all assets on a recipient row fills every held token as amount lines and builds a drain: one recipient, every UTxO spent, the network fee taken from ADA, and nothing left on the paying treasury. Amounts are a preview until build time (ADA after the fee is what is recorded). Prefer Another treasury when you are closing a wallet so the move stays a transfer and is not charged to a budget; an outside address is ordinary spending of the whole balance. Edit amounts leaves drain mode so you can change or remove those lines again. A drain always pays a single recipient; Add recipient and Add asset… are hidden while it is on.

The build is refused while a row has no recipient, an invalid or wrong-network address, the paying treasury's own address, no amount, a zero or malformed amount, or an amount with more decimals than the token supports; each problem is listed under the summary, naming the row. Exceeds treasury balance means the treasury does not hold enough of that token for the sum of every row. At most 40 recipients fit in one transaction. A drain is refused when the wallet holds nothing, or not enough ADA after the fee to carry its tokens.

Token-only outputs carry a small amount of ADA (about 1.2 to 1.5 ADA), the ledger minimum per output. It is not part of the payment and is not recorded as such. A drain always sends enough ADA with the tokens (the remainder after the fee).

Budget period

Every payment is charged to the paying treasury's own budget, never to a workgroup's: workgroup budgets stay task-based and verifiable task by task on-chain. Set up a budget for a treasury on the Budgets page, where each treasury has its own card next to the workgroups.

Choose the month the payment belongs to; it defaults to the current one. A treasury that budgets by quarter resolves the month to its quarter, and the hint under the field says which period will be charged. The summary shows that period's budget with what is already spent and what would be left after this payment; going over is allowed, but the line turns amber so you notice. A treasury with no budget still records the payment against itself, so history is there once a budget is added.

The period is written into the on-chain record as YYYY-MM or YYYY-Qn, and the Dashboard attributes the spending to it.

Transfers between your treasuries

An output to another of the community's treasuries, or to a float wallet, is a transfer, not spending: it takes no budget period, counts against no budget, and is marked Transfer on the transaction page. Once the chain confirms it, the receiving treasury (or float) is linked without treating the move as income, and the Dashboard's funding flow draws it between the wallets. A payment can mix transfers and other recipients; only the other recipients are charged to the budget. Use Move all assets with Another treasury when you want to empty one wallet into another (for example before you stop using it).

Fund this budget on an applied budget proposal opens this page with such a transfer filled in: the workgroup's treasury as the recipient, the period's voted amounts, and the proposal to cite. A notice at the top says which budget is being funded. Pick the treasury that pays (not the one being funded), edit the amounts if you like, and build; the transfer's on-chain record then cites the budget proposal under g. A voted amount in a token the paying treasury does not hold is listed as a problem until you clear it or pay from another treasury.

Who can build a payment

Build payment transaction is enabled for the selected treasury's base signers; on a clawback treasury's recovery path (from its lock date) for its recovery signers, and then only the recovery signers sign. Community admin alone is not enough. Workgroup leads cannot build payments. Signing still needs the treasury's threshold, so nothing moves on one person's say-so, and your wallet must be on the community's network.

When the community has proposal anchors due, a payment build carries as many as fit alongside its own record (same as a payout); the rest stay due for the next payout, payment or dedicated anchor transaction.

On-chain record

Like a payout, a payment carries a public record under metadata label 190001 so the community's spending can be audited from the chain. It is told apart from a payout by t: "payment" and contains only:

v — the record version (1), src — always "treasury-guild", c — the community's slug,
t — "payment"; a payout has no t and carries p instead,
b — the budget period the spend counts against (YYYY-MM or YYYY-Qn), or empty when every output is a transfer,
k — the list of asset tickers paid, including ADA when explicitly paid,
m — the memo, if one was entered; the form allows 64 characters, and the on-chain text is shortened to 64 UTF-8 bytes (so non-ASCII text can be shorter),
o — for each output (by its position in the transaction), the amounts in the same order as k ("" where the output carries none of that asset), and a flag: 0 for spending, 1 for a transfer to another of the community's treasuries,
g — only when a decision is cited: the number and content hash of each cited proposal, such as the budget proposal that set the budget of the period the spending counts against. A payment charged to a budget that was saved directly cites nothing.

Example, for a transfer of 188 ADA and 50 000 GVTT from the main treasury to another of the community's treasuries, with the memo "Workgroup Budget":

{
  "v": 1,
  "src": "treasury-guild",
  "t": "payment",
  "c": "signius",
  "b": "",
  "k": ["ADA", "GVTT"],
  "m": "Workgroup Budget",
  "o": [[0, ["188", "50000"], 1]]
}

The flag 1 marks the single output as a transfer, and b is empty because nothing is charged to a budget. A payment to a contractor instead carries the period in b and flag 0 on its outputs; a payment mixing both keeps the period and flags each output on its own. Amounts are in display units; the small ADA minimum added to token-only outputs is not included. The recipient is the output's address, which the chain already shows; Treasury Guild does not add personal handles or names automatically. The memo is public and permanent, so leave private information out of it. A short human-readable message (CIP-20, label 674) rides along, naming the community, the date, the number of recipients or transfers and the memo.

The transaction page shows the record decoded from the transaction itself, with member handles and treasury names from Treasury Guild's records beside each output, and the cited decisions linked to their proposals. Expanding On-chain payment metadata there shows the raw record with a what the keys mean legend above it.

While the community decides budgets by vote, a payment is checked against the voted budgets before it is built: depending on the community's setting, a payment that does not fit is built with a warning for the signers, or refused with the reasons. Transfers are never checked. On a co-signer treasury the co-signer signs only a payment that fits, whatever that setting says (see The co-signer check).

The record is complete enough to rebuild the payment from the chain alone. When Treasury Guild finds one at a treasury address that it has no record of, it imports it as a confirmed payment with the same recipients, amounts, budget period and memo; a transfer is imported only when the receiving treasury belongs to this community. See Importing on-chain payouts.

Next: Signing transactions.