Governance & Proposals
Every value-changing action — mint, burn, transfer, group change, and fiat↔CBDC conversion — is a proposal against an account's x/group decision policy. Nobody can act unilaterally; a proposal must reach its account's threshold to execute.
Creating a proposal
Proposals are created from purpose-built flows rather than one generic form:
| Flow | Route | Endpoint |
|---|---|---|
| Mint | /mint | POST /multisigs/:id/proposals/mint |
| Burn | /burn | POST /multisigs/:id/proposals/burn |
| Transfer / Send | /send | POST /multisigs/:id/proposals/transfer |
| Group change | /multisigs/$id/group | POST /multisigs/:id/proposals/group-changes |
| Convert (disbursement/redemption) | /convert | POST /organizations/:id/disbursement-request · redemption-request |
Each flow ends in a review dialog that states what will happen and how many signatures are still needed, including an instant-execute notice when the proposer's own weight already meets the threshold.
On submit the API atomically creates the proposal and casts the proposer's YES vote, using EXEC_TRY so it executes the instant the threshold is met — there is no separate "execute" click.
Voting & My Tasks
Other members act on proposals in two places:
- My Tasks (
/my-tasks) — a personal queue of proposals still waiting on your vote (where your recorded vote is null), sorted by least time remaining. - Operation detail (
/operations/$operationId) — the full view of a single proposal: transaction details, the M-of-N vote breakdown, lifecycle, and receipts. Sign/Reject actions appear when the proposal is live (SUBMITTED), you're a member, and it isn't proposer-restricted.
My Tasks is strictly personal — only proposals where your vote is still null. "All caught up" when nothing is waiting on you.
Operation detail for a chain proposal: parameters, the weighted vote breakdown (proposer auto-YES), and the lifecycle timeline.
Each vote is cast on-chain with EXEC_TRY.
Operations: chain vs. admin
The Operations read model (and the unified Activity Log) covers two kinds of action, distinguished by OperationKind:
- CHAIN operations — governed proposals that hit the chain (mint, burn, transfer, group changes, conversions). These have votes and a proposal lifecycle.
- ADMIN operations — off-chain administrative actions recorded for audit but not voted (whitelist add/remove, exchange-address set, freeze/unfreeze, user invited/role-changed/deactivated, chain-RPC updated, account created). These render as read-only detail with a link to the surface that produced them.
Proposal lifecycle
Statuses mirror the chain ProposalStatus enum: SUBMITTED, ACCEPTED, REJECTED, ABORTED, WITHDRAWN. Votes use VoteOption (YES, NO, ABSTAIN, NO_WITH_VETO).
What's stored where
Proposals and votes live entirely on-chain; the platform queries them live. Human-readable metadata (title, the platform user id of the creator) is stored in the on-chain proposal's metadata field, and admin (non-chain) operations are persisted in the activity-log audit table.