# How $40M Were Almost Stolen from Lazy Summer *It’s not only treasuries that can be stolen in DAOs.* By [blockful blog](https://paragraph.com/@blockful) · 2026-04-15 security, daos, defi --- A [proposal titled "Revoke Old V1 Roles and Cleanup for V1→V2 Finalization](https://www.tally.xyz/gov/lazy-summer-dao-official/proposal/20187383025022346489297914643072678675588347037594683824379448703234496405235)" was submitted to Lazy Summer this week. Behind twelve on-chain calls dressed as post-migration maintenance, **one line would have handed a plain, anonymous wallet the master key to a protocol managing $40 million in user funds across three chains.** The proposal was caught and canceled, thanks to the coordinated response of the Lazy Summer Guardian members, who identified the attack and moved to stop it before it reached execution. But it was closer than it sounds. Background: What is Lazy Summer ------------------------------- [Lazy Summer](https://summer.fi/) is a multi-chain yield optimization protocol. Users deposit into vaults (called Fleets), which allocate capital across a set of yield strategies (ARKs): Morpho, Aave, Fluid, and others. The protocol was managing roughly $40M in TVL across Ethereum, Base, Arbitrum, and Sonic. The entire access structure of the protocol flows through a single contract: the `ProtocolAccessManager` (`0xf389BCEa...`). Think of it as the master key for the building. It defines who can do what: rebalance a vault, onboard a new strategy or trigger emergency procedures. At the top of this hierarchy sits `GOVERNOR_ROLE`. Whoever holds it can grant or revoke any other role in the system. It is the only role that requires no second check. Governance decisions flow through a `summerGovernor` contract (OZ Governor with TimelockControl) and a `SummerTimelockController` with a 48-hour delay before execution. The Timelock uses the standard OpenZeppelin role model: `PROPOSER_ROLE` to schedule operations, `CANCELLER_ROLE` to abort them. Timeline -------- In November 2025, Lazy Summer DAO finalized its transition from Governance V1 to V2. The Foundation multisig, which had been added as a co-governor during the transition, formally stepped back. Governance V2 powered, by locked SUMR tokens, became the sole decision-making layer. In February 2026, SIP0.2 passed. It created a Guardian Module with emergency risk controls — a tightly scoped role that can cancel any proposal at any stage, without requiring quorum or voting power. The design intent was clear, the DAO needed a last-resort protection In April 2026, Proposal ID `20187383...235` was submitted to the `summerGovernor` on Base under the title "SIP5.31: Revoke Old V1 Roles and Cleanup for V1→V2 Finalization." The proposal carried 12 on-chain calls targeting 3 contracts, structured to replicate its effects on Ethereum and Arbitrum via LayerZero. The proposer held 10.001 $SUMR - just one token above the quorum threshold of 10.000 $SUMR. At the token price at the time, this means the attacker was positioned to drain $40M. It was canceled before it reached execution after Guardian members identified the malicious intent embedded in the calldata. Diving deeper into the proposal ------------------------------- We retrieved the full calldata via the Tally GraphQL API and decoded each function call against the deployed contract ABIs. Here is what SIP5.31 actually contained: ### Calls on the SummerTimelockController The `SummerTimelockController` is the protocol's mandatory waiting room. Every governance decision — once approved by vote — must pass through it before taking effect. It holds an enforced 48-hour delay during which an authorized party can still cancel the operation if something looks wrong. # Function Account Assessment 1 `revokeRole(CANCELLER_ROLE)` summerGovernor Removes the Governor's ability to cancel queued Timelock ops 2 `revokeRole(EXECUTOR_ROLE)` summerGovernor Low impact — executor is already `address(0)` 3 `revokeRole(PROPOSER_ROLE)` Foundation Multisig Legitimate V1 cleanup 4 `revokeRole(CANCELLER_ROLE)` Foundation Multisig Combined with #1: no address retains CANCELLER\_ROLE 5 `revokeRole(DEFAULT_ADMIN_ROLE)` Foundation Multisig Legitimate V1 cleanup 10 `grantRole(PROPOSER_ROLE)` summerGovernor Legitimate: ensures V2 Governor can schedule ### Calls on the ProtocolAccessManager The `ProtocolAccessManager` is the master access control contract for the entire protocol.Every permission in the system flows through it. At its top sits `GOVERNOR_ROLE`: whoever holds it can grant or revoke any other role instantly, without any delay. # Function Account Assessment 6 `revokeDecayControllerRole` summerGovernor Removes Governor's control over token decay parameters 7 `grantGovernorRole` SummerTimelockController Legitimate: Timelock needs GOVERNOR\_ROLE to execute **8** `grantGovernorRole` `0xb0f5873f...` **ATTACK: unknown EOA receives GOVERNOR\_ROLE** 9 `grantDecayControllerRole` SUMR Token Operational: token manages its own decay ### Cross-chain replication via LayerZero Lazy Summer operates across multiple chains. Its governance, however, lives on Base, where proposals are voted on and executed. To make governance decisions take effect on Ethereum and Arbitrum as well, the protocol uses LayerZero: a cross-chain messaging protocol that forwards the same on-chain calls to other networks after a Base approval. Calls #11 and #12 are exactly that — a mirror of the first ten calls, dispatched automatically to Ethereum and Arbitrum the moment the Base proposal executes. # Destination Action 11 Ethereum (`dstEid=30101`) Replicates calls 1–10 on Ethereum 12 Arbitrum (`dstEid=30110`) Replicates calls 1–10 on Arbitrum The important insights here are: * Call #8 grants `GOVERNOR_ROLE` on the `ProtocolAccessManager` to `0xb0f5873f33b540f4e710404a730aa6a62c6118f2` - a plain EOA with no code, no documented role in the protocol, and no meaningful transaction history. * Calls #1 and #4 together eliminate every holder of `CANCELLER_ROLE` in the Timelock, with no replacement. Call #10 only restores `PROPOSER_ROLE` — not `CANCELLER_ROLE`. * Calls #11 and #12 are not decorative. They propagate the same role grants to Ethereum and Arbitrum via LayerZero, meaning a single governance approval in Base would have compromised the protocol across all its deployed chains simultaneously. The cognitive attack surface ---------------------------- **The proposal contains 10 legitimate actions and 2 malicious ones**. A reviewer who confirms that calls #3, #4, #5, #7, and #10 are correct - and they are - is primed to trust the rest of the package. The pattern is structurally identical to a SQL injection embedded in an otherwise valid query. The malicious payload hides inside context that is supposed to be safe. The title does the rest. "V1→V2 cleanup" is exactly what the DAO expected to see at this stage of its governance lifecycle. The Foundation multisig did need its roles removed. The Governor did need their `PROPOSER_ROLE` confirmed. The proposal reads as institutional hygiene - until you decode every call individually. What would have happened ------------------------ With `GOVERNOR_ROLE` on the `ProtocolAccessManager`, the attacker could have acted immediately - no Timelock, no delay, no governance vote required. The first moves would have been straightforward: 1. Grant `CURATOR_ROLE` over any `FleetCommander`: alter allocation caps, buffer thresholds, strategy composition. 2. Grant `COMMANDER_ROLE` over any ARK: directly control deposits and withdrawals for individual yield strategies. 3. Grant `GUARDIAN_ROLE` to themselves: acquire the ability to submit governance proposals without holding any SUMR. 4. Revoke `GUARDIAN_ROLE` from existing guardians eliminate the only emergency brake. The second-order effect is worse. With no `CANCELLER_ROLE` holder left in the Timelock after calls #1 and #4, any new malicious operation queued in the Timelock could not be canceled by the DAO. The DAO would have been able to schedule a fix, but not abort the damage being done in parallel. Chain TVL at risk Exposure Ethereum $34.6M Replicated via LayerZero Base $4.6M Primary attack chain Arbitrum $729K Replicated via LayerZero **Total** **$39.92M** The antidote: Guardian cancellation ----------------------------------- The `summerGovernor` implements a non-standard exception in its cancellation logic: function cancel(...) { address proposer = proposalProposer(proposalId); if ( _msgSender() != proposer && getVotes(proposer, block.timestamp - 1) >= proposalThreshold() && !isActiveGuardian(_msgSender()) // guardian bypasses all restrictions ) { revert SummerGovernorCannotCancelProposal(...); } return _cancel(...); } Any address with an active `GUARDIAN_ROLE`, checked live against the `ProtocolAccessManager` via `isActiveGuardian()`, can cancel any proposal at any stage before execution. **This is the mechanism that stopped SIP5.31.** The Guardian members coordinated to identify the proposal, decode its intent, and execute the cancellation before execution became possible. The response required both technical capacity and human coordination under time pressure. J**ensei, from Lazy Summer team and one of the Guardians, identified the attack together with Chris** (also from the Lazy Summer team). He described the moment: _"I wrote to Chris, as we discovered the proposal together, to send the statement once I get it_ 😃_"_ The critical observation is that **this defense only existed because of a prior governance decision**. [SIP0.2, approved in February 2026](https://gov.summer.fi/dao/proposal/108093388136831773407292946235331649189762991144555290509377111240682330256900), was the proposal that established the Guardian Module. Without it, the cancellation path would not have been available, and the 48-hour Timelock window would have been the only line of defense, a window the proposal itself was designed to exploit by removing all `CANCELLER_ROLE` holders before execution. Preventing it ------------- The industry standard for governance security tends toward reactivity: something goes wrong, a patch is applied. **Lazy Summer's Guardian Module is a counter-example, because it was built before it was needed.** It is also worth noting the structural difference between the Governor that was attacked and the one currently in use. Governor V1, the target of SIP5.31, used plain $SUMR as its governance token. With a proposal threshold of just 10.000 SUMR, the economic barrier to submit a malicious proposal was approximately $20. Governor V2, the current system, uses stSUMR: a staked, locked version of the token. This significantly raises the cost and time required to accumulate governance power. Lazy Summer team will also **increase the quorum in Governor V2 and formally disconnect from Governor V1** in the coming weeks, eliminating the attacked surface. --- *Originally published on [blockful blog](https://paragraph.com/@blockful/lazy-summer-attack)*