# \[RFC\] Neutralize All Vaults to Withdrawal-Only Shells **URL:** \ **Category:** Request for Comment \[RFCs\]\ **Tags:** rfc, ark-offboarding, cleanup\ **Created:** [July 29, 2026, 3:41pm UTC](https://forum.summer.fi/t/rfc-neutralize-all-vaults-to-withdrawal-only-shells/897 "2026-07-29T15:41:49Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![jensei](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/jensei/32/69_2.png) [@jensei](https://forum.summer.fi/u/jensei)\ **Post date:** [July 29, 2026, 3:41pm UTC](https://forum.summer.fi/t/rfc-neutralize-all-vaults-to-withdrawal-only-shells/897/1 "2026-07-29T15:41:49Z")
> **Related:** [[RFC] Determining the Future Direction of Lazy Summer DAO](https://forum.summer.fi/t/rfc-determining-the-future-direction-of-lazy-summer-dao/868) & [[RFC] Operational Realignment for the Transition Period](https://forum.summer.fi/t/rfc-operational-realignment-for-the-transition-period/875) * * * ### 1. Summary: Following the July 6 exploit and the offboarding already executed under **SIP2.59.1 - 12** (BA-risk-managed) and **SIP7.3.1 - 2** (DAO-risk-managed), this RFC proposes the final step: **remove every remaining Ark from every Lazy Summer Vault, across all networks** , leaving each Vault as a clean, buffer-only ERC-4626 withdrawal shell until further future direction of the Lazy Summer Protocol is figured out. * * * ### 2. Context & Motivation: **What the exploit taught us about Arks.** The July 6 attack worked because an Ark that had been capped to zero for offboarding was still _registered_ on its Vault and therefore still counted toward share price. Zeroing a cap blocks new inflows but does **not** remove an Ark; removal is the substantive step. The SIP2.59.X / SIP7.3.X cleanup completed that removal for the legacy, dormant Arks. **Current state.** The affected Vaults are unpaused and withdrawable, deposit caps are at `0`, and the legacy Arks are gone. What remains is the set of still-registered Arks on each Vault. **Why remove all of them now.** The future of the protocol is uncertain and the Vaults are withdrawal-only. In that posture, every registered Ark is residual surface that serves no purpose: it is a live strategy leg. Reducing each Vault to a buffer-only shell makes it maximally simple, safe, and permissionlessly redeemable regardless of any front-end, the state the DAO wants these contracts in when the [Summer.fi](http://Summer.fi) UI sunsets on **August 31, 2026**. * * * ### 3. Proposal: **Goal:** Remove all Arks from all Vaults so that each Vault ends holding only its buffer/idle balance, with withdrawals available throughout. ##### Step 1: Publish a per-Vault Ark inventory. For every Vault, list the registered Arks, each Ark’s current allocation/balance, and its liquidity/exit profile (instant vs. queued, any lock or withdrawal-window constraints) ready for the followup SIP. ##### Step 2: Execute as minimal, per-network SIPs. - **SIP2.XX (ba-risk-managed)** for the BA-managed Vaults. - **SIP7.X (dao-risk-managed)** for the DAO-managed Vaults (`DAO_LazyVault_USDC_1`, `DAO_LazyVault_WETH_1`). - Batched per network where it makes sense, fully-decoded calldata published, consistent with the DAO’s stance that any wind-down proposal be trivially auditable. **Vaults in scope** | Vault | Network | Lane | | --- | --- | --- | | LazyVault\_HigherRisk\_WETH | Ethereum | SIP2.X | | LazyVault\_LowerRisk\_USDT | Ethereum | SIP2.X | | LazyVault\_LowerRisk\_WETH | Ethereum | SIP2.X | | DAO\_LazyVault\_USDC\_1 | Ethereum | SIP7.X | | DAO\_LazyVault\_WETH\_1 | Ethereum | SIP7.X | | LazyVault\_LowerRisk\_WETH | Base | SIP2.X | | LazyVault\_LowerRisk\_EURC | Base | SIP2.X | | LazyVault\_LowerRisk\_USDC | Base | SIP2.X | | LazyVault\_LowerRisk\_USDC\_2 | Arbitrum | SIP2.X | | LazyVault\_LowerRisk\_USDT | Arbitrum | SIP2.X | | LazyVault\_LowerRisk\_USDCe | Sonic | SIP2.X | | LazyVault\_LowerRisk\_USDC | HyperEVM | SIP2.X | | LazyVault\_LowerRisk\_USDT | HyperEVM | SIP2.X | | _LazyVault\_LowerRisk\_USDC (exploited)_ | _Ethereum_ | SIP2.X | | _LazyVault\_HigherRisk\_USDC (exploited)_ | _Ethereum_ | SIP2.X | * * * ### 4. Open Questions: - **Illiquid or constrained Arks:** does any Ark hold a position that cannot be cleanly exited to buffer (lockups, thin secondary liquidity, queued withdrawals)? If so, how should it be handled, e.g. wait, partial exit, or accept as-is? - **Batching:** per-network batches, or per-Vault SIPs for maximum auditability? - **Timing vs. the UI sunset:** should execution be targeted to complete before August 31 so the Vaults are left as clean shells while support is still available? - **Last-Ark edge cases:** for any Vault, does removing the final Ark have share-price or rounding implications for the remaining depositors that @BlockAnalitica should call out? - **Sequencing with tip-stream revocation:** the separate tip-stream proposal would revoke @BlockAnalitica tip stream. This Ark work should be completed under BA’s risk management _before_ that revocation lands how do we want to order the two? * * * ### 5. Next Steps: 1. Gather [@Recognized\_Delegates](https://forum.summer.fi/groups/recognized_delegates) feedback and the informal signal below. 2. Promote to minimal per-network **SIP2.X** / **SIP7.X** proposals with fully-decoded calldata. * * * ### 6. Informal Support Indicator A non-binding signal to gauge sentiment before any SIP: _Poll ([view on site](https://forum.summer.fi/t/rfc-neutralize-all-vaults-to-withdrawal-only-shells/897/1))_ * * * Tagging @BlockAnalitica for the risk assessment and [@Recognized\_Delegates](https://forum.summer.fi/groups/recognized_delegates) for feedback. –jensei