One vault.
One protocol.
One curator.

The vault in one screen

Depositors put one asset in during a window, a named curator multisig deploys that capital on one external protocol for a fixed term, and at the end everyone redeems principal plus their share of net yield. New yield sources scale by deploying new vaults.

From FIV to Managed Vault

FIV required a custom adapter and a separate audit per yield source. Managed Vault scales horizontally instead — same vault contract, parameter-only.

Bound the trust, don't remove it

Defences against loss are off-chain and reputational: the admin's choice of protocol, the curator's mandate, and the on-chain trust & safety invariants. Every depositor in a vault sits at the same level of the stack — there is no protected tranche.

Asset flow across the lifecycle

Where the underlying asset (e.g. USDC) sits at each phase, and how it moves between depositor, vault, connected protocol, treasury and curator.

Reading this diagram

• Every column is one lifecycle phase. Boxes show what is held where, arrows show what moves.
• USDC only ever lives in three places: depositor wallets, the vault, or the connected protocol. There is no fourth bucket the curator can route to.
• Fees are taken only at the Phase 4 boundary, and only out of the yield above principalAtStart.

What happens when a user deposits

Standard ERC-4626 deposit, gated by the deposit window and the admin pause flag. The vault pulls the underlying via transferFrom and mints proportional shares.

// once per token
USDC.approve(vault, type(uint256).max);

// during the window
vault.deposit(100e6, msg.sender);

// shares now in wallet
vault.balanceOf(msg.sender); // → 100e6 smUSDC

Withdrawal during the window

Depositors may rescind before the window closes by calling redeem / withdraw against their shares while state == Initialized. After start(), mid-term exits are disabled in the scaffold pending Open Question 5.

What the vault actually holds, mid-term

At any instant during Started, the vault's accounting splits into two buckets: idle underlying that hasn't left the contract yet, and the curator-reported value of the open position on the connected protocol.

Why the split matters

• The two buckets are independently observable — the idle portion is trustless (real balance), the position portion is curator-marked (until unwind).
• Anyone can compute the live share price; the guardrail ensures the marked portion can't lurch suspiciously without a timelocked confirmation.
• To exit Started, the curator must drive the position bucket back to zero, i.e. move all value back to the idle bucket.

External integrations

From the vault's point of view, the world is exactly three contracts: the underlying ERC-20, the connected protocol, and the curator multisig that signs curatorCall.

Concrete examples of connectedProtocol

vault.curatorCall(
  aavePool,
  abi.encodeWithSelector(
    Pool.supply.selector,
    USDC, amount, vault, 0
  ),
  amount, true  // approveUnderlying
);

vault.curatorCall(
  morphoBlue,
  abi.encodeWithSelector(
    IMorpho.supply.selector,
    marketParams, amount, 0,
    vault, ""
  ),
  amount, true
);

vault.curatorCall(
  pendleRouter,
  abi.encodeWithSelector(
    IPRouter.swapExactTokenForPt.selector,
    vault, market, minPtOut, ...
  ),
  amount, true
);

vault.curatorCall(
  uniNPM,
  abi.encodeWithSelector(
    INPM.mint.selector,
    mintParams
  ),
  amount, true
);

What the vault deliberately doesn't touch

• Any address other than connectedProtocol, the underlying ERC-20 itself, the treasury (at settlement), and the curator multisig (at settlement).
• No DEX routers, bridges, swap aggregators, or yield optimisers unless one of those is the connected protocol for the vault.

The curator's single door

curatorCall is the only escape hatch from the vault. It is locked to one destination and wraps the call with scoped approvals so the target can never re-pull funds after the call returns.

Fuzzed as an invariant

Across 1,376+ random non-connected targets in the test suite, every attempt reverts with TargetNotConnectedProtocol and the vault's accounting stays whole: idle + protocolDeposits == principalAtStart.

Bounded NAV moves

A single NAV update cannot move share value by more than navMoveGuardrailBps without a separate timelocked confirmation. Guards against fat-fingered or malicious marks.

Why a timelock instead of a hard cap

Some honest events are large (a depeg fix-up, a vault rebase). A hard cap would make them unreportable. A timelock makes them reportable but legible — the world sees the queued move before it executes, with enough lead time for depositors / admin to react.

Two transactions to pay everyone

After the curator has unwound, two things happen: settle() takes the performance fee and locks final NAV, then each depositor calls redeem / withdraw against the locked NAV.

Performance fee only, taken at settlement

No upfront premium. Fee is feeRatio × realisedYield, computed and taken when the vault moves to Settled and split between Saffron treasury and the curator.

Boundary cases

