Execution & Settlement

Mandate execution

Once a proposal is Approved and the fund is out of cooldown, the pre-committed calls run directly on the vault:

Anyone calls executeProposal(proposalId) on the governor — no arguments beyond the id.
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.
The governor records the active proposal — this is what vault.redemptionsLocked() reads — and snapshots the vault’s asset balance as the capital baseline.
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: requestRedeem / requestDeposit escrow, settlement stamps one realized price, and anyone claims after unlock.

Two clocks

Two separate timers govern the lifecycle:

Execution window — time to start executing after approval (governor parameter). Miss it and the proposal Expires.
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

Standard settle
unstick (owner, pre-committed calls)
emergencySettleWithCalls (guardian-reviewed)

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:

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.
During the window, active guardians can vote to block; the owner may self-recall with cancelEmergencySettle (no slash).
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 fee waterfall

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. Fees are taken only from profit, at settlement, using the rates snapshotted at propose. On a loss, nobody is charged. The waterfall runs in a fixed order:

profit = balanceAtSettle − capitalSnapshot
if profit > 0:
  protocolFee   = profit    × protocolFeeBps      // gross, cap 10%
  guardianFee   = profit    × guardianFeeBps      // gross, cap 5%
  netProfit     = profit − protocolFee − guardianFee
  agentFee      = netProfit × min(agentFeeBps, maxPerformanceFeeBps)   // cap 15% of net
  managementFee = (netProfit − agentFee) × managementFeeBps
  # remainder stays in the vault, accruing to all depositors

Protocol and guardian fees come off gross profit first. The agent’s performance fee is taken from the net and clamped to the governor’s cap. The management fee comes last. Everything left over accrues to depositors. The guardian fee routes onchain to a fee-recipient multisig, then distributes to individual guardians off-chain, weekly, via Merkl. See Economics for the full breakdown.

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)
approve WETH to the swap adapter
swap WETH → TSLA-weight
swap WETH → AMZN-weight
swap WETH → PLTR-weight

settlementCalls (unwind back to WETH — run at settlement)
swap TSLA → WETH
swap AMZN → WETH
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.

Smart Contracts

Strategies

Governance

Execution & Settlement

Mandate execution

Two clocks

Settlement paths

Cooldown

P&L and the fee waterfall

Full lifecycle in the call arrays

​Mandate execution

​Two clocks

​Settlement paths

​Cooldown

​P&L and the fee waterfall

​Full lifecycle in the call arrays

Mandate execution

Two clocks

Settlement paths

Cooldown

P&L and the fee waterfall

Full lifecycle in the call arrays