How withdrawals price

An investor cashes out one of two ways. The prices they get, and the fences around each, are the vault's answer to the obvious attack: what if someone tries to redeem at the top of a NAV spike?

The queue — protected price

The default path is asynchronous. requestWithdrawal accrues the management fee, snapshots the current NAV/share, locks the shares, and appends a FIFO request. Later — by the keeper, by you, or by anyone — processWithdrawals settles the front of the queue.

The settle price is the lower of the snapshot and the live NAV/share at the moment funds actually go out:

• NAV rose since the request → you're paid the older, lower snapshot.
• NAV fell since the request → you're paid the newer, lower price.

Either way the exiter gets the worse of the two. This is a one-sided anti-timing collar: a request placed at a local peak still settles at whatever is lower when it's funded, so top-ticking a spike through the queue is impossible. The snapshot only ever caps the payout down; it never lifts it.

Settlement is strict FIFO with a liquidity stop. Each payout is drawn from EVM-liquid USDC; if the next request's gross exceeds what's liquid, the loop halts on it rather than letting a later request jump ahead. That is why servicing the queue means bridging Core funds home to the reserve — the money has to be on the EVM side to pay.

Instant — raw price, heavily fenced

withdraw settles synchronously at raw live NAV/share, no snapshot protection. Because it prices raw, it only runs while the vault is active — a pause routes every exit back through the protected queue, so instant can never fire raw NAV straight through a drawdown. It is fenced four ways:

• Per-request cap — no single instant exit exceeds the instant-limit (instantWithdrawLimitBps) share of NAV.
• Reserve-only liquidity — instant pays from the EVM reserve minus the amount already reserved for the queue, never starving the oldest queued request. A spike's gains sit in perp uPnL on Core, not in the EVM buffer, so the pool an instant exit can drain doesn't hold the spike.
• Lockup — freshly deposited shares are locked (the vault's configured lockup) before either exit path opens, killing the deposit-into-a-spike, exit-immediately play.
• Performance fee — crystallizes on the exiter's own gain above their entry, on the way out.

Instant can be switched off entirely by setting the instant limit to zero; the queue is then the only path.

Why spot can't manufacture a spike

Registered spot tokens are valued in NAV at min(mark, entry cost) — a cost-basis cap. Pumping a token's mark price does not raise NAV, because NAV only ever counts the lower of the live mark and what the vault paid. The spike has to be real equity to price into an exit at all.

Who bears the residual

The small amount an instant exit can capture above the perfectly-fair price is borne by the remaining holders — the deliberate, bounded cost of running an open fund. You tune that residual directly: a larger liquidity reserve and a smaller instant limit shrink it, and instant-limit zero removes it. Queue exits carry no such residual by construction.

The backstop you must respect

If the oldest open request ages past the vault's queue timeout (1–30 days, fixed at creation), triggerEmergency becomes permissionless and anyone can latch the vault into terminal emergency — irreversibly. An unserviced queue is therefore not a soft failure; it eventually hands any address a permanent kill switch. Service it.

A queued request is final — there is no cancel, for anyone. Requesting locks the shares until they settle at the protected price above; the holder bears downside during the wait, but the snapshot means they can never be paid above it.

In the cockpit: Manage → Capital → Queue & bridge shows open requests, the oldest-request age against the timeout, and the process / reconcile levers.