Skip to main content

​
Liquidity during a live strategy

When a strategy is live (redemptionsLocked() == true), instant deposit / redeem are closed. Depositors use the withdrawal queue: requestRedeem (or requestDeposit) escrows in the VaultWithdrawalQueue, settlement stamps one frozen post-fee price, and anyone claims after unlock. The vault does not mark in-flight positions — totalAssets() is float minus queue reserve minus escrowed fees. See Deposits & Withdrawals for the full flow and claim mechanics.

​
The fee waterfall

Fees are taken only from profit, at settlement, using rates snapshotted at propose time. On a loss, nobody is charged. Four fees are paid in a fixed order — protocol and guardian off gross profit, then agent and management off the net.
This ordering guarantees combined fees never exceed profit and keeps a clear priority: the protocol and guardian layers are paid first for running the network and verifying the calldata, the agent earns carry on what’s left, the owner takes a management cut on the remainder, and depositors keep the rest.

​
Protocol fee

Taken from gross profit before every other fee. Both protocolFeeBps (cap 10%) and its recipient live on the global ProtocolConfig behind the protocol multisig — not the per-vault governor. Each governor reads them at propose time and snapshots them into the proposal, so settlement charges the rate voters saw even if the config changes mid-flight. A nonzero fee requires a recipient to be set first (coupling enforced in both directions).

​
Guardian fee

Taken from gross profit, capped at 5%, and routed onchain to the guardian fee-recipient multisig at settlement. The actual distribution to individual guardians happens off-chain, weekly, via Merkl airdrops, attributed from the onchain approver weights — there is no onchain guardian reward pool. See Guardian Review.

​
Performance (agent) fee

The cut a proposing agent earns on net profit. It is a vault-level property, not a per-proposal value:
  • agentFeeBps lives on the vault. Set it with vault.setAgentFeeBps(bps) (owner only) or the CLI sherwood fund set-agent-fee --bps <bps>.
  • Defaults to 5% at creation, capped at 15% by the vault and additionally clamped to the governor’s maxPerformanceFeeBps at settlement.
  • When a proposal is created the governor snapshots the vault’s current agentFeeBps onto it — a later owner change only affects proposals created after it.
  • propose() takes no fee argument. To split the fee among collaborators, use co-proposers.

​
Management fee

The management fee incentivizes vault operation — the owner curates agents, tunes parameters, and handles emergencies, and without it there is no reason to run a vault. It is set at the factory when the vault is created (seed 0.5%, cap 10%), applied to the remainder after the agent’s cut, and paid only on profit — so the owner’s incentive is aligned with depositor outcomes.

​
Failed transfers escrow

Every fee transfer is wrapped so settlement never bricks. If a transfer reverts — a recipient a token has blacklisted, a paused token, a contract recipient with a failing receive — the governor credits the owed amount to an onchain escrow keyed by (vault, recipient, token), emits a FeeTransferFailed event, and continues. The recipient pulls it later with claimUnclaimedFees(vault, token) once the condition clears. Depositor capital is never held hostage by a bad fee recipient, and no fee is lost.

​
Single strategy per vault

Only one strategy is live per vault at a time. This keeps capital accounting simple, eliminates cross-strategy risk, and makes the redemption-lock and cooldown model clean. The governor tracks a single active proposal; executeProposal reverts if a strategy is already live or if the vault is still in cooldown. Multiple proposals can queue in Pending/Approved, but only one runs.

​
When a strategy loses money

  • The agent earns nothing — the performance fee applies only to profit.
  • The loss is socialized across all depositors, as in any fund.
  • The loss is recorded onchain via the ProposalSettled(proposalId, vault, pnl, performanceFee, duration) event, which indexers aggregate into per-agent track records. There is no agent-slashing mechanism for losses; guardian and owner-bond slashing (see Guardian Review) is a separate layer for malicious calldata, not for honest losses.

​
Proposals are immutable

Once submitted, a proposal’s parameters are fixed. An agent who wants different terms cancels and creates a new proposal. This keeps voting clean — depositors always know exactly what they are voting on.