Actually Smart ContractsalphaTemplates

Templates / Treasury and governance

Treasury: a budget that pays only for what it exists for

A treasury wallet with a judiciary signer. Code enforces the caps and the payee list; the jury checks that each payment is for the purpose the treasury was set up for, judged from the proposal and its evidence.

Why it exists

Team and DAO treasuries are guarded by signers who approve what's put in front of them. Caps help, but a payment can sit under every cap and still be for the wrong thing: a vendor that's really an insider, a grant that funds something else.

The treasury template keeps the limits in code and adds the one check code can't do: is this payment for what the treasury is for?

DAOs

Spending under a budget the community set, with purpose checked on every payment.

Teams and foundations

A shared wallet where no single signer can pay outside the purpose.

How it works

Set up

Fill in the purpose, the asset, the monthly budget, the largest single payment and the approved payees. The policy hash is pinned in the signer.

Propose

A member proposes a payment in Squads with a description and evidence.

Check the code rules

Programs, the per-payment cap, the 30-day window across every payment, the payee list.

Ask the jury

One question: is this payment for the purpose, as the proposal and its evidence describe? The proposal text is untrusted material.

Sign or refuse

The signer votes only as the ruling says, and never for a payment that breaks a rule.

What you fill in

The fields of treasury. The whole document is hashed, and that hash is what everyone signs and the signer on chain carries.

FieldWhat it holds
purposeWhat the treasury exists for, in plain words
monthlyThe most that can leave in any 30 days
perTransactionThe largest single payment
payeesApproved recipients
minTimeLockSecondsSquads time lock, one day by default

What code checks, and what the jury decides

Code: the same answer on every computer

  • Only token and system programs
  • At most perTransaction per payment
  • At most monthly in any 30 days, counting every payment
  • Only approved payees
  • Config changes go to the jury

Jury: the questions only judgment can answer

  • Is this payment for the purpose the treasury exists for, as the proposal and its evidence describe?

A rule violation is final: the signer refuses it whatever the jury says.

Attacks, and what stops them

AttackDefenseStatus
A payment split to stay under the capThe 30-day window counts every paymentTested
A payee that isn't on the listRefused by codeTested
A description that misstates the paymentThe jury judges the decoded transaction; the text is untrustedBuilt
Removing the signer or lowering the thresholdAlways refused, whatever the policy saysTested

Every case the signer builds labels the parties' own text as untrusted and never follows instructions in it. See Security for the threat model behind all templates.

Example: A grants treasury

policyFromTemplate('treasury', {
  purpose: 'developer grants for the Solana agent ecosystem',
  asset: 'SOL', monthly: 500_000_000_000, perTransaction: 50_000_000_000,
  payees: ['GranteeA...', 'GranteeB...'],
})

The prompt

Paste this into any capable AI. It asks you about your case one group at a time, writes the treasury for it, explains who gets what in each outcome, points out risks in your terms, and ends with the harness call that checks the result. It never asks for keys: each party signs with its own, outside the conversation.

templates/prompts/treasury.md
You are helping me set up a Verafy Treasury policy (VIP-0011): a wallet with a judiciary signer that pays approved payees under a per-payment cap and a 30-day budget, with a Verafy jury checking that each payment is for the treasury's stated purpose.

Rules for you, the AI:
- Ask me the questions below one group at a time. Don't invent facts about my deal; if I don't know an answer, propose a sensible default and say it is a default.
- Amounts are whole base units as strings (1 SOL = "1000000000"). Times are unix seconds.
- Write every term, outcome and article so a stranger could decide from evidence alone whether it was met. No "reasonable", "high quality" or "timely" without a number or a test.
- Name the evidence that proves each thing, and prefer evidence that can be pinned by hash (a file, a commit, a transaction signature, an export).
- Never ask for or handle private keys. Each party signs with its own key, outside this conversation.
- When you're done, output: (1) the JSON, (2) a plain-English summary of who gets what in each outcome, (3) the risks you see in my terms, and (4) the harness call that checks it.

Ask me:
1. The purpose. What this treasury exists to pay for, in one or two sentences a jury can test a payment against. Say what it is not for, too.
2. The asset, the most that can leave in any 30 days, and the largest single payment.
3. The approved payees, and how a new payee gets added (a config change the jury reviews).
4. The Squads time lock (one day by default).

Then produce the call policyFromTemplate('treasury', { purpose, asset, monthly, perTransaction, payees, minTimeLockSeconds }), the resulting jury question, and three example payments: one that passes, one the code refuses, and one only the jury would refuse, with the reason.

Run it

In code

policyFromTemplate('treasury', params)
checkRules(policy, effectsOf(tx), { now, history })
FileWhat it is
packages/core/src/policy.jsThe rules engine and every template
packages/core/src/judiciary.jsCase contracts for the signer

Status, honestly

Measured
  • The judiciary signer program passed 30 of 30 checks on a local validator against the Squads v4 program dumped from mainnet
Not done yet
  • The signer program isn't on devnet yet
ProposalStatus
VIP-0011: Policies, and Covenant Launch: rules a wallet cannot breakShipped (v0.0.4-alpha)
VIP-0010: Judiciary Signer: a multisig member that votes only as a jury rulesShipped (v0.0.4-alpha); devnet deploy open

Other templates