[RFC] Establish Guardian Module & Emergency Risk Controls

[jensei]

1. Summary:

This RFC proposes establishing a Guardian Module for the Lazy Summer Protocol to strengthen emergency response capabilities and reduce the probability and impact of future risk events.

The Guardian Module would introduce a community-controlled multisig with narrowly scoped emergency powers, including vault pause and governance cancellation rights, designed to act only under clearly defined, high-severity conditions. This RFC seeks feedback on scope, thresholds, guardian responsibilities, and selection mechanics.

NOTE: First mention of the guardian framework, and umbrella proposal.

---

2. Context & Motivation:

November events on Arbitrum USDC (OLD) Vault highlighted the need for faster, narrowly scoped emergency actions that sit between day-to-day risk management and full DAO governance timelines.

While @BlockAnalitica provides continuous risk curation and the DAO governs strategic decisions, there remains a gap during live or rapidly deteriorating situations, where:

• Capital flight can accelerate losses
• Governance execution timelines are too slow
• Partial mitigation is preferable to inaction

The goal is not to centralize power, but to introduce a limited, accountable safety layer that protects users while preserving DAO sovereignty.

---

3. Proposal:

3.1 Guardian Module Overview

The Guardian Module would be implemented as a multisig, controlled by a minimum of 5 trusted community members, with narrowly defined emergency authorities.

Proposed emergency powers:

• Vault Pause: Temporarily halt deposits/withdrawals (and optionally rebalances) on affected vaults
• Governance Cancellation: Cancel in-flight governance proposals that pose immediate protocol risk

These actions would be:

• Reactive only (no proactive parameter changes)
• Fully transparent
• Time-bounded, with mandatory post-event DAO review

3.2 Trigger Conditions (Proposed)

Guardians may act only if predefined emergency thresholds are met, such as:

• 5% loss or projected loss at a Lower Risk Fleet Level
  8% loss or projected loss at a Higher Risk Fleet Level
• Severe external oracle failure or dependency outage
• Active exploit or credible exploit in progress
• External protocol failure materially impacting vault safety

Exact thresholds would be finalized in a follow-up SIP.

3.3 Guardian Responsibilities & Expectations

Being a Guardian is a serious operational responsibility, not an honorary role.

Guardians are expected to:

• Be highly responsive during incidents
• Exercise sound judgment under pressure
• Act strictly within defined authority
• Coordinate with SEAL Org, @BlockAnalitica, the LS Foundation, and DAO where applicable
• Publish or contribute to post-incident transparency reports

Guardians must:

• Understand Lazy Summer vault architecture and risk surfaces
• Be comfortable creating & signing emergency transactions
• Accept public accountability for actions taken

Failure to meet expectations should result in replacement via governance.

3.4 Initial Guardian Nominees (Proposed)

As a starting point for discussion, I propose the following community members as initial Guardian nominees:

• @JavierD
• @Pockythehamster
• @techsqrt
• @MasterMojo
• @halaprix
• @Raphael_Anode

This list is not final and is intended to seed community discussion.

---

4. Open Questions:

• What emergency thresholds should explicitly trigger Guardian authority?
• Should Guardian actions automatically expire after a fixed time window?
• What is the optimal multisig size (5, 6, 7+) and a rule set (3/5, 4/6)?
• How should Guardian replacement or removal be handled?
• Should Guardians receive explicit compensation for this role?

---

5. Next Steps:

• Gather community feedback on scope, powers, and expectations
• Finalize Guardian framework and thresholds
• Confirm Guardian set
• Promote to SIP with formal specification and deployment details
• Vote onchain

---

6. Informal Support Indicator:

To gauge initial sentiment, @Recognized_Delegates and community members are encouraged to signal on the following.

6.1 How do you feel about establishing a Guardian Module with limited emergency powers?

Options:

• Support as proposed
• Support, with adjustments
• Do not support

6.2 Nominate yourself as a Guardian

• I nominate myself for the role

6.3 Should Guardians receive explicit compensation for this role?

Options:

• Yes, fixed stipend (comment below)
• Yes, incident-based compensation (comment below)
• No, volunteer role

This is a foundational safety discussion for the protocol. Please read carefully, challenge assumptions, and nominate candidates only if you believe they can genuinely carry this responsibility.

Looking forward to the @Recognized_Delegates, @BlockAnalitica, and wider community’s input.

–jensei

[Meta]

Let’s run a simple simulation of the proposal as offered: how would the outcome of the recent Arbirtrium USDC vault bank run have differed under this regime, versus the prior standard?

I’m interested in understanding the proposal in relation to an incident, versus in theory.

–

Separately: I’m split on compensation expectations. Volunteering may not align expectations with incentives adequately, while fixed stipend has the opposite effect of reward regardless of engagement. The middle ground of incident-based comp seems like a decent middle-ground, which I could see working as…

“IF Guardian met 3.3 Guardian Responsibilities & Expectations for incident XYZ, THEN disburse share of Guardian-alloted reward pool to this + other incident-engaged Guardians.”

[Raphael_Anode]

I think this is necessary. In line with the security council many other protocols have.

I want to point to some deeper research on the topic and on how to decentralize the guardian roles I made for Reserve Protocol and have written about here: Decentralization of the Reserve Protocol Guardian – dubidu.io

(Republished for Summer)

[jensei]

thats a good question @Meta and nice to clarify, DAO are usually seen as structurally unable to act in real time. imo the process would look as follows:

1st Phase: Early stress detection

