Active

SIP0.3: Renew Guardian Module Mandate & Re-confirm Guardian Set


ID 108652...8521

ID 108652...8521

Proposed on: Jul 22nd, 2026

Proposed on: Jul 22nd, 2026

Result details
Current Votes

Quorum

62.07M of 42.72M

Majority support

Yes

For

62.07M

Against

0

Abstain

0

Actions

Type

Address

Details

Custom

0x4cEe...3274

sendProposalToTargetChain(..)

Custom

Account

0x4cEe...3274

Method

sendProposalToTargetChain(..)

Custom

0x4cEe...3274

sendProposalToTargetChain(..)

Custom

Account

0x4cEe...3274

Method

sendProposalToTargetChain(..)

Custom

0xf389...9694

setGuardianExpiration(..)

Custom

Account

0xf389...9694

Method

setGuardianExpiration(..)

Custom

0x4cEe...3274

sendProposalToTargetChain(..)

Custom

Account

0x4cEe...3274

Method

sendProposalToTargetChain(..)

Proposal

1. Overview:

This SIP renews the Guardian Module established under https://forum.summer.fi/t/sip0-2-establish-guardian-module-emergency-risk-controls/675, whose 180-day mandate expires on or around 9 August 2026. It extends the guardian expiration across all four supported chains via setGuardianExpiration, and re-confirms the guardian set agreed in principle during SIP0.2.

RFC: https://forum.summer.fi/t/rfc-operational-realignment-for-the-transition-period/875 Part B (poll B1/B1a). Polling is still open; this SIP is brought forward ahead of poll close because the mandate expires inside the standard governance cycle.

Conflict of interest: I am one of the eight guardians and a signer on the Guardian Safe. This proposal preserves a role I hold. Delegates should weigh it accordingly.


2. Motivation:

2.1 The mandate expires in ~18 days

SIP0.2 granted guardian powers with a 180-day expiration, executed on Base on ~10 February 2026. ProtocolAccessManager enforces MAX_GUARDIAN_EXPIRY = 180 days, so this was never open-ended by design; therefore it requires affirmative renewal by the DAO.

On expiry, isActiveGuardian() returns false and the module goes dark. Most consequentially, the DAO loses the ability to cancel in-flight malicious proposals: only "with expiry date" guardians hold that power, and only while unexpired.

2.2 The module is not theoretical, as it has already saved the protocol

In April 2026 a proposal titled "Revoke Old V1 Roles and Cleanup for V1->V2 Finalization" was submitted to Governance V1. Per blockful's analysis, it carried 12 onchain calls against 3 contracts, of which 10 were legitimate and 2 were malicious: call #8 granted GOVERNOR_ROLE on the ProtocolAccessManager to an undocumented EOA, while calls #1 and #4 eliminated every CANCELLER_ROLE holder in the Timelock with no replacement, disarming the 48-hour delay itself. Calls #11 and #12 replicated this to Ethereum and Arbitrum via LayerZero. The proposer held 10.001 SUMR against a 10.000 threshold, an economic barrier of roughly $20 to attempt seizing control of a protocol then managing ~$40M across three chains.

The guardian cancellation path was the only defence that worked, because the attack was specifically designed to neutralize the Timelock. The report's conclusion is the argument for this SIP in one line: that defence existed only because of a prior governance decision, made before it was needed.

2.3 Measured performance to date

From the https://forum.summer.fi/t/guardian-multisig-transparency-reporting-thread/787, time from transaction creation to execution:

DateActionResponse time
23 Mar 2026Post-Resolv precaution 6 markets capped to 0 (DAO-Risk-Managed USDC)54 min
08 Apr 2026Cancellation of the malicious Governance V1 proposal96 min
20 Apr 2026Post-Kelp caps to 0 on 4 ETH + 4 USDC ARKs41 min
20 Apr 2026Pause deposits, ETH DAO Managed Vault (withdrawals left active)42 min
19 May 2026Fluid Lite ETH Ark cap to 0 (explicitly non-critical)237 min

