Summer.fi's $6M Lazy Summer Exploit: When a Donation Broke the Vault Math

TL;DR

On July 6, 2026, an attacker drained about $6 million from Summer.fi's Lazy Summer Protocol, the automated USDC yield vaults the platform runs on Ethereum. No private key was stolen and no admin function was abused. The attacker borrowed a roughly $65.4 million flash loan, deposited most of it into a FleetCommander vault, then donated a separate strategy token straight into the vault's underlying Ark. That donation inflated the vault's totalAssets(), which lifted the share price, and the attacker redeemed the same shares for about $70.9 million. After repaying the loan, the roughly $6 million spread was the take, swapped to DAI on Curve and moved to a wallet the attacker controlled. Security firm Blockaid flagged the activity first, with PeckShield and CertiK confirming, and Summer.fi's guardians paused every vault across the protocol. This is a textbook ERC-4626 donation inflation attack against a live yield vault, and it is a code bug an audit and a single invariant test would have caught.

What Happened to Summer.fi's Lazy Summer Vaults?

Summer.fi runs an automated yield product called the Lazy Summer Protocol. Users deposit stablecoins, and the protocol routes that capital across external lending markets to chase yield without the user clicking through each move. The Block was among the first to report the incident, with analysts pointing at a flash loan attack within hours.

The affected vault was LazyVault_LowerRisk_USDC, a USDC vault managed by Block Analitica. That naming matters. This was the conservative, lower-risk product, the one a cautious depositor would pick. The attack did not need a exotic corner of the protocol. It needed the ordinary deposit and redeem path plus one accounting assumption that turned out to be false.

The loss landed on a small base. Summer.fi held roughly $22 million to $25 million in total value locked at the time, so the roughly $6 million taken was close to a quarter of everything in the protocol. Its SUMR token fell more than 18 percent as the news moved.

How Did the Vault Accounting Exploit Work?

Every ERC-4626 vault answers one question on every deposit and every withdrawal: how many shares is a deposit worth, and how many assets is a share worth. That answer comes from two numbers, the total shares outstanding and the vault's totalAssets(). Divide one by the other and you get the price per share. Deposit assets, receive shares at that price. Redeem shares, receive assets at that price. The math is only as honest as the totalAssets() figure feeding it.

Summer.fi's vaults do not hold idle stablecoins. A contract called FleetCommander parks the deposits into strategy modules the protocol calls Arks, each Ark plugged into an external venue for yield. To know how much the vault is worth, FleetCommander sums what its Arks report holding. CryptoSlate laid out the moving parts: FleetCommander manages deposits and withdrawals, the Arks run the strategies, a RAFT module harvests rewards, and keeper agents rebalance inside limits the protocol sets. It is a lot of automation stacked between the depositor and the yield.

The flaw the attacker found sits in that summing step. FleetCommander counted the assets in an Ark by reading a balance, and that balance could be changed by anyone willing to send tokens to it. So the attacker did exactly that.

According to CoinMarketCap's writeup, the attacker had accumulated a position in the Silo: Varlamore USDC Growth vault in advance, then donated those assets to the Ark between transactions to skew the figures FleetCommander relied on. A donation here means a plain transfer, no deposit call, no shares minted. The Ark's counted balance jumped. FleetCommander's totalAssets() jumped with it. The price per share jumped. And the shares the attacker had just minted with a flash-loaned deposit were now redeemable for far more than they paid.

The whole thing lived inside a single transaction. The Defiant noted that the exploit relied on legitimate protocol functions, the ordinary deposit, redeem, and withdrawFromArks calls, rather than any compromised credential. Nothing was hacked in the sense of a broken cryptographic control. The contract followed its own rules perfectly, and those rules were the bug.

The Attack, Step by Step

$6M or $70.9M? Reconciling the Figures

The headline number is $6 million. Read past the headline and the sums moving through the vault are an order of magnitude larger, which is where most recaps get sloppy. Treat the figures as three separate things.

The gross borrowed was about $65.4 million, the flash loan CertiK sized in its alert. The gross redeemed was about $70.9 million, the amount pulled back out of the vault. CoinMarketCap reconciled the flow directly: the attacker borrowed roughly $65.4 million, deposited roughly $64.8 million, and by distorting totalAssets() redeemed roughly $70.9 million, netting about $6 million.

