Related: [RFC] Determining the Future Direction of Lazy Summer DAO & [RFC] Operational Realignment for the Transition Period
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 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:
- Gather @Recognized_Delegates feedback and the informal signal below.
- 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:
- Support - remove all Arks and neutralize every Vault to a withdrawal-only shell
- Support - but only the BA-risk-managed-vaults
- Do not pursue
- Abstain / Need more information
Tagging @BlockAnalitica for the risk assessment and @Recognized_Delegates for feedback.
–jensei