Analysis of the Governance Attack Attempt on Lazy Summer

[blockful]

Intro

In early April, Lazy Summer’s governance faced an attempted attack, which was blocked by the DAO’s Guardians.

We wrote a report going in depth on the attack, explaining the vectors, the consequences had it succeeded, and potential improvements to Lazy Summer.

The Attack

A proposal titled "Revoke Old V1 Roles and Cleanup for V1->V2 Finalization" was submitted to Lazy Summer governance.

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.

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.

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.

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.

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 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.

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.

Jensei, 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, 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.