Lazy Summer Protocol Exploit, July 6 2026: BA Labs Risk Curator Retrospective

Risk
1

Hey Lazy Summer community,

In an effort to bring transparency around the exploit that affected the Mainnet USDC fleets on July 6, 2026, BA Labs acting as the risk curator for the Lazy Summer Protocol, provides a report below to document the risk curation actions taken by BA Labs during the incident.

Summary

The exploit transaction that resulted in an approximate $6 million loss affecting the Mainnet USDC Lower Risk and Mainnet USDC Higher Risk fleets originated from a protocol-level NAV-accounting and offboarding issue, where capped but still-active (not delisted) ARKs remained included in FleetCommander share-price accounting.

The CURATOR_ROLE held by BA Labs, has limited capabilities including the management of the exposure parameters such as deposit caps, while it cannot remove ARKs from the active fleet set, alter NAV accounting, freeze withdrawals, or change protocol implementation, as this is done by governance.

The exposure to the ARKs used during the manipulation of the FleetCommander’s accounting of totalAssets() was set to zero by BA Labs over 8 months before the exploit, by setting the caps to zero, which is the only risk parameter related to the ARK exposure management available to the Risk Curator role:

As detailed below and in the official post-mortem by SummerFi, the exploit path relied on the continued presence of these ARKs within the protocol despite their allocation caps having been set to zero. Although capital exposure to the affected ARKs had been removed, the ARKs themselves remained available as the governance process required to complete their offboarding had not been finalized.

What Happened

Based on Summer.fi’s post-mortem, the exploit was a NAV manipulation involving externally transferred, stale-valued receipt tokens donated into capped but still-active ARKs.

The attacker used the same underlying accounting vector against both affected Mainnet USDC fleets, but through different arks:

  1. The attacker took a Morpho flash loan of 65.4M USDC and 1M USDT.

  2. In the Mainnet USDC Lower Risk fleet, the attacker deposited approximately 64.8M USDC, minting fleet shares at the pre-attack share price.

  3. The attacker used stale-valued Silo “Varlamore USDC Growth” vault tokens, which were externally transferred to the SiloV2 / SiloManagedVault ark. This increased the LR fleet’s accounted NAV even though the assets did not originate from the authorized fleet allocation flow and did not add equivalent realizable liquidity.

  4. Because the SiloV2 ARK’s totalAssets() is included in the LR fleet accounting sum, the stale-valued donated position inflated reported NAV and distorted share pricing.

  5. The attacker then redeemed LR fleet shares against the inflated accounting state, realizing the majority of the exploit profit.

  6. In the Mainnet USDC Higher Risk fleet, the same accounting vector affected the Term Finance ark. In the attack transaction, the attacker deposited approximately 29.517M USDC into the HR fleet and redeemed approximately 29.916M USDC, implying an estimated HR fleet loss of approximately 399.2k USDC.

  7. Across the full transaction, the attacker realized a profit of roughly $6.1M, repaid the flash loan, and swapped the remaining approximately 6M USDC to DAI via Curve.

The underlying cause appears to be the combination of an impaired, still-active ARK and fleet-level NAV accounting. A cap of zero prevents new authorized allocations through the fleet allocation flow, but it does not remove an ARK from the active fleet set or from NAV accounting. In this incident, externally transferred stale-valued receipt tokens were counted through active ARKs, inflating share price without adding equivalent realizable value.

For the full overview of the exploit path and timelines, please refer to the SummerFi’s official post-mortem and a technical post-mortem.

Timeline of BA Labs Actions

At 05:44 UTC, BA Labs identified an ongoing exploit on Summer.fi, reporting approximately $6M drained. By 06:13 UTC, BA Labs had confirmed anomalous deposit and withdrawal activity affecting the Mainnet USDC Lower Risk (LR) and Higher Risk (HR) fleets, visible on Etherscan, and began preparing emergency transactions from the risk multisig.

At 06:37 UTC, the first emergency transaction pausing deposits was executed on Mainnet (tx). The exploit operated as a repeated loop of deposits and withdrawals, with each iteration requiring the attacker to mint fleet shares via deposit, so pausing deposits immediately halted the attack loop. Deposit pausing and setting caps to zero are the full extent of actions available to BA Labs from the risk multisig. Freezing withdrawals falls under the remit of the protocol Guardians, who were notified in parallel and subsequently paused all fleets across supported networks, as documented in their transparency report.

Given that the exploit pattern suggested a smart-contract-level accounting issue rather than an issue isolated to a single ark, BA Labs decided shortly after to set caps to zero across all fleets as a precaution against the same loop being replicated elsewhere. These transactions were executed on Mainnet at 06:46 UTC and on Base at 06:47 UTC, setting deposit caps to zero on the Base Lower Risk EURC, USDC, and ETH fleets, among others. All other networks, including Arbitrum, HyperEVM, and Sonic, already had caps at zero as part of the ongoing fleet offboarding process. Additionally, BA Labs recommended freezing the DAO-managed fleets sharing the same architecture, and the Summer.fi team was informed of all actions as they were taken.

Risk Framework Context

Under the BA Labs risk framework, exposure limits are enforced via ark-level caps. In this instance, caps had already been set to zero on the affected SiloV2 ark in the Lower Risk USDC fleet and on the affected Term Finance ark in the Higher Risk USDC fleet. However, this exploit demonstrates that for this class of attack, a cap of zero does not eliminate all residual exposure while an ARK remains listed: Externally transferred assets whose reported ARK valuation materially exceeds realizable value can still distort fleet share pricing if the ARK remains active and included in NAV accounting.

BA Labs’ role as risk curator is focused on yield-source assessment, collateral exposure, liquidity, concentration, cap sizing, onboarding and offboarding recommendations, and the emergency actions available through the multisig with CURATOR_ROLE assigned. Protocol architecture, NAV-accounting logic, ARK removal, and withdrawal freezes are outside the direct control of the Risk Curator role.

Path Forward

As of this report’s publication, all fleets remain frozen. From a risk perspective, the issue appears to stem from capped but still-active ARKs remaining included in NAV accounting while holding assets whose reported value could diverge materially from realizable value.

The definitive root-cause analysis, design, and implementation of any fix fall under the remit of the Summer.fi team.

BA Labs will wait for the Summer.fi team to clarify the issue and adopt the corresponding mitigations, and will not propose raising caps on any fleet until those measures are implemented and verified.

Incident resolution and communications fall under the remit of the Summer.fi team and the Lazy Summer DAO. The Guardians have published their activity log covering the emergency pause transactions executed across Ethereum, Base, Arbitrum, Sonic, and HyperEVM in the Guardian Multisig transparency thread. BA Labs will coordinate with the Summer.fi team throughout.

We will follow up with any material updates as the post-incident review progresses.

1 Like