FAQ

No. The OPERATOR_ROLE holder can update it via setProtectionPremiumRate.

The metavault setter itself is immediate, so deployments that want a delay route OPERATOR_ROLE through an external timelock or through a Premium Rate Module. Every update first syncs accounting, so the old rate applies to the elapsed period and the new rate only applies going forward.

The rate can never exceed 100% APR, and it can never be set below the vault's immutable minProtectionPremiumBps floor.

A drawdown deeper than what junior can absorb. Junior absorbs first, but if the underlying drops far enough, junior reaches zero and the residual loss starts marking down the senior share price. So your worst case is approximately (underlying loss − junior depth ÷ senior depth × 100%) plus the premium you've been paying.

At the 4× leverage cap, junior is 25% the size of senior, so senior is shielded from drawdowns up to roughly 20% of the underlying before any senior haircut starts.

A drawdown deeper than your share of junior. Junior is the first absorber, so any underlying loss takes a bite out of the junior share price proportionally. If junior reaches zero, the share price reaches zero and your junior position is wiped on the affected drawdown.

There's no extra mechanism that takes more than 100% of your share. The loss is bounded by the value of your shares.

There is no protocol exit fee when you execute your own notice.

Both senior and junior redemptions execute at the current share price after the notice matures, capped by the file-time snapshot value. The premium you've already paid (senior) or earned (junior) is already reflected in the share price.

If a third-party keeper executes a matured notice for you, the keeper receives KEEPER_FEE_BPS (5 bps) from your payout. Other LPs do not pay that fee.

The PROTOCOL_ROLE holder can set a performance fee up to MAX_PERFORMANCE_FEE_BPS (20% of underlying gains) and choose the fee recipient.

The fee is taken only when the wrapped vault's underlying value increases. It is paid by minting value-backed junior shares to the fee recipient, so it does not create a separate senior exit charge and it does not apply to losses or to the senior-to-junior protection premium.

To stop senior holders from racing junior in a developing drawdown. Without the notice, a senior could see the vault wobbling and exit cleanly while junior is still locked behind their notice, leaving the protection cushion under-collateralised. The 5-day window plus execution-time pricing keeps both sides committed long enough that the protection economics stay honest.

Junior is the protection-providing tranche. A 10-day lock prevents junior holders from yanking collateral right before a loss event, which would leave senior unprotected. The asymmetry (10d junior vs 5d senior) reflects the asymmetric protection role.

No. The notice locks the shares so they can't be transferred while pending. The redemption is priced at the lower of execution-time NAV and the file-time snapshot value, so a pending notice does not capture post-filing upside.

Yes, any time, with no penalty. Cancelling returns the queued shares back to your wallet immediately.

You cannot refile while a notice is active. requestSeniorWithdrawal / requestJuniorWithdrawal reverts until the existing notice is cancelled, fully executed, or otherwise cleared.

The OPERATOR_ROLE holder can pause new deposits via a single global depositsPaused flag. Withdrawals are never paused. Filing, cancelling, and executing all keep working regardless of pause state.

At the 4× leverage cap, a 5% drop on the underlying is fully absorbed by junior, so senior doesn't feel it.

• Senior: the share price stays put. Withdrawals execute at par (modulo accrued premium).
• Junior: a 5% drop on senior equals roughly 20% of junior, so junior's share price marks down by ~20%.
• Solvency: the cap is preserved on a relative basis (junior smaller, senior unchanged), so new senior deposits won't clear until junior recapitalises.

This is the protocol's intended protection envelope: the worst case where senior is still fully whole.

• Senior: still whole. Senior share price unchanged.
• Junior: share price reaches zero on this drawdown.
• Any further drops past this point start absorbing into senior. See the next scenario.

Past the depth of junior, senior bears the rest. This is the protocol's outer boundary.