Four incidents, four responses inside 100 minutes at a 6/8 threshold, one non-urgent action at 237 minutes. The record shows a functioning module, and it is the principal evidence bearing on the threshold question.

2.4 Why renewal is correct under either strategic direction

The DAO is deciding its future in https://forum.summer.fi/t/rfc-determining-the-future-direction-of-lazy-summer-dao/868. Renewal is the right action under both branches:

  • Option A (Continue Building): a protocol rebuilding after an exploit needs its emergency brake more than a stable one does.
  • Option B (Orderly Wind-Down): The RFC explicitly lists maintaining governance security while treasury decisions are finalized. A DAO consolidating a treasury is a more attractive governance-attack target, not less; and the April attempt shows the cost of attempting one is trivial. Letting the brake lapse precisely while assets are being moved would be the single worst-sequenced decision available.

3. Specification:

3.1 Summary of actions

#ActionExecuted byOnchain?
1Extend guardian expiration on 4 chainsDAO governance (Base + LayerZero)Yes
2Re-confirm / rotate guardian signer setGuardian Safe ownersSafe-level
3Confirm signing thresholdGuardian Safe ownersSafe-level
4Formalize periodic liveness checkGuardiansOffchain
5Acknowledge dormant compensation clauseDAONone

3.2 Onchain execution to extend guardian expiration

Function (ProtocolAccessManager, per SIP0.2):

function setGuardianExpiration(address account, uint256 expiration)

Target contracts:

{
  "base":     "0xf389BCEa078acD9516414F5dabE3dDd5f7e39694",
  "mainnet":  "0xf389BCEa078acD9516414F5dabE3dDd5f7e39694",
  "arbitrum": "0xf389BCEa078acD9516414F5dabE3dDd5f7e39694",
  "sonic":    "0xAFb8a8beA8F7CdB4b65437b0c5963dc7Cd270bC6",
}

account parameter is the Guardian Safe:

0x91E4482CF58aC14d8DC25290d828b2A4D9492BA4

expiration parameter proposed value:

1800000000  

Cross-chain routing. Governance executes on Base and propagates via LayerZero. The April attack analysis confirms live LayerZero routes to Ethereum, Arbitrum, and Sonic, if the governor cannot reach those ProtocolAccessManager instances via the standard dispatch, this SIP must specify an alternative path (e.g. Foundation execution instruction, as used in SIP5.17) rather than silently leaving chain unguarded.

3.3 Proposed transaction set

Assuming role-on-Safe and LayerZero reachability, the Base proposal contains:

CallChainTargetFunctionArguments
1Base0xf389BC…9694setGuardianExpiration(0x91E4…2BA4, 1800000000)
2Ethereum (via LZ)0xf389BC…9694setGuardianExpiration(0x91E4…2BA4, 1800000000)
3Arbitrum (via LZ)0xf389BC…9694setGuardianExpiration(0x91E4…2BA4, 1800000000)
4Sonic (route TBC)0xAFb8a8…0bC6setGuardianExpiration(0x91E4…2BA4, 1800000000)

3.4 Guardian set and threshold

Powers are unchanged. This SIP renews the SIP0.2 mandate verbatim: vault pause, deposit-cap override to 0, and proposal cancellation; no fund movement, no parameter tuning, no strategy onboarding; reactive use only, under the SIP0.2 trigger thresholds (≥4% realized or projected loss at fleet/ark level, active or credible exploit, severe oracle failure, or external protocol failure materially impacting vault safety). No expansion of authority is proposed or implied.

Signer re-confirmation. All eight guardians are asked to re-confirm in-thread before the vote opens, explicitly acknowledging continued availability:

GuardianAddress
@blockful0x1F3D3A7A9c548bE39539b39D7400302753E20591
@Raphael_Anode0x6ad64B3B5300821b651aF5415c2119a6ED4e2007
@halaprix0x718b75a546a1b7edf107199aaa62dc257cb7ee80
@MasterMojo0xF68D2BfCecd7895BBa05a7451Dd09A1749026454
@jensei0x746bb7beFD31D9052BB8EbA7D5dD74C9aCf54C6d
@JavierD0xcA4Bc5E1564EBdC2b7e2C9e498735860668A807f
@chrisb0xe9c245293dac615c11a5bf26fcec91c3617645e4
@Sixty0x84bC99d6067f30E01e32D7E7E193d68E24546EcC

