Lazy Summer USDC Vault Exploit Post-Mortem: What Happened and What Comes Next

On July 6, 2026, an attacker manipulated the share price of two Lazy Summer Protocol USDC vaults on Ethereum mainnet and extracted approximately $6.04 million of depositor value in a single atomic transaction.

This post explains what happened, walks through the response actions by the Guardian Multisig, the Lazy Summer Foundation ("Foundation"), SEAL 911, and other parties, gives a full timeline, and sets out what the Lazy Summer DAO, the Foundation and Summer.fi, as front-end, are doing next.

The onchain analysis behind this report has been reproduced independently by multiple contributors against the transaction trace, subgraph, and contract source. Where something is still being finalized, it will be stated.

In this post, you will read about:

1. What happened
2. How the exploit worked
3. Pre-positioning: how the attacker prepared the manipulated position
4. Scope and impact
5. Review of Guardian Multisig actions
6. Timeline of happenings
7. Fund status and recovery
8. What the Lazy Summer DAO is evaluating now
9. What Summer.fi is focusing on next
10. In Conclusion
11. FAQ

A deeper technical post-mortem can also be found here: https://gist.github.com/halaprix/52bd5e32b35be100dc40ba30539e4169

1. What happened

Early on July 6, blockchain security monitors flagged a live exploit against the Lazy Summer Protocol. Blockaid was first to raise the alarm, with CertiK, PeckShield, and Cyvers publishing alerts shortly after and initially reporting roughly $6M drained. Our own tracing puts the figure at approximately $6.04M across two vaults, extracted in a single atomic transaction.

The attacker exploited how a vault’s net asset value (NAV) is calculated across its underlying Arks. This allowed them to deposit (“donate”) tokens into a Silo market that had been halted after the November 2025 events, with new deposits restricted through caps. The tokens used for this (Silo “Varlamore USDC Growth” vault tokens) had continued to report an onchain value inherited from before the November 2025 Stream Finance collapse: their underlying valuation never corrected, and interest kept accruing on the USDC stranded in that market. Depositing these tokens made the vault appear to have gained enormous value, pushing up its NAV and therefore its share price. The attacker then used their flash-loaned position to withdraw the vault’s real, available USDC, leaving only the non-withdrawable balance behind. This was not a temporary, oracle-style price trick that unwinds at the end of a transaction. The Arks in question had been paused with deposit caps following the 2025 issues, but had not been fully removed from the fleet’s NAV calculations as intended. The operation was primarily flash-loan-funded and required little upfront capital relative to the size of the extraction.

Two vaults were affected:

• LazyVault_LowerRisk_USDC (0x98C49e13…EcF17): net loss ≈ 5.64M USDC
• LazyVault_HigherRisk_USDC (0xE9cDA459…cB06): net loss ≈ 0.40M USDC

A widely shared side-effect of the manipulation: the lower-risk vault's displayed APY briefly spiked to roughly 2.08 million percent. That figure was an artifact (our subgraph observed the one-block NAV jump and annualized it); not real yield.

Importantly, this was not a compromised-key or admin-privilege event, and the Guardians did not and cannot move user funds. Independent analysis published in several social networks attributes the loss to a single-transaction NAV manipulation: the attacker donated an over-valued token into an Ark that had been capped for offboarding but was still counted in the vault's share price, then redeemed at the inflated price. The extraction itself was atomic (a single transaction) even though the position it relied on had been accumulated over the preceding months (see §3). The attack ran through an attacker contract (bytecode), while the affected Protocol contracts were themselves verified (human-readable) and behaved exactly as written. The gap was not a coding bug in those contracts, it was the offboarding window that left an impaired, still-active Ark priced into NAV.

2. How the exploit worked

Lazy Summer vaults are automated ERC-4626 vaults. A FleetCommander contract sits above a set of strategy adapters called Arks, and the vault's share price is derived from the total value those Arks report.

The exploit turned on how that share price is formed — and on what can move it:

• Share price is computed from totalAssets() — the sum of every active Ark's reported totalAssets().
• An Ark's totalAssets() credits any tokens donated (transferred) directly into it, at the Ark's own valuation, without minting new shares.

