﻿I would give every Kiduna DUNA a standard library of executable proposals. Members vote twice a month, and approved proposals automatically change the organization's state, move money, grant authority, establish budgets, or initiate work.
The key principle:
A proposal isn't just a decision. It's an instruction to Kiduna to do something specific.
Your first two types are:
1. Distributions — Pay people or organizations from the treasury.
2. Appointments — Assign or revoke roles and their associated authority.
I'd add several more, covering membership, budgets, missions, agents, alliances, resources, and governance.
One important distinction: West Virginia's DUNA law permits reasonable compensation, reimbursement, and certain purpose-related benefits, but generally prohibits distributing profits to members simply because they're members. Kiduna should therefore classify and validate treasury distributions by purpose.


§36-13-4
Recommended standard proposal types
Type
	What Kiduna executes when approved
	3. Membership
	Admit, suspend, reinstate, or remove members; update membership and voting eligibility.
	4. Budgets
	Establish or modify operating budgets, spending limits, recurring allocations, and expiration dates.
	5. Work Authorization
	Fund Tasks, authorize bounties, establish deliverables and compensation, and create work opportunities members can accept.
	6. Missions & Campaigns
	Create, modify, pause, or close Missions and Campaigns; approve objectives, resources, measurable goals, and completion criteria.
	7. AI Agents
	Deploy, configure, authorize, restrict, or deactivate Guides working for the DUNA. Set their mandates, capabilities, budgets, and permissions.
	8. Resource Allocation
	Allocate KI compute credits, infrastructure, storage, software, datasets, and other organizational resources.
	9. Alliances & Partnerships
	Authorize relationships with other DUNAs, Alliances, institutions, or organizations. Create partnership offers and shared initiatives.
	10. Policies
	Adopt or amend operating policies, compensation formulas, conduct rules, procurement standards, and other enforceable policies.
	11. Governance Rules
	Change voting thresholds, quorum requirements, proposal eligibility, election procedures, delegation rules, and terms of office.
	12. Treasury Management
	Move funds between treasury pools, change reserves, modify wallet permissions, or alter authorized spending controls.
	13. Official Actions
	Approve and publish organizational statements, commitments, endorsements, or other actions taken in the DUNA's name.
	14. Organizational Changes
	Amend the DUNA's purpose or governing principles; initiate restructuring, mergers, or dissolution, with required legal steps.
	Most are executable entirely inside Kiduna. Others can execute the authorized internal change or initiate a workflow but require additional consent, external signatures, or legal filings.
I'd prioritize these for the first release
1
Distributions
Transfer approved treasury funds
2
Roles
Appoint people and update permissions
3
Membership
Update membership status and eligibility
4
Budgets
Establish bounded spending authority
5
Work
Fund Tasks and publish opportunities
6
Missions
Authorize organized work and objectives
7
Agents
Deploy and govern DUNA Guides
8
Policies
Adopt enforceable operating rules
The remaining types can follow, but the underlying engine should support them from the beginning.
How I'd design the proposal system
1. Every proposal is a typed, executable action
No free-form proposals that merely say, "We agree to do X."
A proposal contains a defined change, the authority required, and its exact execution parameters.
For example:
Example proposal
Treasury • Distribution
Pay local school food researchers
Fund the completed research work for Lunchbreakers.
Payment amount
1,500 USDC
Source
Research Budget
Recipient
Approved researcher wallet
Execution
After approval
On passage: validate payment conditions, transfer USDC through authorized treasury controls, and record the transaction.
A policy proposal similarly creates a versioned policy, while an appointment proposal updates the role and associated permissions.
2. Give different proposals different safeguards
I'd establish three execution classes:
Class
	Typical proposals
	Execution
	Routine
	Distributions within established limits, ordinary roles, funded Tasks
	Automatic after approval
	Significant
	Large budgets, agent authority, policy changes, treasury controls
	Higher approval threshold and possible time delay
	Foundational
	Governance changes, removal of administrators, changes of purpose, dissolution
	Special voting and legal procedures
	West Virginia law specifically identifies membership removal, administrator selection, changes to governing principles, disposition of property, dissolution, and organizational purpose as decisions requiring member approval by default, subject to the DUNA's governing principles.

§36-13-20
3. Don't require a vote on every operational decision
This is especially important for a massively multiplayer organization.
A proposal might approve a $10,000 monthly research budget and authorize a Guide or designated member to spend up to $500 per transaction on qualifying research, for six months.
Kiduna can then execute qualifying transactions without holding another organization-wide vote, provided the spending authority has been validly delegated and the limits are enforced.
This is consistent with the distinction already outlined in your Kiduna Tokenomics draft: membership governance approves the action, and the execution layer handles treasury operations.
For Solana, Squads can enforce custody and signer permissions, but the DUNA vote must be connected to an authorized execution mechanism. A passed Kiduna vote alone doesn't grant a wallet the ability to move assets.

Squads Docs
The most important architectural distinction
I'd separate three different things:
Proposals determine what the organization authorizes.
Mandates establish continuing, bounded authority to act without additional votes.
Actions are individual executions, each with a verified result and permanent audit trail.
This allows a DUNA to vote twice a month while its people and agents operate continuously.
Each approved proposal should produce an immutable approval record, execute only the authorized changes, and record success, failure, or required external action. It should never silently substitute a different action if execution fails.
My recommendation: Build the 14-type proposal library, expose the first eight types initially, and make mandates a first-class feature. That gives every DUNA something much more powerful than voting: a practical, democratically controlled operating system for getting things done.
