Thank you to everyone who joined Community Call #16. This was not the call we planned a month ago. Following the July 6 exploit of two Lazy Summer USDC vaults, we dedicated the full session to the incident: what happened, how the response unfolded, and the governance decisions that now sit in front of the DAO.
Announcement: Community Call #16: July 6 Incident Review, Community Q&A & Next Steps
X Stream: Community Call #16: July 6 Incident Review, Community Q&A & Next Steps / X
I said in the announcement that I would rather face this openly with the community than go quiet, and this call was one part of that. Below is a full recap for everyone who could not attend.
What Happened: The Incident in Plain Language
Early on July 6, at around 05:17 UTC, an attacker executed a single atomic transaction against the protocol. Blockaid was the first to flag it live, with other security monitors publishing alerts shortly after.
Two vaults were affected (both USDC vaults on Ethereum mainnet (the Lower Risk and the Higher Risk USDC vaults)), with approximately $6.04 million taken from the vaults’ real liquid positions, meaning depositor capital.
Official SummerFi Post-Mortem Blog Post: Lazy Summer USDC Vault Exploit Post-Mortem: What Happened and What Comes Next
Technical Post-Mortem Article by @halaprix: Lazy Summer exploit - 07.06.2026 · GitHub
The most important facts up front, because these are the first questions on everyone’s mind:
- This was not a compromised key or an admin privilege event. The Guardians did not (and cannot) move user funds.
- This was not a coding bug in the vault contracts. The affected contracts were verified and behaved exactly as written.
- This was not opportunistic. Onchain evidence shows the attack was planned for at least three months.
Root Cause: A Donation Into a “Zombie” Arc
A quick architecture refresher: Lazy Summer vaults are ERC-4626 vaults. Each vault has a FleetCommander contract sitting on top of a set of strategy adapters (“arks”). The vault share price is derived from the total value the active arks report.
Here is the design detail that mattered: an ark’s reported value includes any tokens transferred or donated directly into it, valued at the ark’s own valuation, without new shares being minted. If someone donates a fairly valued asset, that’s harmless the vault gains real value. The attack only works if you can donate something the ark overvalues.
And exactly that existed. After the Stream Finance collapse in November 2025, certain Silo USDC vault tokens were left reporting a stale onchain value nearly worthless to acquire, but still credited near par by the ark.
The second half of the setup: that Silo ark had been in the process of being offboarded. Its deposit cap was set to zero back in late October / early November 2025, which blocks new deposits through the normal flow. But it was still counted in the NAV and therefore still moved the share price.
The Attack Mechanics
On July 6, in a single transaction, the attacker:
- Flash-borrowed roughly $65M+ in stablecoins from Morpho (zero fee, no capital of their own required).
- Deposited about $64.8M USDC into the Lower Risk vault at the honest share price, filling the vault to its cap.
- Donated their pre-accumulated stale-valued Silo tokens directly into the capped-but-still-active ark. This inflated the vault’s reported total assets by roughly 9%. The share price jumped from ~1.0665 to ~1.1678 with no real value behind it.
- Redeemed their shares at the inflated price, pulling out roughly $71M USDC, paid out of the vault’s genuine liquid positions (the buffer plus the liquid Morpho, Spark, and Sky arks): other depositors’ capital.
- Repaid the flash loan in full, swapped the profit to DAI, and exited.
The same technique hit the Higher Risk vault in the same transaction (in fact the sequence began there), using a near-zero-cost round trip to prime its buffer and routing funds through the term vault, so the same capital did double duty. The full mechanics are in the technical post-mortem (pasted above).
On the planning: roughly three months before the exploit (around April), the attacker funded a set of wallets through the same funding path and quietly accumulated the stale-valued Silo tokens over the following weeks. The position that inflated the NAV cost them on the order of $40,000 to acquire. Three blocks before the exploit, all of it was consolidated into the attack contract. Long lead time, deliberate obfuscation, and a manipulated position built well in advance.
One important correction, because some early third-party write-ups got this wrong: this was not a withdrawable-vs-totalAssets accounting bug. Redemptions drain arks from smallest to largest and stop once covered the manipulated ark was never even touched during the payout. Its zero withdrawable balance is a normal state for a market that is unwinding, and if anything it was protective. The accounting is by design.
The Response: Guardian Module in Action
This was the first time the Guardian module (established under [SIP0.2] and previously used in April to cancel a malicious governance proposal) was used to pause vaults during a live exploit.
Quick reminder of what the Guardian module is: a community-controlled 8-signer multisig with a 6-of-8 threshold, deployed on Base, Ethereum, Arbitrum, and Sonic. Its authority is deliberately narrow: it can pause vaults, set deposit caps to zero, and cancel risky in-flight governance proposals. It cannot move user funds, not during this incident, not ever.
Rough timeline of July 6 (all times UTC):
- 05:36 The exploit is flagged live by security monitors; the team is alerted.
- 06:42 @BlockAnalitica freezes all deposits to the affected vaults by setting caps to zero.
- 07:39 SEAL 911 is engaged to help understand the exploit and trace the funds.
- 07:52 The first Guardian transactions are queued and all signers alerted.
- 09:48 An on-chain message is sent to the exploiter asking to open communications.
- 10:25 Guardian transactions execute: caps to zero on both DAO-managed vaults, and all Ethereum and Base vaults paused as the critical first action.
- 11:38 Arbitrum and Sonic vaults paused as well, out of caution.
- 16:39 The Foundation multisig sweeps the donated Silo shares out of the Lower Risk vault, so the donated position stops distorting the reported NAV, socializing that loss across the vault.
A precise action-by-action timeline with transaction links is in the published post-mortem.
Two points of important context. First, there were some front-end issues with the Safe multisig that made signing take a bit longer than expected. The affected vaults already had deposit caps at zero, so the attack vector was already blocked at that point. Second, on what the pause actually achieved: the exploit itself was a single atomic transaction, so there was no window to detect or stop it before funds moved. The pauses were about preventing copycat attacks on any other vault that might have had a similar operational state. That is also why all vaults were paused protocol-wide, not just the two that were hit. The conservative move was to pause everything and review each vault individually.
First Responders: Block Analitica’s Perspective
@BlockAnalitica joined the call as effective first responders on the protocol side. @definikola gave a refresher on the curator role BA Labs holds: with the curator multisig they can set caps to zero which is what triggered the original offboarding process for these arks back in late October / early November last year.
Miller then walked through the morning of July 6 from their side:
- A team member saw the first alert tweet almost immediately (~7:00 CET) and flagged it internally.
- BA quickly verified the exploit on-chain, confirmed the ~$6M figure, and reassessed the transaction flow.
- They identified that the attacker needed a deposit to trigger the loop so, controlling only the parameters, they immediately set caps to zero on the two affected fleets to block any repeat round.
- Around 08:30 CET they extended caps-to-zero to all fleets in case a similar vector existed elsewhere, informed the Summer.fi team, and recommended the same for the DAO-managed vaults.
- The Guardians then froze withdrawals (something BA cannot do, the curator role can only block new deposits).
- BA deliberately held off publishing their own assessment until they had confirmation from the core developers, to avoid amplifying speculation.
Fund Status & Tracing
The attacker has since swapped a portion of the proceeds and routed them through Tornado Cash via an intermediary wallet. Realistically, that signals limited intent to return funds voluntarily, and once assets go through a mixer, direct on-chain tracing becomes much harder.
That said, tracing continues with SEAL 911 and other security partners, and several external teams have offered help. The two attacker addresses are published in the post-mortem so exchanges can flag activity.
Community FAQ
“Will I be compensated?” This is very much a Lazy Summer DAO governance decision, and no decision has been made yet, it is still very soon. What has been done: a full onchain snapshot of vault positions was taken at the moment of pause, so that whoever was affected, and by how much, is precisely known and anything the DAO decides on can be allocated fairly and pro-rata. No final per-user figures will be published until reconciliation is done. The reimbursement discussion will happen openly on the forum.
“Can I withdraw / use the protocol right now?” Withdrawals, like deposits, are disabled while vaults are paused. For the unaffected vaults, governance needs to decide on unpausing, and the governance path takes around 6 days to execute once initiated. Vaults will be reviewed and unpaused individually, not in one batch. For the two affected USDC vaults, simply unpausing is likely not an option, as around $4M of the capital remains in illiquid positions, governance needs to decide the right mechanism for returning it.
“Was the code audited? How did audits miss this?” The contracts behaved exactly as written. The accounting is by design and, importantly, correct changing it would hurt honest depositors.
@chrisb added important context here: the potential attack vector was not known in any way it was not surfaced in any audits, reviews, bug bounty submissions, or AI-assisted auditing. Setting deposit caps to zero was genuinely understood across the DAO as effectively disabling those arks (keepers attempting to deposit would always have reverted). In hindsight it is a process failure, but not one made with any knowledge that a risk to the protocol existed.
Next Steps: The Remediation RFC
@chrisb walked through the [RFC] posted the morning of the call. To be clear: this is one proposal of several that will need to come forward. This one focuses specifically on the two USDC vaults on Ethereum (Higher Risk and Lower Risk, curated by @BlockAnalitica) and on returning the remaining USDC to the users of those vaults as the first immediate priority.
Key elements:
The attacker still holds a share balance in both vaults. A snapshot was taken at the moment the vaults were paused (posted inside the RFC). Governance has the option to create a Merkle proof distribution that removes the attacker’s balances. The DAO presumably does not want to hand any more capital to the attacker. Because the Lower Risk vault has already had its losses socialized, the vaults cannot simply be unpaused: doing so would allocate some of the remaining assets to the attacker’s shares.
Distribution mechanism. The easiest path is a Merkle-proof distribution. Merkl (already used for SUMR rewards and staking distributions) is the tried-and-tested route, but by default carries a 2–3% fee, so we would need to ask them to waive it. The alternative is custom Merkle contracts built in-house, which has been done a number of times before. Community members are also welcome to propose their own approach.
Three polls are live in the RFC, open until Friday 11:00 UTC, so @Recognized_Delegates can give direction quickly:
- Remove the attacker’s address from the snapshot? Yes / No
- Use the proposed snapshot? Yes / No (with a suggested alternative in the comments)
- Distribute via Merkle proof? Yes, using Merkl if the fee is waived / Yes, but with custom contracts / No, propose another way in the comments
Once direction is given, the Labs company will build the relevant contracts and code, and the process will be promoted to a SIP with a clear formal specification. The rough execution path for the affected vaults: unpause the vaults within the vault structure, assign the keeper role to governance, request withdrawals from the relevant arks (these are all asynchronous-withdrawal arks which is exactly why they couldn’t be drained in the attack), and once that capital is reclaimed, a further governance vote sweeps the USDC into the Merkle distribution contracts.
The Higher Risk vault does not need its shares separately socialized, its balance has effectively self-corrected via the already-socialized Lower Risk vault (through the term ark).
Separate RFCs for unpausing the unaffected vaults will follow in the next day or so, possibly with certain arks removed prior to or during the unpausing stage.
Closing Thoughts
Two days before this call, an attacker who had been preparing for over three months found a gap and took roughly $6.04M of depositor value in a single transaction. There was no window to stop that transaction. But the vaults were paused, the vector was contained, the loss was quantified, two post-mortems are public and independently verified, and the tracing and recovery work continues.
The governance decisions on remediation and next steps start now, and they need everybody’s voice, whether you are a @Recognized_Delegates member, an affected depositor, or a community member. Rough ideas are welcome on the forum; they don’t need to arrive as polished proposals.
A big thank you to the Guardians, to @BlockAnalitica, to SEAL 911 and the security researchers, and to the broader community; including everyone who reached out with messages of support and offers of help. It is genuinely appreciated.
The forum thread stays open for every question we didn’t get to. Updates will keep coming as tracing and the snapshot work progress.
–jensei