So donating an over-valued token into any Ark that is still in the active set raises the vault's totalAssets(), and therefore its share price, with no real assets behind the increase. The attacker then redeems at that inflated price, and the payout is assembled from the vault's genuinely liquid positions (the buffer plus liquid Morpho, Spark, and Sky Arks ) from other depositors' capital.

One clarification, because several early third-party writeups framed this as a totalAssets()-vs-withdrawableTotalAssets() accounting bug: it was not. Redemptions drain Arks in ascending order of size and stop once the requested amount is covered, so the large, manipulated Ark was sorted last and never withdrawn from at all, as its withdrawable balance is irrelevant to the payout. The manipulated Ark had zero withdrawable balance is a normal, by-design state for a market that is unwinding, and if anything it was protective: it stopped the attacker from also claiming the illiquid donated position. Pricing the active set from totalAssets() is the intended accounting; the failure was that an impaired Ark was still in that set.

Concretely, the attack ran as follows:

1. The attacker used flash loan to borrowed roughly 65M USDC plus additional stablecoin liquidity via flash loans, requiring no capital of their own.
2. They deposited ~64.8M USDC into the lower-risk vault, minting shares at the true price of ~1.0665 USDC/share and filling the vault to its cap.
3. They inflated the NAV through a donation by transferring an over-valued external position (Silo Varlamore USDC Growth tokens) into a Silo Ark. This Ark had its deposit cap set to zero and was in the process of being removed following the 2025 incidents, but the cleanup had not been fully completed. As a result, the donation increased the vault’s reported totalAssets() by roughly 9.5% without minting any new shares and without adding any withdrawable liquidity.
4. They then redeemed their shares at the now-inflated price of ~1.1678 USDC/share, paying out ~71M USDC while burning fewer shares than they had minted. The payout was assembled from the vault's real liquid positions (the buffer plus liquid Morpho, Spark, and Sky Arks) that is, from other depositors' capital.
5. The same technique was applied to both USDC vaults in the single operation. Notably, the sequence actually began with the higher-risk vault, to prime its buffer: a near-zero-cost deposit/withdraw round trip moved ~$398k of liquidity into the buffer, so the later inflated redemption could be paid from liquid assets. The Term deposit then did double duty: it minted the Term shares later donated into the HigherRisk Term ark, while routing the underlying USDC into LowerRisk’s buffer, where it was recovered during the larger LowerRisk drain. The attacker repaid the flash loans in full, swapped the proceeds to DAI, and exited, leaving the donated positions behind because they were the NAV / price-per-share lever, not the exit asset.

The aggravating factor: a capped-but-active Ark still counted in NAV

Donating a fairly-valued asset into an Ark is harmless: it raises totalAssets() by the asset's true worth and adds real backing, so a would-be manipulator only claws back their own donation, there is no free money. The exploit worked because the donated asset was drastically over-valued: the stale Silo "Varlamore" tokens were still credited near par by the Ark while being worth a fraction of that, so the donation inflated totalAssets(), and the share price, far beyond any real value added. The lever was the mispriced donation into an Ark still counted in NAV (not the Ark's withdrawable state), the inflated redemption was paid from the vault's other liquid Arks, never from the manipulated one.

The Ark was in that state because its per-Ark deposit cap (depositCap, zeroed via setArkDepositCap) had been set to 0 as part of offboarding. Zeroing the cap blocks new inflows (the rebalance validation reverts any move into a cap-zero Ark) but it does not remove the Ark from the FleetCommander's active set (getActiveArks()), and both totalAssets() and withdrawableTotalAssets() are summed over that active set. The Ark's now-manipulable valuation was therefore still counted in NAV and still moved the share price.

This is why the decommissioning process is the real lever. removeArk itself requires the deposit cap to already be zero and the Ark to hold no assets (_validateArkRemoval), so every offboarding necessarily passes through a temporary phase in which the Ark is capped to zero, still active, and still priced into NAV. That phase has to be handled deliberately: sweep and socialize the loss, or otherwise empty the Ark, then complete removeArk through governance and, as defense-in-depth, an Ark's contribution to NAV could be made more donation-resistant where the design allows (valuing boarded principal rather than a raw token balance; not every Ark fits this, since some distribute yield by minting new shares or by rebasing). The accounting itself is not the fix target: excluding capped-but-active Arks from pricing would deflate the share price for honest holders and force withdrawal freezes while legitimate markets unwind. The exposure is leaving an impaired, donatable Ark in the active set longer than necessary.