• Senior: the residual loss (e.g. 10% past junior's depth in a 30% drawdown) is divided across senior alone, so about a 12.5% mark-down at the 4× cap.
• Junior: fully wiped on entry to this regime; further drops don't take more from junior because there's nothing left.

The withdrawal is blocked transiently, not lost. The notice doesn't consume, so the holder simply retries once liquidity returns.

• The wrapped vault has high utilisation and can't satisfy the redemption right then.
• The metavault doesn't queue or partial-fill; the call reverts cleanly.
• The same withdrawal succeeds once underlying liquidity recovers.

New entries are blocked on both sides; withdrawals keep working regardless.

• The OPERATOR_ROLE holder can pause new deposits globally via a single depositsPaused flag.
• Existing positions can still file notices, cancel, and execute. Premium accrual continues.
• Reversible at any time.

The transaction is rejected before any value loss can be socialised.

• The metavault measures the underlying value before and after every deposit/withdrawal it routes.
• If a deposit credits less than the supplied assets, or a withdrawal removes more value than the payout, the call reverts.
• Approved underlying vaults are therefore expected to be no-fee/no-slippage integrations, modulo one asset unit of rounding tolerance.

Some exit successfully; the rest are blocked until the cap rebuilds. This is the race-on-contention trade-off of a continuous-flow pooled design.

• Juniors all wait out the 10-day notice and race to execute. Senior leverage is at, say, 3.9× of the 4× cap.
• The first junior withdrawals succeed.
• Once those exits push senior past 4×, subsequent withdrawals are blocked.
• Trapped juniors wait for more junior deposits, premium accrual lifting the junior side, or senior exits.
• Junior exits are also bounded by currently redeemable underlying liquidity. Outstanding senior notices can reserve liquidity ahead of junior, but only up to SENIOR_NOTICE_RESERVE_CAP_BPS (50%) of currently redeemable liquidity.

Self-balancing mitigation: as junior thins out, junior yield mechanically rises (the same premium splits across fewer junior shares), which attracts fresh deposits and rebuilds the cap. The operator or PRM can also raise the premium rate to accelerate the rebalance, subject to the vault floor and rate cap.

Not meaningfully. Two design choices close this off:

• Execution-time pricing. Filing a notice doesn't lock in the pre-drawdown share price; senior redeems at the share price when execution lands, after the waterfall has already absorbed the loss.
• 5-day senior notice. Most drawdowns play out well inside 5 days, so the haircut is already baked into the share price by the time senior could exit. Filing early doesn't escape the loss; it just chooses when to realise it.

The result: filing early is break-even at best.

It doesn't stay sitting for long. Once a notice matures, keepers crank it through, and holding a stale notice costs the filer, so it isn't a free option.

Keepers are permissionless bots that execute matured notices on behalf of the filer. Anyone can call withdrawSenior / withdrawJunior once a notice matures with owner set to the notice holder; the keeper earns KEEPER_FEE_BPS (5 bps) of the proceeds, skimmed from the holder's own payout — not socialised across other LPs. Self-execution by the holder is always free. The keeper-paid fee is what makes this economic: bots watch the chain, push matured notices to settlement, and pocket the spread. The metavault also enforces a 3-day NOTICE_EXECUTION_WINDOW after maturity, after which the notice becomes stale. Stale senior notices can be cleared by calling clearStaleSeniorWithdrawal(owner); stale junior notices are cancellable by the holder. Deployments where the public keeper market is too thin can set keeperRestricted, which limits the keeper path to PROTOCOL_ROLE holders while leaving self-execution open.

That economic pressure plus a few mechanical points stop the stale-notice strategy from working:

• A senior who sits on a matured notice keeps paying premium for no reason: premium continues to drain into junior on those queued shares.
• The share price keeps moving while the shares are locked. Filing doesn't insulate them from the waterfall.
• Locked shares can't be transferred, posted as collateral, or sold on a secondary market.
• Junior notices still hit the leverage gate at execution, so a standing junior notice doesn't guarantee exit.

Net effect: a standing notice removes the time cost of exiting, not the price cost — and the keeper market means the time cost expires on its own.

Existing lcJUN shares become worthless, and the tranche is terminal, but the contract handles it cleanly.

• After a full wipe, the junior share price is zero.
• New junior deposits are blocked while zero-value shares remain outstanding, so new capital can't resurrect old shares.
• Partial drawdowns remain recapitalizable: if junior is above zero, new depositors mint at the impaired share price.
• After a full wipe, operators deploy a fresh metavault rather than recapitalising in place.

The metavault enforces hard bounds, but governance delay depends on who holds OPERATOR_ROLE.

• The premium cannot be set above 100% APR.
• The premium cannot be set below the vault's immutable minProtectionPremiumBps floor.
• If OPERATOR_ROLE is held by a timelock, the change must be queued and is visible before execution.
• If OPERATOR_ROLE is held by a PRM, the module's own curve, floor, cap, and APY guard determine the next rate before it calls the metavault.
• If OPERATOR_ROLE is held directly by an address, the setter is immediate. That is an operator trust assumption, not a metavault timelock.