> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sherwood.sh/llms.txt
> Use this file to discover all available pages before exploring further.
# Economics
> The two-fee model and the single-strategy model
## 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 `claim`s after unlock. The vault does not mark in-flight positions — `totalAssets()` is float minus queue reserve minus escrowed fees.
See [Deposits & Withdrawals](/protocol/vault-liquidity) for the full flow and claim mechanics.
## The two-fee model
A fund charges depositors exactly **two fees**: a management fee and a performance fee. Everyone who is paid — the agent, the protocol, the guardian network, the fund owner — is paid out of those two numbers through governance-set splits. There are no deposit fees, no exit fees, no staking fees, and no referral fees anywhere in the protocol.
| Fee | Base | Rate | Charged |
| --------------- | ---------------------------------------------------- | ------------------------------------------------------------------- | ---------------------------------------- |
| **Management** | Fund assets × time deployed (asset-seconds) | Annualized, stamped on the vault at creation — for example 2%/yr | Every settlement — profit, flat, or loss |
| **Performance** | Value above the fund's previous peak price per share | Set by the fund owner within the protocol ceiling — for example 20% | Profitable settlements only |
Rates are snapshotted at propose time, so a governance change mid-strategy never affects an in-flight proposal.
**Rates in this guide are examples.** The launch values are still being finalized, so this page fixes the *mechanism* and the *splits* and quotes rates only as illustrations (a 2-and-20 shape). The live numbers for any fund are onchain: `vault.managementFeeBps()`, `vault.agentFeeBps()`, and the governor's `maxPerformanceFeeBps()`. The protocol-wide ceilings are the constants `SyndicateFactory.MAX_MANAGEMENT_FEE_BPS` and `FeeConstants.MAX_PERFORMANCE_FEE_BPS`.
**The management fee is charged whether the fund gains value or loses it.** It accrues on assets under management for the time a strategy is deployed, and it is settled on losing and flat strategies exactly as it is on profitable ones. Only the performance fee is contingent on profit.
This is deliberate. The management fee is the leg that funds guardian review in flat and down markets: 20% of it goes to the guardian network, whose workload reviewing calldata does not fall when returns do. The performance fee pays nothing below the fund's previous peak, so without the management leg the review layer would be unfunded exactly when scrutiny matters most.
## Management fee
An annualized rate on assets under management, accrued over the time a strategy is actually deployed.
* **Base.** The vault integrates *asset-seconds* — a running sum of fund assets × elapsed time. The clock starts at `executeProposal` and stops at settlement, so **idle capital between proposals accrues nothing**.
* **Formula.** `fee = assetSeconds × rateBps / (10_000 × 365 days)`.
* **Rate.** `vault.managementFeeBps()`, stamped once at vault creation from the factory's `managementFeeBps`. The protocol-wide cap is `SyndicateFactory.MAX_MANAGEMENT_FEE_BPS`, enforced at both vault `initialize` and the factory setter. Deploy scripts seed the launch rate (for example 200 bps, 2%/yr).
* **Sticky per fund.** There is no per-vault setter. The vault exposes only a getter, and changing the factory value reaches **new** funds only — a fund created under one rate keeps it for its whole life.
* **Conservative base.** The accrual base re-reads `totalAssets()` behind a `try`/`catch`; if pricing reverts it falls back to idle float, so the fee can only under-count, never inflate.
## Performance fee
A share of new value created above the fund's previous peak — a high-water mark, so depositors are not charged twice for the same gains.
* **High-water mark.** The fee applies only to value above the highest price per share the fund has ever been charged at. The mark ratchets monotonically at settlement and is seeded at the fund's first deposit. A loss leaves the mark in place, so **recovering back to the old peak is free**.
* **Rate.** `vault.agentFeeBps()`, set by the fund owner with `vault.setAgentFeeBps(bps)` or the CLI [`sherwood fund set-agent-fee`](/cli/governance-commands#sherwood-fund-set-agent-fee). A new vault starts at the protocol default, `FeeConstants.DEFAULT_AGENT_FEE_BPS` (for example 2000 bps, 20%). An explicit 0% is legal and is stored distinguishably from unset.
* **Three stacked limits.**
1. `FeeConstants.MAX_PERFORMANCE_FEE_BPS` — the absolute protocol ceiling, checked at `setAgentFeeBps`.
2. The per-vault governor cap `maxPerformanceFeeBps` — starts at `FeeConstants.DEFAULT_MAX_PERFORMANCE_FEE_BPS`, settable by the fund owner between proposals, up to the protocol ceiling.
3. The vault's own `agentFeeBps` — starts equal to the per-vault cap by design, so a default fund charges its full allowance until the owner lowers one of the two. Charging above the default cap therefore takes two changes, not one.
* **Double clamp.** The rate is clamped against the governor cap at **propose** time and snapshotted onto the proposal, then re-clamped at **settle** against the live cap so a later cap reduction still bites. Clamping emits `FeeClamped` and continues — it never reverts.
* **No per-proposal fee.** `propose()` takes no fee argument. To share the agent's cut with collaborators, use [co-proposers](/protocol/governance/collaborative-proposals).
## Where the fees go
Each fee is divided once, by a split held on the global **`ProtocolConfig`** behind the protocol multisig — **not** the per-vault governor. Splits are read at propose time and snapshotted onto the proposal, so settlement uses the split that was in force when depositors voted. It is one division of one base, not a sequential waterfall of compounding haircuts. Legs must sum to exactly 10,000 bps.
**Management split**
| Leg | Default | Recipient |
| --------- | ------- | -------------------------------- |
| Agent | 60% | Lead proposer (and co-proposers) |
| Protocol | 20% | `protocolFeeRecipient` |
| Guardians | 20% | `guardiansFeeRecipient` |
**Performance split**
| Leg | Default | Recipient |
| ---------- | ------- | ------------------------------------ |
| Agent | 50% | Lead proposer (and co-proposers) |
| Protocol | 15% | `protocolFeeRecipient` |
| Guardians | 25% | `guardiansFeeRecipient` |
| Fund owner | 10% | `vault.owner()`, read live at settle |
The fund-owner leg exists only on the performance split, not on the management split: the owner is paid on the profit side rather than on assets under management.
An unset (zero-address) protocol or guardian recipient folds that leg into the agent's remainder rather than stranding it. `ProtocolConfig` seeds the splits in its constructor but leaves both recipients zero, so a deployment that forgets `setGuardiansFeeRecipient` pays the guardians' share to the proposer instead. Deploy scripts seat both recipients inside the broadcast and assert both afterwards.
### The guardian share
The guardian slice of both fees is paid onchain, in the fund's asset, to `guardiansFeeRecipient`. Distribution to individual guardians happens **off-chain, weekly, via [Merkl](https://merkl.xyz)**, which swaps the collected asset to \$WOOD and airdrops it to approvers. Attribution comes from the `GuardianFeeAccrued` event, which is emitted only on actual delivery — never on escrow. There is no onchain guardian reward pool and there are no staking emissions. See [Guardian Review](/protocol/governance/guardian-review).
## Settlement ordering
`_finalizeSettlement` charges in a fixed order so no fee is charged on assets another fee already took:
1. **Management fee** — lowers fund assets, and therefore lowers price per share.
2. **Performance fee** — reads the high-water mark *after* the management fee has been taken.
3. **High-water mark ratchet** — against the post-fee price.
4. **Queue settle price stamped** — queued redeemers and depositors settle at post-fee NAV.
## 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. Anyone can later push it out with the permissionless `claimUnclaimedFees(vault, token)`. Depositor capital is never held hostage by a bad fee recipient, and no fee is lost.
The vault also refuses to pay fees out of float reserved for stamped queue redemptions, so a fee can never eat into an already-priced exit.
## Other charges
These are not depositor fees, but they are the only other amounts the protocol moves:
| Item | What it is | Bounds |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| Fund creation fee | Optional absolute ERC-20 amount pulled at `createSyndicate`; default **0** (free) | Owner-set, unbounded |
| Idle-liquidity floor `minBufferBps` | A batch-execution guard, not a charge | 0 (off) to 5,000 bps (50%) |
| Challenge bonds and slashing | Guardian-accountability economics, not fees | See [Guardian Review](/protocol/governance/guardian-review) |
| WOOD staking | No staking fee and no reward emissions. Slashed WOOD is **burned** to `0x…dEaD`, never routed to the treasury | — |
## Consolidated bounds
| Parameter | Units | Default | Min | Max |
| -------------------------------------- | -------- | ----------------------------------------------------------- | --------- | ----------------------------------------- |
| `managementFeeBps` | bps/yr | Deploy-seeded (e.g. 200) | 0 | `SyndicateFactory.MAX_MANAGEMENT_FEE_BPS` |
| `agentFeeBps` | bps | `FeeConstants.DEFAULT_AGENT_FEE_BPS` (e.g. 2,000) | 0 | `FeeConstants.MAX_PERFORMANCE_FEE_BPS` |
| `maxPerformanceFeeBps` (per-vault cap) | bps | `FeeConstants.DEFAULT_MAX_PERFORMANCE_FEE_BPS` (e.g. 2,000) | 0 | `FeeConstants.MAX_PERFORMANCE_FEE_BPS` |
| Management split legs | bps | 6000 / 2000 / 2000 | 0 per leg | Sum == 10,000 |
| Performance split legs | bps | 5000 / 1500 / 2500 / 1000 | 0 per leg | Sum == 10,000 |
| Co-proposer `splitBps` | bps | Per proposal | 100 | 9,000 total |
| `creationFee` | Absolute | 0 | — | Unbounded |
| `minBufferBps` | bps | 0 | 0 | 5,000 |
## 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
* **No performance fee is charged.** It applies only to value above the fund's previous peak price per share, and a loss leaves that mark untouched.
* **The management fee is still charged**, on the assets and the time the strategy was deployed. See the disclosure above.
* 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](/protocol/governance/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.