3. Pre-positioning: how the attacker prepared the manipulated position

This was not an opportunistic attack. The evidence points to an operation planned at least three months in advance.

Roughly three months before the exploit, the attacker funded a set of wallets, (all through the same funding path) a pattern consistent with one actor spreading activity across multiple addresses to obscure a large, deliberate accumulation. Those wallets were then used to accumulate the Silo "Varlamore USDC Growth" vault share tokens that would later be donated to the vault's Silo Ark to inflate the vault's NAV. This accumulation is exactly what made the attack possible: as noted above, those tokens still carried an on-chain valuation that had never been marked down after the November 2025 Stream Finance collapse, so building a large position in them gave the attacker a cheaply acquired asset that the vault's accounting would badly overvalue.

In short, the manipulated position was pre-positioned by the attacker themselves, not conjured within the exploit transaction. The precise mechanics of how the tokens moved between the funded wallets and into the attack contract are still being confirmed. What is clear now is that the operation had a long lead time. A useful signal both for attribution and for understanding that the stale external valuation combined with incomplete offboarding, not a single flash-loan trick, was the load-bearing condition.

4. Scope and impact

• The stolen USDC came from the vaults' real, liquid positions and buffers — that is, other depositors' capital. The vaults are left temporarily holding illiquid donated shares in place of the drained USDC.
• All vaults across the Lazy Summer Protocol were paused as a precaution, and deposit caps on the DAO-managed vaults were set to zero, while the root cause was confirmed and remediation prepared. This included vaults with no indication of exposure to the same vector.
• The Protocol's native token, SUMR, traded near $0.00193, down about 5.3% over the following hours.

A full onchain snapshot of vault positions is being conducted to establish, precisely and per-depositor, who was affected and by how much, so any remediation the DAO decides on can be allocated fairly and pro-rata. No final per-user figure will be published until that reconciliation is complete.

5. Review of Guardian Multisig actions

This was the first time the Guardian Module established under SIP0.2 (previously used to block a governance attack in April 2026) was used to pause vaults during a live exploit.

What the Guardian Module is

The Guardian Module is a narrowly scoped, community-controlled multisig (0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4) designed to act faster than a full governance cycle during high-severity events. It is an 8-signer multisig with a 6-of-8 signing threshold, deployed across Base, Ethereum, Arbitrum, and Sonic.

Its authority is deliberately constrained. Its only permitted actions are pausing vaults, overriding deposit caps (setting them to zero), and cancelling risky in-flight governance proposals. It cannot move user funds, onboard or offboard strategies, or tune parameters proactively. It is reactive only. No user funds were, or could be, moved by the Guardians during this incident.

What the Guardians did on July 6

Working from the security-firm alerts and the confirmed exploit transaction, the Guardians executed, in priority order:

1. Deposit caps set to zero: on both DAO-managed vaults.
2. Paused all Mainnet vaults: prioritized as the critical action, since the exploited vaults were on Ethereum.
3. Paused all Base vaults: the first Base transaction had to be superseded and resubmitted, and signers were directed to the corrected transaction.
4. Paused Arbitrum vaults.
5. Paused Sonic vaults.

A deeper action log report of the Guardian Multisig can be found here: forum.summer.fi

Before signing, signers independently verified that each queued transaction targeted only the pause and cap functions on the intended contracts, rather than trusting the batch blindly; appropriate diligence, given that one transaction interacted with the compromised vaults and triggered warnings in the signing interface.

Where the Guardians hit a limitation: HyperEVM

On HyperEVM, the pause transaction reverted: the Guardian multisig did not hold the guardian role on that chain (CallerIsNotGuardianOrGovernor). The Guardians therefore cancelled the proposed pause transaction and escalated to the Foundation to pause the two HyperEVM vaults through a different path.

