[RFC] Offboard legacy Arks and re-open paused Fleets for withdrawals

1. Summary:

This RFC proposes to wind down the legacy ARK set across the Lazy Summer Fleets (except for the exploited USDC LR/HR Vaults on Ethereum). For each affected Fleet we would remove the old ARKs that are already at deposit cap 0, unpause the Fleet so depositors can withdraw, and set the tip rate to 0. It is intended as a housekeeping / consolidation step; it does not migrate user funds or introduce new strategies. If the community is supportive, it would be promoted to a batch of SIPs (one vote per Fleet) under SIP2.59.X (ba-risk-managed) and SIP7.3.X (dao-risk-managed).


2. Context & Motivation:

The Fleets have accumulated a large number of legacy ARKs from earlier configuration. Many have already had their deposit caps set to 0, but remain registered on their FleetCommanders and are still counted in NAV precisely the state the exploit abused. While the two affected Mainnet USDC vaults are being remediated through their own separate votes (SIP1.7 & SIP1.8), the remaining Fleets still carry these dormant zero-cap Arks. All Vaults were paused protocol-wide as a precaution after the incident, and the post-mortem notes that removing old, unused Arks is likely a precondition for safely unpausing them.

Cleaning these up:

  • Restores withdrawals. Unpausing the affected Fleets re-enables withdrawals for depositors.
  • Simplifies the Fleets. Removing dormant zero-cap ARKs reduces surface area and keeps each Fleet’s registered strategy set current.
  • Is low-risk. Only ARKs already at cap 0 are in scope, so no new deposit exposure is created and no funds are moved beyond making them withdrawable.

An important constraint shapes the scope: an ARK’s cap cannot be set to 0 while it is paused, so paused / non-zero ARKs cannot be bundled into this round. This RFC therefore covers only the ARKs already at cap 0; any remaining ARKs would be handled in a later round if the community wishes to continue.


3. Proposal:

Retire the legacy zero-cap ARKs across the Fleets below, unpausing each Fleet (where paused) and zeroing its tip rate.

Per-Fleet onchain actions: unpause() (where paused) → removeArk() for each legacy ARK → setTipRate(0). Proposals originate on the Base governor and relay via LayerZero to each destination-chain timelock (Base Fleets execute directly).

Scope for ba-risk-managed (→ SIP2.59.X):

Fleet Network ARKs removed
LazyVault_HigherRisk_WETH Mainnet 17
LazyVault_LowerRisk_USDT Mainnet 11
LazyVault_LowerRisk_WETH Mainnet 10
LazyVault_LowerRisk_USDC Base 15
LazyVault_LowerRisk_WETH Base 10
LazyVault_LowerRisk_EURC Base 5
LazyVault_LowerRisk_USDC_2 Arbitrum 10
LazyVault_LowerRisk_USDT Arbitrum 6
LazyVault_LowerRisk_USDCe Sonic 7
LazyVault_LowerRisk_USDC HyperEVM 4 (not paused — no unpause)
LazyVault_LowerRisk_USDT HyperEVM 6 (not paused — no unpause)

Scope for dao-risk-managed (→ SIP7.3.X):

Fleet Network ARKs removed
DAO_LazyVault_USDC_1 Mainnet 10
DAO_LazyVault_WETH_1 Mainnet 5

That is 13 Fleets / ~116 ARKs in total. Each Fleet would be its own Tally vote, following per-Fleet SIPX.Y.Z convention.


4. Open Questions:

  • Continuation: Do @Recognized_Delegates want to continue into a second round for the paused / non-zero ARKs after this batch, or stop at the zero-cap set?
  • Exclusions: Should any listed Fleet be held back (e.g. kept paused) pending separate discussion?

5. Next Steps:

  • Gather community feedback and delegate input.
  • @BlockAnalitica to confirm all listed ARKs are at cap 0 and sign off the risk framing.
  • Iterate on scope based on discussion.
  • Promote to SIPs SIP2.59.1 – 11 (ba-managed) and SIP7.3.1 – 2 (dao-managed) — with per-Fleet specifications.

Tagging @Recognized_Delegates for you input.

–jensei

2 Likes

When will the paued-vault reopen?

Thanks for the proposal @jensei, I am supportive of removing ARKs whose deposit caps have already been set to 0. Their prompt removal will ensure the exploit is not replicated on any previously deprecated vaults.

Supportive of this proposal. As a depositor in LazyVault_LowerRisk_USDC_2 (Arbitrum) — allocation is 99% Sky sUSDC plus a small idle buffer, and I can confirm the other 10 listed arks (Fluid, Morpho variants, Aave V3, Compound V3, Gearbox) all show 0.00 allocated on my end too — I’d flag on the “Exclusions” question that there’s no technical reason from what I can see to hold this fleet back from the current round. Happy to be corrected if BlockAnalitica’s review finds otherwise, but wanted to share the depositor’s-eye view on why timely inclusion matters here.