> ## 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.
# Execution & Settlement
> Executing the mandate, the settlement paths, cooldown, and P&L
## Mandate execution
Once a proposal is Approved and the fund is out of cooldown, the pre-committed calls run directly on the vault:
1. Anyone calls `executeProposal(proposalId)` on the governor — no arguments beyond the id.
2. The governor verifies the proposal is Approved (guardian review cleared), inside its execution window, that no other strategy is live, and that cooldown has elapsed.
3. The governor records the active proposal — this is what `vault.redemptionsLocked()` reads — and snapshots the vault's asset balance as the capital baseline.
4. The governor calls `vault.executeGovernorBatch(executeCalls)`, the vault's governor-only entrypoint. All positions now live on the vault address.
**Nothing new enters at execution.** The calls were locked at proposal time and voted on. Execution is a replay.
**The redemption lock is a pull-check, not a stored flag.** The vault has no `lockRedemptions()` call — `redemptionsLocked()` reads the governor's active-proposal signal live on every access. Recording the active proposal at execution flips the lock; clearing it at settlement unlocks it. This removes a whole class of state-desync bugs where the vault could disagree with the governor about whether a strategy is live.
While a strategy is live, `withdraw` / `redeem` / `deposit` and the rescue functions all revert against instant execution. Depositors who want to move during a proposal use the [async queue](/protocol/vault-liquidity): `requestRedeem` / `requestDeposit` escrow, settlement stamps one realized price, and anyone `claim`s after unlock.
## Two clocks
Two separate timers govern the lifecycle:
1. **Execution window** — time to *start* executing after approval (governor parameter). Miss it and the proposal Expires.
2. **Strategy duration** — time the position *runs* before it can be settled (agent-proposed, capped by `maxStrategyDuration`).
```
|-- voting --|-- review --|-- exec window --|----- strategy duration -----|-- cooldown --|
propose guardians execute calls position is live settle withdrawals open
```
## Settlement paths
A live strategy runs for its committed duration, then settles by replaying the pre-committed `settlementCalls`. Because the exact onchain state at settlement can't be predicted — slippage, interest accrual, pool drift — those calls can revert. Sherwood provides the standard path plus a bonded, guardian-gated emergency split for stuck strategies.
| Function | Who | When | Calls |
| ------------------------------ | --------------------------------------------------------------- | -------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| **`settleProposal`** | Proposer anytime after execute; anyone after `strategyDuration` | Happy path | Pre-committed `settlementCalls` |
| **`unstick`** | Vault owner | Strategy stuck past its duration | Pre-committed `settlementCalls` only — no custom calldata, no bond, no review |
| **`emergencySettleWithCalls`** | Vault owner | Pre-committed calls are broken | Owner-supplied custom calls; stored in the registry, opens a guardian review. Requires a sufficient owner bond |
| **`cancelEmergencySettle`** | Vault owner | Before the review ends | Self-recall of the above, no slash |
| **`finalizeEmergencySettle`** | Vault owner | After the review ends | Runs the stored calls if guardians didn't block; if they did, the owner bond is burned and this reverts |
The proposer can settle starting **1 hour** after execution — the early-close incentive, since the agent has the most context and only earns carry on profit. Once the full `strategyDuration` has elapsed, **anyone** — keeper, depositor, bot — can settle, so a disappearing agent never traps capital. Both paths run the same voted-on `settlementCalls`, close all positions, and return capital to the vault; P\&L is booked and fees distributed on profit.
When the committed unwind is still correct but nobody has triggered it, the owner calls `unstick(proposalId)` to force it. It runs the proposal's pre-committed `settlementCalls` only — no custom calldata, no fallback — and reverts if those calls revert. It needs **no** active owner bond, because the calls were already approved through governance and guardian review; an owner whose bond was slashed elsewhere can still `unstick` a legitimately-approved settlement here.
When the pre-committed calls are broken (stale params, a paused target, shifted pool state), the owner proposes custom settlement calldata through a guardian-reviewed window:
1. `emergencySettleWithCalls(proposalId, calls)` — reverts unless the owner bond covers the vault's current required bond. The governor stores the full calls array in the registry and opens the review. **Calls do not execute yet.**
2. During the window, active guardians can vote to block; the owner may self-recall with `cancelEmergencySettle` (no slash).
3. After the window, `finalizeEmergencySettle(proposalId)` — proposal id only; the registry returns the stored calls. If guardians reached the block quorum, the owner bond is burned and this reverts. Otherwise the governor runs the calls and settles.
The bond recheck at call time is sized to the vault's *current* value, closing a "stake small, drain large" gap.
The split replaces a single all-in-one emergency function whose unbounded owner power was the primary escalation vector. It covers every failure mode without handing the owner an unbounded escape hatch: the happy path is trustless, `unstick` needs no new calldata, and any custom calldata is bonded and guardian-gated.
**Fees can't brick settlement.** Every fee transfer is wrapped so that a failure — a recipient a token has blacklisted, a paused token — escrows the owed amount against that recipient instead of reverting the whole settlement. The recipient pulls it later with `claimUnclaimedFees(vault, token)`, keyed to the origin vault. Settlement always completes.
## Cooldown
After settlement a cooldown runs before any new strategy can execute on the fund. During cooldown, redemptions are open and depositors can leave; proposals can still be submitted and voted on, but `executeProposal` reverts until cooldown ends. It is the deliberate exit window between strategies — if depositors don't like what's next, they get out first. Bounds: 1 hour to 30 days.
## P\&L and the two fees
Only one strategy runs per vault at a time, so P\&L is a simple balance snapshot: the vault's asset balance at settlement minus the capital baseline snapshotted at execution. Any non-asset dust the strategy failed to unwind counts as that much loss — strategies must fully return the underlying before settling.
Settlement charges exactly two fees, at rates snapshotted at propose. The **management fee is charged on every settlement — profit, flat, or loss.** The **performance fee is charged only above the fund's previous peak price per share.** They are taken in a fixed order:
```
pnl = balanceAtSettle − capitalSnapshot
# 1. Management fee — always charged, regardless of pnl
managementFee = assetSeconds × managementFeeBps / (10_000 × 365 days)
# 2. Performance fee — only on value above the high-water mark,
# measured after the management fee has lowered price per share
gain = max(0, postMgmtValue − highWaterMarkValue)
performanceFee = gain × min(agentFeeBps, maxPerformanceFeeBps)
# 3. Ratchet the high-water mark against the post-fee price
# 4. Stamp the queue settle price at post-fee NAV
# Everything left over stays in the vault, accruing to all depositors
```
Each fee is then divided once by the splits held on `ProtocolConfig` — management 60/20/20 across agent, protocol and guardians; performance 50/15/25/10 across agent, protocol, guardians and the fund owner. There is no sequential waterfall of compounding haircuts. The guardian slice routes onchain to a fee-recipient multisig in the fund's asset, then distributes to individual guardians off-chain, weekly, via Merkl. See [Economics](/protocol/governance/economics) for the full breakdown, bounds, and the loss-case disclosure.
## Full lifecycle in the call arrays
The proposal commits the complete lifecycle upfront — opening calls in `executeCalls`, closing calls in `settlementCalls`. A Portfolio-strategy proposal against a WETH-denominated fund looks like:
```
executeCalls (open the basket — run at execution)
1. approve WETH to the swap adapter
2. swap WETH → TSLA-weight
3. swap WETH → AMZN-weight
4. swap WETH → PLTR-weight
settlementCalls (unwind back to WETH — run at settlement)
5. swap TSLA → WETH
6. swap AMZN → WETH
7. swap PLTR → WETH
```
Depositors vote on the whole sequence — the exact tokens, weights, and venue — before it runs. After the unwind the vault should hold its deposit asset (WETH in this example) again; any leftover non-asset tokens are recoverable only via the owner's targeted rescue functions. Because the unwind calls are a prediction of future state, agents should use generous slippage tolerances; if the standard settle reverts, the owner uses `unstick` or the guardian-reviewed emergency path.
The onchain track record is the `ProposalSettled(proposalId, vault, pnl, performanceFee, duration)` event emitted at settlement, which indexers aggregate into per-agent history. A richer EAS-based attestation is planned but not shipped.