1. Overview:
This SIP proposes establishing a Guardian Module for the Lazy Summer Protocol: a narrowly scoped, community-controlled multisig empowered to take temporary emergency actions during high-severity risk events, reducing loss amplification while preserving DAO sovereignty.
RFC: [RFC] Establish Guardian Module & Emergency Risk Controls
2. Motivation:
The Guardian Module introduces a minimal, accountable safety layer aligned with best practices used by Compound, ENS, Arbitrum, and others designed to:
- act faster than governance,
- operate only under explicit emergency conditions,
- and remain fully accountable to the DAO.
This SIP does not centralize power or replace risk management. It reduces loss amplification, not risk existence.
3. Specification:
3.1 Guardian Module Overview
The Guardian Module will be implemented as a multisig with strictly limited emergency authorities.
Authorized actions (only):
-
Vault Pause
Temporarily halt deposits and withdrawals on affected DAO-managed vaults. -
Deposit Cap Override
Set deposit caps to0for DAO risk-managed vaults. -
Governance / Onchain Proposal Cancellation
Cancel in-flight proposals that pose immediate protocol risk.
The Lazy Summer Protocol has
regularandwith expiry dateguardians. Only the latter can cancel proposals - as long as they are not expired.
Explicit limitations:
- No proactive parameter tuning
- No fund movement
- No strategy onboarding/offboarding
- Reactive use only
All actions are:
- fully transparent,
- time-bounded,
- subject to mandatory post-incident DAO review.
3.2 Emergency Trigger Thresholds
Guardians may exercise authority only when one or more of the following conditions are met:
- ≥ 4% realized or projected loss at a fleet or ark level
- Active exploit or credible exploit in progress
- Severe oracle failure or critical dependency outage
- External protocol failure materially impacting vault safety
Thresholds are intentionally conservative to allow earlier intervention than DAO voting cycles.
3.3 Guardian Composition & Signing Rules
Proposed multisig configuration:
- 8 signers
- 6/8 signing threshold (75%)
- 180d expiration, renewable via governance
Initial Guardian Set (proposed):
To confirm the initial set of guardians I request all the above mentioned users to confirm, accept the responsibilities and post their wallet address to be included in the guardian multi-sig in the comment below this post.
This set reflects:
- risk & governance expertise,
- operational readiness,
- diversity of affiliations,
- prior public accountability.
A subjective assessment of member selection is included to align with L2BEAT Security Council standards, and can be found here.
3.4 Guardian Responsibilities
Guardians are expected to:
- remain highly responsive during incidents,
- act strictly within defined authority,
- coordinate with @BlockAnalitica, SEAL Org, Lazy Summer Foundation, and the DAO,
- publish or contribute to post-incident transparency reports,
- accept public accountability for actions taken.
Failure to meet expectations may result in removal via governance.
3.5 Contracts & Transactions
`function grantGuardianRole(address account)`
`function setGuardianExpiration(
address account,
uint256 expiration`
on all supported chains
"protocolAccessManager": {
"base": "0xf389BCEa078acD9516414F5dabE3dDd5f7e39694",
"mainnet": "0xf389BCEa078acD9516414F5dabE3dDd5f7e39694",
"arbitrum": "0xf389BCEa078acD9516414F5dabE3dDd5f7e39694",
"sonic": "0xAFb8a8beA8F7CdB4b65437b0c5963dc7Cd270bC6",
"hyper": "0x38fB5a7fa70103dCd9e8A969f3975A77E0fE755f"
},
where
/// @notice Minimum allowed guardian expiration period (7 days)
uint256 public constant MIN_GUARDIAN_EXPIRY = 7 days;
/// @notice Maximum allowed guardian expiration period (180 days)
uint256 public constant MAX_GUARDIAN_EXPIRY = 180 days;
3.6 Compensation
To align incentives and accountability:
- 15% of DAO-managed vault income allocated to a Guardian compensation pool
- Split evenly across active signers
- Distributed only while Guardian powers are active
- as soft-proposed: here.
In addition, the DAO may approve:
- Supplementary SUMR emissions (subject to separate confirmation or future SIP)
4. Risk Assessment
Risks:
- Centralization of emergency power
- Guardian inactivity or capture
- Governance capture preventing renewal
Mitigations:
- Narrow, enumerated powers only
- High multisig threshold (75%)
- Annual expiration & DAO renewal
- Full transparency & post-event review
Upon confirmation from the proposed individual entities, I will create and share a multi-sig in the comment below; pre-onchain vote publishing.
5. Voting
If YES: - Approves creation of the Guardian Module, authorizes deployment of contracts, confirms initial Guardian set, and activates emergency authorities under defined thresholds.
If NO: - Maintains current governance-only emergency posture.
Tagging all @Recognized_Delegates for review, before it is posted for an onchain vote ~04/02/2026.
