Skip to main content
The vault owner proposes a strategy, the vault’s depositors get an optimistic veto, staked guardians review and underwrite the exact calldata, and anyone executes the mandate within the window depositors already approved. Profit earns the agent carry; loss earns nothing. One-liner: Owners propose. Depositors veto. Guardians underwrite. Anyone executes and settles. Per-vault governor. Each vault has its own governor, a BeaconProxy the factory deploys at creation and resolves with factory.governorOf(vault). A proposal targets that one vault, and only its depositors vote. Every governor shares one implementation through GovernorBeacon, so there is no protocol-wide governor.
Launch posture (private beta). SyndicateFactory.ownerOnlyProposals is on: only vault.owner() can call propose, and it must also be a registered agent of the vault. Co-proposers are refused (CollaborationDisabled), so every proposal opens directly in Pending. depositsRestricted is also on, so every vault is whitelist-only whatever its openDeposits flag. Both flags are factory-owner setters and will be relaxed for general access.

Optimistic governance

A proposal passes by default unless enough depositors vote against it. Depositors act only when they disagree; silence is consent.
  • Only Against votes carry weight. For and Abstain are recorded but never counted.
  • The veto bar is max(1, votableSupply × vetoThresholdBps / 10_000). A proposal is Rejected at voteEnd when votesAgainst reaches it. When votableSupply is zero the veto check is skipped, so an empty vault cannot auto-reject.
  • There is no participation quorum on approval.
This works because the exact onchain calls are committed at propose time: depositors inspect calldata, not a description, and guardians are the adversarial second check.

Electorate and timing

Buying shares after a proposal opens grants no power on it, and the one-second gap plus the two-checkpoint minimum removes same-block and flash-loan weight.

Owner veto

The vault owner can reject a proposal with vetoProposal(proposalId) only while it is Pending (ProposalNotCancellable otherwise). Once voting ends and the proposal enters GuardianReview, the only way to block it is the guardian block quorum.
Depositors cannot call vetoProposal; it reverts NotVaultOwner. Depositors block a proposal by casting Against votes during the voting window.

The flow

1

The owner proposes

The proposal commits the full strategy: the opening calls, the closing calls, per-call caps, a RiskEnvelope (maxCapital, maxDrawdownBps) and a strategyDuration. The performance fee is not chosen here; it is the vault’s agentFeeBps, clamped to the governor’s maxPerformanceFeeBps.At propose the governor prices the calls into requiredCoverage, checks the covered-TVL cap and the 60-day horizon, and pulls the proposer bond into ProposerBondEscrow. From this moment the vault’s instant deposit and redeem paths are closed (openProposalCount() != 0), see Deposits & Withdrawals.
2

Depositors vote

votingPeriod (24 h by default; owner-set, 30 min minimum on 4663). Weight is vault shares at the snapshot. Only Against counts.
3

Guardians review and underwrite

reviewPeriod (30 min on 4663; protocol-set). Staked guardians inspect the committed calldata and vote Approve with a WOOD lock, or Block. A block quorum rejects the proposal and slashes its approvers; otherwise it is Approved. See Guardian Review.
4

Anyone executes

Within executionWindow (24 h), executeProposal(proposalId) replays the opening calls through vault.executeGovernorBatch. Capital is scaled to the coverage guardians actually booked. Nothing new enters at execution.
5

The strategy settles

The proposer can settle one hour after execute; anyone can settle once strategyDuration has elapsed. The closing calls run, the management fee and (above the high-water mark) the performance fee are charged and split, the queue price is stamped and ProposalSettled is emitted. See Execution & Settlement.
6

Cooldown and bond release

Every terminal transition stamps cooldownEndsAt = now + cooldownPeriod; the next propose waits for it (CooldownNotElapsed). Instant deposits and redemptions re-open as soon as no proposal is open. The proposer bond is released by the permissionless reclaimProposerBond; a settled proposal waits out the challenge window first.

What a proposal contains

  • executeCalls / settlementCalls are read back with getExecuteCalls / getSettlementCalls. Every target must be the vault asset (transfer and approve shapes only) or a strategy registered on StrategyFactory, else NotARegisteredStrategy(target).
  • maxCapital must fit inside totalAssets() × maxCapitalBps / 10_000, checked at propose (MaxCapitalExceedsCeiling) and again at execute against live TVL (MaxCapitalCeilingRegressed).
  • maxDrawdownBps sets the settle price floor: settlement reverts SettlePriceBelowFloor if price per share falls below ppsAtExecute × (10_000 − min(maxDrawdownBps, 9_000)) / 10_000.
  • Fee snapshot. The performance-fee rate and both ProtocolConfig splits are snapshotted at propose, so a change after the vote cannot alter what voters approved.
  • Strategies do not report a value. totalAssets() is vault float minus the queue reserve minus escrowed fees.
The calls are the vote. executeProposal(proposalId) takes only the id and replays what was approved. The metadataURI explains why; the calls are what.

Who controls what

There is no onchain timelock on governor parameters; the freeze while a proposal is open plus the hard bounds are the protection, and the owner is expected to be a multisig.

Governor parameters

Launch values are the factory defaults every new governor starts with. Bounds are enforced by GovernorParameters.
Recommended seeds for a new vault. Right after createSyndicate and before the first propose, set setTier2CallCapBps(200) and setMaxCapitalBps(8000) on the governor and setMinBufferBps(500) on the vault. The governor defaults leave both caps inert, and minBufferBps must never be raised while a proposal is open: the post-batch buffer check would make the committed settlement calls revert.

Proposer, agents and depositors

Proposing. The caller must be a registered agent of the vault (registerAgent, up to 32 per vault) and, while ownerOnlyProposals is on, the vault owner. The vault’s owner stake must be live (OwnerBondNotLive at propose and again at execute), the vault must have no open proposal (VaultHasOpenProposal), and the cooldown must have elapsed. Depositing. deposit / mint check the receiver against the vault’s depositor whitelist (NotApprovedDepositor) while depositsRestricted is on, and revert DepositsLocked while any proposal is open. Depositors need no WOOD and no identity. Every settlement emits ProposalSettled with realized P&L, so an agent’s record is verifiable onchain before anyone votes on its next proposal.

Proposal states

ProposalState, in enum order: Draft, Pending, GuardianReview, Approved, Rejected, Expired, Executed, Settled, Cancelled. stateOf(proposalId) is a true view: it reports Approved, Rejected or Expired as soon as the clock makes them determinable. resolveProposalState(proposalId) is a permissionless flush that persists a lazy terminal transition.

Who can end a proposal early

Every early exit, and every Rejected or Expired transition, runs _decOpen: the open count drops, the cooldown is stamped, and any registered guardian review is cancelled. None of them stamps a queue price, so a queued redeem tagged to that proposal must be cancelled by its owner (see Deposits & Withdrawals). See Guardian Review for the Pending → GuardianReview → Approved / Rejected gate and Execution & Settlement for the post-approval path.