Rotation. Three guardians (@chrisb, @halaprix, @jensei) are associated with the winding-down Labs Co. Continued participation is a personal commitment, not an institutional one, and each should state plainly whether they can sustain it. Standing backups already identified: @Thomas (0xF523EEc9E35a697E5bc3e3534167BE9bAdB68e2D), @TokenBrice, and @Meta, who expressed continued interest in February. Signer changes are executed at the Safe level and do not alter the calldata above, provided the Safe address is unchanged.

3.5 Compensation is dormant, and stated plainly

SIP0.2 allocated 15% of DAO-managed vault income to a guardian compensation pool, distributed only while guardian powers are active. With vaults paused, this income is effectively zero, and guardians are therefore serving unpaid.

This SIP proposes no new compensation and makes no claim on the treasury. It is recorded here so the DAO understands what it is asking: eight people to remain on call, retain key custody, and accept public accountability for emergency actions, with no compensation, during a wind-down. That is a reasonable ask given the stakes, but it should be an acknowledged one, not an assumed one, and it is a further reason to expect and accommodate rotation.

3.6 Timing

DateMilestone
~22 JulSIP published
~22 JulOnchain proposal submitted onchain
~25 JulVoting period
~27 JulTimelock delay (48h)
~28 JulExecution across all chains
~9 AugCurrent mandate expires

4. Risk Assessment:

4.1 Risk of not renewing (the primary risk).

The DAO loses vault pause, cap override, and proposal cancellation. A governance attack on this DAO costs roughly $30 (22/07/2026) to attempt; and therefore the Timelock alone is insufficient, the April attack was purpose-built to strip CANCELLER_ROLE. An unguarded window during treasury consolidation is the highest-risk configuration available to the DAO.

4.2 Centralization of emergency power.

Unchanged from SIP0.2 and mitigated identically: narrowly enumerated powers, no fund movement, 75% threshold, expiry-based renewal, mandatory transparency reporting. This SIP expands nothing.

4.3 Guardian inactivity or capture.

Mitigated by re-confirmation, and rotation to identified backups. Residual risk: signers are unpaid during a wind-down, which may degrade responsiveness over the renewal period. The liveness check is the detection mechanism.

4.4 Governance capture preventing renewal / conflict of interest.

I am a guardian and Safe signer. The mitigation is procedural: no expansion of powers is sought, no compensation is requested, the full signer set is subject to re-confirmation and rotation, calldata is published for independent verification, and delegates are explicitly invited to contest the threshold recommendation.

4.5 Renewal fatigue.

A fixed January 2027 expiry creates another cliff. If the DAO winds down and governance participation thins, a future renewal may struggle to reach quorum. The DAO should treat the January date as a hard calendar item and (if Option B proceeds) decide deliberately how the guardian function terminates, rather than letting it lapse by inattention.


5. Voting:

If YES - Renew the Guardian Module mandate: extend guardian expiration to January 2027 across Base, Ethereum, Arbitrum, and Sonic; re-confirm the guardian set unchanged from SIP0.2.

If NO - Do not renew. Guardian powers lapse on ~9 August 2026, and the DAO returns to a governance-only emergency posture with no proposal-cancellation path.


Tagging @Recognized_Delegates for review ahead of the onchain vote, and all current guardians for re-confirmation: @blockful, @Raphael_Anode, @halaprix, @MasterMojo, @JavierD, @chrisb, @Sixty. Backups: @Thomas, @TokenBrice, @Meta.

--jensei

Current Votes

Quorum

62.07M of 42.72M

Majority support

Yes

For

62.07M

Against

0

Abstain

0

Current Votes
Status

Wed Jul 22, 03:13 pm

Published onchain

Thu Jul 23, 03:13 pm

Voting period started

Sun Jul 26, 03:13 pm

End voting period

in 4 hours

Queue proposal

Execute proposal