[RFC] Adjusting Governance Quorum & Proposal Threshold

General Discussion Request for Comment [RFCs]
, , ,
1

1. Summary:

This RFC proposes adjusting Lazy Summer DAO’s governance parameters, specifically increasing quorum requirements and raising the proposal submission threshold to better align governance security with the current distribution of voting power.

At present, governance can be significantly influenced by a small number of large delegates, creating a structural risk where a single delegate (or a tightly coordinated small group) can approach or reach quorum thresholds with limited broader participation.

The goal of this RFC is to introduce more robust guardrails against governance capture while preserving operational efficiency, and to align proposal creation and execution thresholds with the DAO’s evolving scale and active voting participation.

This RFC also introduces an informal support indicator poll to guide parameter selection before moving toward a formal SIP.

2. Context & Motivation:

Lazy Summer DAO has grown into a more mature governance system with:

  • Institutional partners and protocol complexity
  • Expanding vault and ARK strategies
  • A growing but still concentrated delegation set
  • ~114M actively participating voting power

Current governance parameters:

  • Quorum: 15% of stSUMR supply (~39.15M stSUMR)
  • Proposal Threshold: 10,000 stSUMR

Governor Contract: Address: 0xbe5a4dd6...a0601e9fa | BaseScan

While these parameters were appropriate during earlier phases of bootstrapping governance, current conditions introduce emerging structural risks:

  • The largest delegate holds ~50M voting power
  • Top 3 delegates combined exceed ~110M voting power
  • Active governance participation is ~114M voting power total
  • This creates a scenario where:
    • Quorum can be approached or influenced by a small subset of delegates
    • Proposal creation remains extremely accessible relative to system size
    • Coordination risk increases in low-participation voting cycles

Here I think we should aim to ensure that:

  • No single delegate (or tightly coordinated subset) can meaningfully influence quorum outcomes alone
  • Proposal creation remains accessible but not trivial
  • Governance reflects broad participation, not concentrated activation
  • The system scales safely as delegation continues to consolidate or evolve

3. Proposal:

This RFC explores adjustments to two core governance parameters: quorum and proposal threshold. Rather than prescribing a single fixed change, this RFC proposes three example options for community evaluation/editting.

3.1 Option A: Moderate Increase

  • Quorum: 15% → 20% of stSUMR supply
  • Proposal Threshold: 10,000 → 50,000 stSUMR
Rationale:
  • Increases safety margin without making governance overly rigid
  • Preserves current participation dynamics
  • Still accessible for mid-sized delegates and working groups
Effect:
  • Requires broader coalition-building for execution
  • Slightly reduces spam/low-signal proposals

3.2 Option B: Stronger Security Upgrade

  • Quorum: 15% → 25% of stSUMR supply
  • Proposal Threshold: 10,000 → 100,000 stSUMR
Rationale:
  • Aligns quorum more closely with active governance supply distribution
  • Ensures no single delegate or top 2–3 can meaningfully influence outcomes alone
  • Encourages stronger coordination across delegate set
Effect:
  • Higher coordination requirement for passing proposals
  • Stronger anti-capture guarantee
  • May reduce governance throughput slightly

3.3 Option C: Strong Security Upgrade

  • Quorum: 15% → 30% of stSUMR supply
  • Proposal Threshold: 10,000 → 1,000,000 stSUMR
Rationale:
  • Adapts to governance participation trends over time
  • Prevents over-hardcoding parameters in a rapidly evolving DAO
  • Creates structured separation between low-impact and high-impact proposals
Effect:
  • Most flexible and future-proof
  • Higher complexity in governance design
  • Requires offchain coordination or governance module upgrades

4. Open Questions:

Feedback is especially needed on:

  • Should quorum increases prioritize security (capture resistance) or efficiency (proposal throughput)?
  • What level of friction is acceptable for small contributors or working groups?
  • What other proposed amounts are sensible options here?

5. Next Steps:

  • Gather community feedback across @Recognized_Delegates and contributors
  • Run informal support poll (below)
  • Evaluate preferred direction
  • Refine into formal SIP if consensus emerges

6. Informal Support Indicator:

To gauge delegate sentiment before formalizing this into a SIP:

6.1 What quorum adjustment do you support?

  • 15% → 20%
  • 15% → 25%
  • 15% → 30%
  • Other? (Share below)
0 voters

6.2 What threshold adjustment do you support?

  • 10,000 stSUMR → 50,000 stSUMR
  • 10,000 stSUMR → 100,000 stSUMR
  • 10,000 stSUMR → 1,000,000 stSUMR
  • Other? (Share below)
0 voters

As governance participation matures and delegation continues to concentrate, parameter design becomes a core security surface of the DAO. This RFC is intended to open discussion on whether current settings still reflect the risk profile and scale of Lazy Summer Protocol governance today, or whether we should proactively evolve safeguards before they become necessary.

Looking forward to feedback from @Recognized_Delegates, contributors, and Lazy Summer community.

–jensei

2 Likes
Community Call #15: Market Conditions, Risk Updates & DAO Vaults
2

Hey @jensei, thanks for bringing this forward. I agree with the overall sentiment of the proposal. If it’s not too much work, I would propose we gradually increase the parameters from option A towards option C.

This would look something like this:

  • Immediately increase to option A now,
  • increase to option B in Q3 if governance stability continues,
  • and finally increase to option C in Q4 if governance stability is achieved with option B.

This allows us to find an equilibrium over time, rather than prescribing a single parameter change.