The deposit caps were already set to 0, so it was not possible for the attack to take place on those vaults.

6. Timeline of happenings

All events July 6, 2026 unless noted.

Pre-incident context

• 30th of Oct 2025: Deposit Cap of the “Varlamore” Ark has been set to 0 . (tx)
• Nov 2025: The Stream Finance collapse leaves certain Silo “Varlamore” vault tokens reporting stale onchain value (their underlying valuation never corrected).
• 4th of Feb 2026: Guardian Module proposed and executed via SIP0.2.
• 8th of Apr 2026: Guardians cancelled a malicious governance proposal; first live use of Guardian authority.
• 6th of Apr 2026: The attacker funds a set of wallets, all through the same funding path; an early indication the operation was planned well in advance. (example tx)
  • Following weeks (9th of Apr): Those funded wallets accumulate the Silo “Varlamore USDC Growth” vault tokens; the stale-valued position later used to inflate the vaults’ NAV. (example tx)

Day of incident (The following times are in UTC)

1. [05:17 AM]: Shortly before the exploit attacker consolidates its pre-accumulated Silo "Varlamore" vault tokens into the attack contract, ready to be donated into the vault. (tx)
2. [05:17 AM]: Exploit transaction: Attacker flash-borrows ~65M+ in stablecoins and, across both USDC vaults (beginning with the higher-risk vault), deposits at the honest price, donates the stale-valued Silo position into the capped, zero-withdrawable Ark pending removal to inflate NAV ~9.5%, redeems at the inflated price, repays the loans, and exits with ~$6.04M in DAI. (tx)
3. [05:36 AM]: Blockaid flags the live exploit; and the team is alerted to it. (alert)
4. [06:42 AM]: Block Analitica freeze all deposits (setting Vault caps to 0) to affected Vaults. (tx)
5. [07:39 AM]: SEAL 911 are engaged and start to work with the Summer.fi team to understand the exploit and trace the source of the funds used to exploit the protocol.
6. [07:52 AM]: First Guardian transaction setup and all guardian signers are alerted. DAO Managed Vault caps and pause transactions are queued. (safe tx)
7. [09:48 AM]: An onchain message is sent to the exploiter address from the Lazy Summer Protocol deployer address asking to set up communications. (message)
8. [10:25 AM]: Guardian transactions executed, and deposit caps set to zero on both DAO-managed vaults; all Vaults on Ethereum and Base are paused as the critical first action. (tx)
9. [11:38 AM]: Guardian pauses Arbitrum and Sonic Vaults also, given the continued uncertainty over exactly what happened. Deposit caps were already zero on all Vaults on these networks, so the same attack vector was already blocked. (tx1, tx2)
10. [16:39 PM]: Lazy Summer Foundation Multisig executes transactions to sweep the Silo “Varlamore” Vault shares from the LowerRisk USDC Vault and transfer them to the Foundation Multisig, stopping the donated position from distorting reported NAV / share-price displays and socializing the loss across the LowerRisk Vault. (tx)
11. [17:16 PM]: Summer.fi reaches out to FixedFloat with addresses and transactions that were initially funded via FixedFloat.

7. Fund status and recovery

The attacker has since swapped a portion of the proceeds and routed them through Tornado Cash, the onchain mixer, via an intermediary wallet (0x46e0…eBa7). It signals limited intent to return the funds voluntarily. Once assets are swapped out of stablecoins and deposited into a mixer, direct onchain tracing breaks down. The Lazy Summer team and security partners are continuing to trace what is possible, and several external teams have offered assistance and introductions, which we appreciate.

For reference, the two attacker-controlled addresses at the center of the incident are the funder/beneficiary EOA (0x7BF7…BDCa) and the executor contract (0x0514…FC61). These are already public across security-firm reporting; we are publishing them here so the community and exchanges can flag associated activity.

Beyond the addresses above, we are holding back the finer details of our attribution and funding-source analysis so as not to compromise ongoing tracing or any work with law enforcement.

8. What the Lazy Summer DAO needs to evaluate now

With all Vaults across the Protocol currently paused and their deposit caps set to 0, the DAO will need to decide next steps: when to unpause, and how to deal with the Ethereum USDC Vaults affected by the exploit.