The net kept, the only figure a depositor should care about, is the roughly $6 million spread between what went in and what came out, banked after the flash loan was repaid in the same transaction. Cyvers and CertiK pinned that net at about $6 million, denominated in DAI, which fits the exit: the take was swapped to DAI on Curve and sent to the attacker's own address.

We trust the roughly $6 million net figure because it is the one three independent firms converged on and it matches the on-chain settlement in DAI. The $70.9 million and $65.4 million are real, but they are gross flows inside one atomic transaction, not stolen funds. Anyone reporting a $70 million hack is reading the redemption leg and missing the loan repaid against it. When a protocol's whole TVL is around $22 million, a real $70 million theft is not even arithmetically possible.

Why Was totalAssets() the Real Hole?

The single overlooked control is the one that decided how the vault valued itself. FleetCommander trusted a token balance it did not mint and did not control. Any address could push assets into an Ark, and the accounting would treat that gift as real yield belonging to existing shareholders, then let a redeemer walk out with the inflated value.

This is the ERC-4626 donation attack, sometimes called an inflation attack, and it is old enough to be documented in the standard's own security notes. The EIP-4626 specification calls out that implementations must account for the case where a vault holds more underlying assets than its recorded state expects, precisely because a direct transfer can move the share price. The canonical mitigation, virtual shares or a decimals offset, exists because this class of bug is expected, not novel.

What made Summer.fi a rich target was the layering. CryptoSlate's framing is the honest one: the more invisible the yield machinery becomes, the more it matters to show where automation stops and user exposure begins. A depositor into LazyVault_LowerRisk_USDC was trusting a chain of contracts, the FleetCommander accounting, the Ark strategy code, the keeper rebalancing, and the emergency controls, to all agree on one thing, what a share is worth. Break the weakest link, the balance read, and every layer above it faithfully computed the wrong answer.

What Does This Generalize To?

Donation inflation is not a Summer.fi problem. It is a pattern that reappears anywhere a contract prices itself off a value an outsider can move for free.

The failure is the same shape as a price oracle reading a spot pool that a flash loan can shove around for one block. It is the same shape as a lending market that values collateral off a manipulable reserve, the class we wrote about in why reserve manipulation is not dead. It rhymes with the Kelp DAO incident, where one configuration assumption broke the accounting across a DeFi integration. And it sits next to the automated systems we covered in the Jaredfromsubway MEV bot honeypot, where an autonomous agent was fed a reality that was individually valid on-chain and catastrophic in aggregate.

The common thread across all of them: an automated system took an external, attacker-controllable input as ground truth. A share price, an oracle read, a reserve ratio, a pool balance. In each case the manipulated input was legitimate at the level of a single call. The attack was in the aggregate, and the aggregate is exactly what an automated vault is built to stop watching.

Operator Takeaways: Controls That Stop Donation Inflation

1. Account internally, do not read raw balances. Track a stored accounting variable that only changes on deposit, withdraw, and harvest. A strategy contract that computes its worth from token.balanceOf(address(this)) will count any donation as real. That single design choice is the whole bug.

2. Ship the ERC-4626 inflation mitigation by default. Virtual shares or a decimals offset make share-price manipulation economically pointless. This is documented in the standard and in every major vault library. There is no reason to deploy an ERC-4626 vault without it in 2026.

3. Write the donation invariant test, then fail the build on it. One property test: transferring any asset directly to any strategy contract must not change any user's redeemable value. If that test goes red, you found the exploit before an attacker did. If you never wrote it, you shipped blind.

4. Bound single-transaction flows. A deposit and a redeem of the same shares in one transaction, or a redemption that exceeds a sane fraction of TVL in one block, should be blocked or at minimum flagged. A vault holding $22 million has no honest reason to settle a $70 million redemption in one call.

5. Alert on step changes in totalAssets() and price per share. A jump in a vault's totalAssets() or share price inside one block, with no matching harvest, is an anomaly with a very short list of causes. This is the observable that eventually caught this attack. It fired, just after the money left.

