pool-vault is run by whoever holds its Manager role: fee, oracle and
accepted-token changes are single-key decisions. That suits most operator-run funds.
For cooperative- or community-owned pools, such as a farming cooperative’s fund or a
community investment group, the vault can instead be run by its share holders.
Governance mode is Stellar-only.
Opting in
Governance mode is chosen at deployment and is one-way:multi-token-factory::deploy_governed_pool_vault, which uses
pool-vault::initialize_governed. An existing vault’s Manager can also call
enable_governance(config) once. Vaults that never opt in behave exactly as before.
What changes in governance mode
These actions can then only happen through a passed proposal:
Calling the direct Manager setters, or
upgrade, reverts. Direct mint of pool shares
is disabled too, so no single key can create voting power.
Lifecycle
- Propose:
propose(proposer, action). The proposer must hold at leastproposal_threshold_bpsof supply. The quorum is fixed at creation from the total supply at that moment. - Vote:
vote(voter, id, support). Each vote is weighted by the voter’s share balance. Those shares are locked until voting ends: they can’t be transferred, burned or withdrawn, so the same shares can’t vote twice from another address. A voter can vote once per proposal. - Outcome: after
voting_period, a proposal passes iffor > againstandfor + against ≥ quorum. - Timelock: a passed proposal is
Queuedfortimelockseconds. Holders who disagree can withdraw during this window. - Execute: anyone calls
execute(id).
cancel_proposal while voting is open. proposal_state(id) returns
Active | Defeated | Queued | Executable | Executed | Cancelled.
Operational roles stay with their holders in governance mode: pausing (
Pauser), asset
status and the identity verifier (Manager). If your community wants those governed too,
assign the roles to a multisig held by elected stewards.