1. Right now, the exploiter continues to have shares in the two USDC Vaults. Governance should decide if it wants to exclude these from snapshots taken by the Lazy Summer team. If it does, it will then need to decide on the preferred way to return the outstanding capital in the Vaults (roughly $4M, much of it currently illiquid) to the affected users, as simply unpausing the Vaults is likely not an option.
2. How to handle the non-exploited Vaults. Given the other Vaults across Ethereum, and all Vaults across Base, Arbitrum, Sonic and HyperEVM are unaffected, Governance will need to decide the best course of action to enable these in a safe and secure way. Withdrawals are disabled while the Vaults remain paused, and it will take around 6 days to unpause the Vaults through Governance. It would likely also be necessary to remove any old, unused Arks from the Vaults.

Once the above are decided, it will then be up to the DAO Governance to decide on any other non-critical next steps, such as adjusting Guardian signer requirements and possible next steps for the protocol.

9. What the Foundation and Summer.fi are focusing on next

As the front-end and a supporting contributor to the DAO and Protocol, Summer.fi is actively assisting the Foundation in:

• Supporting root-cause confirmation and fund tracing with data and analysis, in coordination with SEAL 911, Blockaid, CertiK, PeckShield, Cyvers, and other partners.
• Reflecting the pause and incident status clearly in the UI, and propagating warnings into user dashboards, not only vault pages.
• Supporting the DAO in any technical matters that are required to help support redemptions and unpausing the relevant markets.
• Keeping communication channels open and transparent throughout, with no blocking or removal of community members on official channels.

In Conclusion

This was a sophisticated attack that occurred in a single atomic transaction, allowing no opportunity to detect it, or stop it before any funds were lost. There is evidence onchain that it was being planned for over 3 months, using multiple wallets to obscure the accumulation of billions of Silo “Varlamore” tokens needed to carry out the exploit.

This was not a fault with the Vault accounting logic, but a process that allowed older Arks/ markets to be left as active once they had been deactivated by having their caps all set to zero in the knowledge that they were no longer usable.

The reaction of Block Analitica and Guardians to quickly set the caps to 0 and pause the Vaults was commendable and stopped any other Vaults from potentially being exposed to copycat style attacks, but unfortunately had no effect on the main attack.

Over the coming days, the Lazy Summer DAO and governance will need to pick up and decide on the next steps, and Summer.fi will continue to support the Foundation, DAO and protocol where required. Summer.fi will also be providing further updates on behalf of the Foundation as and when it has more information.

FAQs

1. Were user funds moved by the team or the Guardians?
No. The Guardian Module cannot move user funds. Its only actions are pausing vaults, setting deposit caps to zero, and cancelling risky governance proposals. The value was taken by the attacker through the exploit.

2. Why were all vaults paused, not just the two that were hit?
The exposure came from an operational state that could exist in more than one vault (an Ark capped for offboarding but not yet removed, so still counted in NAV) rather than anything specific to one strategy. A protocol-wide pause and cap-to-zero was therefore the conservative choice while every vault is reviewed. Vaults will be reviewed and unpaused individually.

3. What happened on HyperEVM?
The Guardian role was not added to the HyperEVM network, so they could not pause these Vaults. However, these Vaults already had deposit caps set to 0, so new deposits through the normal vault flow were blocked and the same flash-loan deposit/redeem path was not available.

4. Will I be compensated?
Compensation is a Lazy Summer DAO governance decision. Discussion of reimbursement, if it happens, will likely take place in the Lazy Summer DAO forum.

Join us via Discord | Telegram | X/Twitter | Linktree

Disclaimer: Oazo Apps Limited functions solely as a front-end interface (Summer.fi) provider and does not act on behalf of any user. Oazo Apps Limited did not launch, nor does it operate or control, the Lazy Summer Protocol. The Lazy Summer Protocol is accessed through Summer.fi. Information provided herein is on behalf of the Lazy Summer Foundation for informational purposes only and does not constitute investment advice. Figures and root-cause statements are based on analysis available at the time of writing and are subject to revision. Users interact with the Protocol at their own risk. T&C for the use of Summer.fi apply.