The strategy you offboarded is still in your NAV math.

On a recent ERC-4626 vault engagement, the sharpest High we wrote had nothing to do with the deposit path everyone expects us to stress. It lived in the exit path. The vault routed deposits across several sub-strategies, each with its own cap, and the team had built a clean offboarding flow: set a strategy's cap to zero, stop new allocation, wind it down. The code did exactly that. What it did not do was drop the offboarded strategy out of the totalAssets() roll-up.

So the strategy sat there. Zero cap, no new deposits, still counted. And whatever it held still moved share price. That is the whole finding: a component you have operationally decided is dead is still cryptographically alive in your NAV, and its balance is something an outsider can influence by transferring tokens straight into it. The share price of the entire vault becomes steerable through a leg the team stopped watching.

We treat this as the same bug family as classic ERC-4626 donation inflation, but the trigger is different and worse to catch. Donation inflation on an empty vault is a first-depositor problem you can reason about at launch. This one only exists after a governance action, weeks or months into the vault's life, when a strategy gets capped but not excised. No line of the deposit code changed. The attack surface opened during an ops procedure that most audits never model, because most audits end before the protocol has ever offboarded anything.

The remediation is one invariant, stated flatly: any strategy contributing to totalAssets() is either fully active or fully excluded, never a zero-cap zombie. Offboarding must remove the leg from the accounting set, not just fence off its deposits. And the deeper lesson for anyone shipping a vault: the decommission path deserves the same adversarial review as the onboarding path. It is code too. It runs against live TVL. It is exactly where the next person will look.

This is Block 01 in the wild, which is why it leads the issue. Summer.fi's Lazy Summer "Fleet Commander" vaults spread USDC across lending markets, each wrapped as an "Ark." One Ark had been set to a zero deposit cap during offboarding. It was never removed from the vault's totalAssets() calculation. Every ingredient from the finding above, sitting in a live $22M protocol.

What it verified correctly

Everything the auditors were told to check. Deposit caps enforced. No reentrancy. No broken access control on the privileged functions. No private-key compromise. The contracts behaved precisely as written. That is the uncomfortable part: there is no red line to point at in the deposit logic.

What it didn't

That a zero-cap Ark still contributes to NAV, and that its balance is donatable. The attacker spent roughly three months quietly accumulating stale-priced Silo vault tokens, donated them into the impaired Ark to inflate reported NAV, then redeemed shares against real liquid USDC. Redemption of ~$70.9M against a ~$64.8M deposit netted ~$6M, swapped to DAI on Curve. The flash loan supplied end-of-transaction liquidity. It was not the vulnerability, and reading it as a flash-loan hack sends you looking in the wrong file.

The test we'd have written

An invariant that share price cannot move by transferring tokens directly into any sub-strategy, run against every Ark including capped ones. In Foundry terms: snapshot convertToAssets(1e18), donate an arbitrary balance into a randomly selected leg, assert the share price is unchanged. The moment you include a zero-cap Ark in that leg set, the assertion fails and the finding writes itself.

// invariant: donating into ANY leg, active or capped,
// must not move share price
function invariant_donationResistance() public {
    uint256 pxBefore = vault.convertToAssets(1e18);
    address leg = allArks[seed % allArks.length]; // includes capped
    stableToken.transfer(leg, donationAmount);
    uint256 pxAfter = vault.convertToAssets(1e18);
    assertEq(pxBefore, pxAfter); // fails on the zombie Ark
}

Why it's the same class as the last three exploits

Because the contract was fine, and the loss came from the boundary around it. Week 01 through Week 03 traced this exact thread through keys: spend key, sign key, upgrade key. Summer.fi extends it one more notch, to a dormant accounting component. CertiK's H1 2026 numbers put credential and operational failures ahead of pure Solidity bugs by dollar loss. The audited surface keeps passing. The stuff just outside it keeps paying attackers.

The donation-resistance invariant above only catches Summer.fi if your handler can actually reach a capped strategy. Most vault fuzz harnesses build their leg set from active strategies at setUp() and never revisit it, so a strategy that gets capped mid-run silently drops out of the target list. That is the exact gap the exploit lived in. The fix is to source the leg set from the vault's own registry every call, including capped and paused legs, and to add a handler action that offboards a random strategy partway through the run so the "capped but present" state is reachable at all.

Point Medusa or Foundry's invariant runner at that expanded state space and let it interleave offboard, donate, and redeem. If share price ever moves off a direct transfer, you have the finding before the vault ever ships an offboarding. This is the fuzz-first, cover-the-exit-path pattern the Zealynx bench leans on, and it costs nothing but harness discipline.

# run the expanded invariant set with offboarding in the loop
forge test --match-contract FleetCommanderInvariants -vvv

Two Q3 audit slots remain open. If you are shipping a vault before September, get the scope in now at zealynx.io/audits. If you'd rather have Zealynx cover the audit directly, our Round 02 grants are open below.