What the user gets — the share token

On deposit() the depositor receives a standard ERC-4626 share token. It's a regular ERC-20: transferable, viewable in every wallet, and tradeable on secondary venues if any exist for this vault.

USDC.approve(vault, amount);
shares = vault.deposit(amount, you);
// shares represents your stake in the vault

assets = vault.redeem(shares, you, you);
// you receive principal + your share of net yield

The position-token decision is still open

Open Question 4 in the spec — ERC-4626 share token (the current scaffold) vs ERC-721 per-deposit NFT. The fungible share token gives users a tradeable, divisible position; an NFT would record each deposit individually. Product decision pending.

Position dashboard — view functions

The vault exposes the full position state via cheap view functions. Any UI, indexer, or third party can reconstruct the on-protocol position off-chain from these reads (spec §10.4).

The full read surface

// position + accounting
vault.idleAssets()              // USDC sitting inside the vault
vault.reportedPositionValue()   // curator-reported value of the open position
vault.totalAssets()             // idle + reported (or finalTotalAssets in Settled)
vault.convertToAssets(shares)   // per-user claim
vault.previewRedeem(shares)     // what you'd get if you redeemed right now

// lifecycle
vault.state(), vault.depositWindowEnd(), vault.termEnd(), vault.finalTotalAssets()

// immutable config (read once before depositing)
vault.connectedProtocol(), vault.curator(), vault.admin(), vault.treasury()
vault.feeRatio(), vault.navMoveGuardrailBps(), vault.navMoveTimelock()

Who can do what

Four roles, each with narrow, legible authority. Crossing the line reverts.

Two-multisig separation of duties

Admin and curator are different multisigs. The admin can not operate vault capital, and the curator can not reconfigure the vault. There is no single role that can both deploy a vault and drain it.

State machine

Four states, one-way transitions, enforced on-chain. Each state gates a different set of allowed actions.

Transition rules

• Initialized → Started: anyone may call start() once block.timestamp ≥ depositWindowEnd. Principal at that moment is snapshotted as the baseline for yield.
• Started → Ended: anyone may call end() once the term has elapsed and the curator has fully unwound the reported position to zero.
• Ended → Settled: anyone may call settle(). Computes performance fee on realised yield, transfers fee shares, locks final NAV.

What each actor does, in order

Same four states, viewed as an actor-vs-time grid.

Curator authority is scoped

The curator can do everything on the connected protocol and nothing anywhere else. Calls to arbitrary targets revert with TargetNotConnectedProtocol.

Implementation

• connectedProtocol is immutable — set in the constructor, no setter.
• curatorCall requires target == connectedProtocol; otherwise reverts with TargetNotConnectedProtocol(target).
• Approvals to the target are scoped to the single call: forceApprove(target, value) before, forceApprove(target, 0) after.
• NAV updates also enforce newTotal ≥ idleAssets() to prevent quietly under-reporting an escape.

On-chain invariants

Five invariants pinned in the implementation. The two starred are the highest-value fuzz targets per spec §14 and are exercised in the invariant test suite.

Add yield sources by deployment, not by governance

There is no on-chain whitelist of allowed protocols. To onboard a new yield source the admin deploys a new vault with that protocol baked in. Existing vaults are unaffected.

What this lets you do

• Run multiple vaults in parallel against different protocols, terms, and curators.
• Sunset a yield source by simply not deploying new vaults for it.
• Audit risk per-deployment, not per-governance-vote.

Genuinely exotic protocols

The common case is parameter-only — the curator drives the protocol via the generic curatorCall. Truly exotic protocols can still get a thin adapter contract (IProtocolAdapter); the vault calls the adapter, the adapter calls the protocol.

Deliberately out of scope

Discipline list. These should not be built unless the spec changes.

What product still has to decide

Each item below is a constructor parameter or configurable TODO — not hardcoded into immutable defaults. Locking these is a product decision, not a code change.

How the code is laid out

Foundry, OpenZeppelin v5, Solidity 0.8.28. Per-vault factory deploys ERC-4626 instances with the spec encoded as immutables.

Run it

forge install
forge fmt --check
forge build --sizes
forge test -vvv

FOUNDRY_PROFILE=ci forge test -vvv        # 1024 fuzz runs, depth 128 invariants
FOUNDRY_PROFILE=coverage forge coverage   # optimizer off, source maps usable
slither . --config-file slither.config.json

What this deck is missing

• Concrete fee / guardrail / timelock numbers (Open Questions 1–3).
• The position-token decision (Open Question 4).
• Early-exit policy (Open Question 5).

Everything else in the spec is encoded in the code, the tests, or this deck.