6. Scope what keepers and Arks can touch. Automated rebalancers routing capital across Curve and Morpho need explicit bounds. A strategy contract that will count any token sent to it, combined with an automation layer that reacts to balances, is an open door with a greeter.

Where Does Security Actually Catch This?

Be honest about which layer stops which attack, because it is the difference between a marketing line and useful advice.

This was a code and logic bug. The fix lives before deployment. A human audit that checks ERC-4626 accounting against the donation class, guided by a disciplined smart contract audit checklist, or an automated scan like SigIntZero's Sentinel, flags a vault that prices itself off a mutable balance and never mints against a donation. An invariant test suite refuses to compile the belief that a free transfer cannot move the share price. Full audits and formal invariant work are where this specific exploit dies, and we will say that plainly rather than pretend monitoring was the answer.

Runtime monitoring is the seatbelt, not the brakes. It is worth naming what actually happened in the wild: Blockaid, PeckShield, and CertiK all detected the anomaly on-chain, which is exactly what runtime monitoring is for. The catch is timing. Those alerts landed after the roughly $6 million had already moved and after Summer.fi's guardians had to pause the vaults reactively. A monitoring rule watching for a single-block totalAssets() jump, or a same-transaction $65 million-in and $70.9 million-out pattern, shrinks that window from after the drain to as it happens, which is often the difference between a paused vault and an empty one. That is where Tripwire, SigIntZero's runtime monitoring layer, earns its place, as the layer that shortens the blast radius of the bug your audit missed, not as a substitute for the audit.

The takeaway for anyone running a vault: get the accounting reviewed against the donation class before you deploy, and monitor the share price for impossible moves after you do. One prevents this. The other keeps it from being total.

Frequently Asked Questions

What is an ERC-4626 donation or inflation attack? It is an attack against a tokenized vault that prices its shares off the assets it appears to hold. An attacker transfers, or donates, assets directly to the vault or its strategy contract without going through a deposit, so no new shares are minted. The vault's assets go up while its share count stays flat, which inflates the price per share. The attacker then redeems shares they already hold for more than they paid. The ERC-4626 standard documents the class and the standard mitigation is virtual shares or a decimals offset.

Did Summer.fi lose its private keys or get its admin compromised? No. Multiple analysts confirmed the attack used legitimate protocol functions, the ordinary deposit, redeem, and withdraw calls, not stolen credentials or an admin takeover. The vulnerability was in how the FleetCommander contract counted its own assets, which is a logic flaw, not a key compromise.

How was only $6 million stolen if the flash loan was $65 million? The flash loan and the redemption are gross flows inside one atomic transaction. The attacker borrowed about $65.4 million, deposited about $64.8 million, and redeemed about $70.9 million, then repaid the loan in the same transaction. The roughly $6 million net kept is the spread between the redemption and the deposit. It is the only figure that represents stolen funds.

Which vault was affected and which assets were involved? Reporting names LazyVault_LowerRisk_USDC, a USDC vault managed by Block Analitica, as the affected product. The attacker used a pre-accumulated position in the Silo: Varlamore USDC Growth vault as the donated asset, and the proceeds were swapped into DAI on Curve before being moved to the attacker's wallet.

Could an audit have caught this before deployment? Yes. Donation inflation is a known, documented ERC-4626 failure class, and a review focused on how the vault computes totalAssets(), backed by a single invariant test that a direct transfer cannot change redeemable value, would have surfaced it. This is the kind of bug audits and invariant testing exist to find.

Sources / References

• CoinDesk: DeFi protocol Summer.fi halts Lazy Summer vaults after $6 million exploit
• The Block: Summer Finance exploited for $6 million; analysts point to flash loan attack
• The Defiant: Summer Finance drained of $6M in flash loan exploit
• CoinMarketCap: Summer Finance loses $6M in flash loan vault exploit
• ForkLog: DeFi protocol Summer.fi hacked for $6 million
• Metaverse Post: Summer.fi suffers $6M DeFi exploit after alleged flash loan manipulates vault accounting
• CryptoSlate: Summer.fi exploit shows AI automation now sits above DeFi smart contract risk
• EIP-4626: Tokenized Vault Standard