Impairment v1 disclosures

What happens to deposits and withdrawals when a vault strategy fails, and how holders claim any recovered funds.

Impairment side-pocketing is the vault's safety mode for a failed strategy. The failed strategy is set aside, the rest of the vault (the clean book) keeps its value, and holders at the moment of the failure get claims on whatever is later recovered. Read this if you hold vault shares, integrate CreatorOVault, or operate a vault.

Status

This is the public behavior summary for CreatorOVault impairment side-pocketing v1, which ships with new vault launches on module storage v3. It only changes vault behavior after a guardian trips impairment on a strategy. The full state graph, actors, and test checklist are in Impairment state machine.

What v1 does

• Keeps one fungible ERC-4626 share for clean-book operations.
• Uses trip-boundary snapshots to lock recovery rights for impaired epochs.
• Uses non-transferable v1 claims (epoch-scoped).
• Uses realized-only recovery accounting through CreatorORecoveryEscrow.
• Excludes finalized impaired strategies from clean-book totalAssets().

What v1 does not do

• No transferable claims.
• No claim-aware pass-through adapters for wrappers/lending markets.
• No onchain historical share checkpoints for eligibility (Merkle-root snapshot flow in v1).

Who receives claims

Claims go to the accounts listed in a snapshot, not automatically to everyone who holds exposure through another contract.

The vault does not infer beneficial ownership across integrations onchain. Management proposes a Merkle root of (epochId, account, amount) leaves; claim ERC1155s mint to those accounts.

For the standard OVault path (vault ERC-4626 shares locked in CreatorOVaultWrapper, users hold ShareOFT):

• Preferred roots target ShareOFT economic holders (or their custody addresses) with amount in vault-share units (typically shareOFT.balanceOf(user) * 1000, plus attributed dust when used). Holders then mint and call claimImpairmentRecovery themselves.
• Do not build a sole leaf from vault.balanceOf(wrapper) unless that wrapper leaf is intentional (residual / treasury). A wrapper leaf requires a wrapper that can receive ERC1155 claims and forward recovery (new CreatorOVaultWrapper bytecode: ERC1155Holder + onlyOwner claimImpairmentRecovery). Older non-upgradeable wrappers revert on mint (ERC1155InvalidReceiver).
• Other integrations (lending markets, pooled adapters) still receive claims only if they appear as leaf accounts; without a claim-aware adapter, end users behind those contracts cannot claim.

Trust boundaries

What the roles that run impairment can and cannot do.

• Guardian/emergency roles may trip impairment to protect users.
• Trip/finalize cannot assign discretionary impaired NAV to the clean book.
• Recovery distribution is limited to epoch claims and realized inflows.

Deposits and withdrawals during impairment

While impairment is active, the vault is frozen for deposits and withdrawals.

• During Suspect mode:
  • deposit / mint revert.
  • withdraw / redeem revert.
  • maxDeposit / maxMint / maxWithdraw / maxRedeem return 0.
• Claims cannot mint before root finalization.
• Finalization cannot occur before challenge-window unlock.

Claim and recovery caps

Hard limits that stop claims from being diluted or paid twice. These guards come from the June 2026 audit pass (C-2 / C-3 / H-1) and are enforced onchain by CreatorOVaultCoreModule and CreatorORecoveryEscrow:

• Mint cap (C-2). Cumulative claims minted for an epoch never exceed the epoch’s totalClaimSupply. A proposed root whose leaves sum past the cap reverts with ClaimSupplyExceeded once the cap is reached — no silent dilution of honest claim holders.
• Epoch-scoped escrow accounting (C-2). CreatorORecoveryEscrow rejects any claim that would push claimedByEpochAsset past recoveredByEpochAsset for that epoch/asset (ClaimExceedsRecovered). One epoch’s claims cannot drain recoveries notified for another.
• False-alarm trips destroy the claim surface (C-3). clearImpairmentTrip zeroes the epoch’s snapshotRoot, totalClaimSupply, and recoveryAsset and resets the challenge-window state. Cleared epochs cannot mint claims or receive recovery notifications (ImpairmentRootRequired). Legitimate post-finalize Resolved epochs keep their root and stay claimable.
• Recovery notification guards (H-1). notifyImpairmentRecovery reverts on zero amounts. When the recovery asset is the creator coin, transfer uses tracked-balance accounting so clean-book totalAssets() immediately reflects the escrowed outflow (no double counting between vault book and escrow).

Release notes template text

Use the following text in release communication:

1. v1 introduces impairment epochs with trip-boundary snapshots and non-transferable claim rights.
2. clean-book ERC-4626 operations resume after impairment finalization.
3. realized recoveries are paid through epoch claims; recoveries are not merged back into clean NAV.
4. OVault ops should root ShareOFT economic holders (vault-share units); residual wrapper leaves need a claim-aware wrapper. Other share-holding integrations still need claim-aware adapters.