• External dependency stress is in action.
• Withdrawals begin accelerating.
• Loss projections start crossing Lower Risk Fleet thresholds (~5%) or trending toward them.

NO difference yet.

2nd Phase: Threshold breach

• Once projected or realized loss thresholds are met, Guardians are authorized to:
  • Pause withdrawals (and possibly deposits/rebalances) on the affected vault.

This likely occur simply due to earlier than DAO action (>5d), and before the potential liquidity exhaustion.

3rd Phase: Immediate effects of a vault pause

• No first-mover advantage. Losses that are not reflected onchain (as experienced with Silo) become uniform and proportional, not withdrawal-order dependent.
  • Information stabilization where delegates and risk teams can communicate without competing against outflows.

4th Phase: Post-pause resolution

• With flows halted BlockAnalitica / delegates assess true impairment vs temporary dislocation; where DAO decides on next steps e.g.: Gradual reopen, Partial unwind, Orderly migration, Haircut mechanics (if unavoidable).

---

It’s important to be precise and realistic here though,

• It would not magically eliminate losses if dependencies were fundamentally impaired.
• It would not protect against insolvency from deep, permanent depegs.
• It would not replace risk management.

What it changes is loss amplification, not risk existence.

Therefore, if any potential problem is discovered in time and enacted upon quickly by the guardians, it could lower realized losses and fairer loss distribution.

[blockful]

Hello! We are blockful, a DAO governance security company.

One of the criteria we use to evaluate the security of a DAO is the analysis of its Security Council.

From a governance perspective, the Security Council is used to block malicious proposals. However, L2s and protocols also use it to prevent attacks on their infrastructure. Compound, for example, has a Guardian with the power to pause its markets and/or block the execution of an approved proposal, all with the goal of protecting the protocol.

As we participate in the Security Councils of ENS and Superfluid and actively study the adoption of this mechanism in the market, we would like to contribute to the answers to the Open Questions.

What emergency thresholds should explicitly trigger Guardian authority?

Usually, the Guardian’s authority is not limited to specific types of incidents, but rather to specific contract functions within a protocol. Compound’s Guardian, for example, is limited to Supply, Transfer, and Withdraw functions for users, and Absorb and Buy functions for the protocol, in addition to having the power to block the execution of proposals.

In our analysis, Lazy Summer should adopt a similar approach, given that it has a comparable business model and that this Guardian model has already been validated in production.

Should Guardian actions automatically expire after a fixed time window?

This is the best way to avoid leaving a Guardian with permanent power over Lazy Summer’s contracts. This renewal usually happens every two years (as in ENS) or annually (as in Compound or Arbitrum).

However, there is a problem: if governance (or the protocol itself) is captured by a malicious attacker, the Guardian may lose its powers and be prevented from acting once it expires.

An example: in Compound, protocol governance was captured by a well-known DAO attacker called Humpy. He holds enough power to block proposals in Compound. After the expiration of the Compound Guardian, Humpy, together with dozens of wallets controlled by him, blocked the proposal to renew the Guardian members’ compensation. We do not know why he did not block the renewal of the Guardian’s powers as well, but he could potentially have done so if he wanted.

Therefore, setting an annual or biannual expiration for the Guardian is good practice. The power should not be permanent. However, there is a risk that, if governance or the protocol is captured, the Guardian may no longer be able to prevent attacks. For this reason, it is important not to rely solely on the Guardian and to treat governance and protocol security as an ongoing concern.

What is the optimal multisig size (5, 6, 7+) and a rule set (3/5, 4/6)?

A good standard to follow for multisigs is the one proposed by L2BEAT. It requires meeting a set of criteria such as:

1. at least 8 members,

2. a 75% signing threshold,

3. publicly announced members, and

4. a subjective assessment of member selection.

Point (4) is especially about how diverse the Security Council composition should be and the current regulatory situation of the participating members in the multisig.

Therefore, a 6/8 or 5/7 multisig is sufficient for Lazy Summer’s Guardian. A 6/8 setup is generally adequate.

There are much larger multisigs, such as those used by Arbitrum and Optimism to secure their L2 Security Councils. However, given Lazy Summer’s TVL and the need for operational agility, having more than 10 signers would become impractical.

How should Guardian replacement or removal be handled?

Arbitrum’s Security Council provides a good framework that can be adopted or used as a reference for building Lazy Summer’s Guardian, mainly due to three aspects:

1. a contract for member management,

2. a contract for member removal,

3. a contract for managing the Guardian/Security Council’s powers over the protocol.

Given Arbitrum’s TVL, it made sense to build such a structured Security Council. The idea here is for Lazy Summer to use this model as inspiration to build its own Guardian.

Should Guardians receive explicit compensation for this role?

Yes, compensation is necessary to incentivize Guardian participants to commit to Lazy Summer’s security and to attract members with sufficient technical expertise to manage a multisig in extreme situations, evaluate risks, and decide when Guardian intervention is necessary.

Not compensating Guardians may attract people interested in capturing Lazy Summer or create stronger incentives for Security Council members to be “captured” by malicious actors, encouraging them not to block an approved proposal or not to pause a vulnerable market in the protocol.

[Raphael_Anode]

This is excellent. Thanks a lot!

[Meta]

Reverting now as the discussion as advanced. While I’m seriously concerned the proposed guardrails would have had materially little impact on the experience of recently affected depositors, I am interested in participating to (a) represent depositor interests, which appear underweighted relative to token-holder interests and (b) to see the guardrails develop beyond this initiative, into something that firmly and tractably would have and will prevent future losses in line with user expectations.