[SIP0.2] Establish Guardian Module & Emergency Risk Controls

Governance Summer Improvement Proposals [SIPs]
, , , ,
1

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):

  1. Vault Pause
    Temporarily halt deposits and withdrawals on affected DAO-managed vaults.

  2. Deposit Cap Override
    Set deposit caps to 0 for DAO risk-managed vaults.

  3. Governance / Onchain Proposal Cancellation
    Cancel in-flight proposals that pose immediate protocol risk.

The Lazy Summer Protocol has regular and with expiry date guardians. 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.