SIP0: Governance Process

Hey everyone! :wave:

I’m sharing SIP0: Governance Process, which outlines how proposals will be submitted, discussed, voted on, and executed within Lazy Summer Protocol. This is the foundation of our governance system, ensuring transparency, efficiency, and community-driven decision-making.

This is an open draft, and I’d love to hear your thoughts before it moves to a formal vote. Your feedback is crucial in refining the process and making sure it works smoothly for everyone.


Overview

SIP0 establishes the governance process for Lazy Summer Protocol, providing a structured framework for community participation, proposal submission, and decision-making. This process ensures that all proposed changes are thoroughly vetted and receive broad community support before implementation.

Motivation

A well-defined governance process is essential for effective decision-making and community engagement. By establishing clear procedures for submitting and approving Summer Improvement Proposals (SIPs), SIP0 empowers token holders and protects the protocol’s integrity, ensuring transparency and accountability.

Proposal Stages

  1. Idea Submission (Lazy Summer Protocol Forum)

• Community members post their ideas in the Lazy Summer Forum for initial feedback.

• Posts should include the following details:

• Background: Context and relevance of the idea.

• Problem Statement: The issue the proposal addresses.

• Potential Solution: A brief description of the proposed change.

  1. Discussion & Refinement

• Community members provide feedback to refine the idea.

• The proposer integrates insights from the discussion to improve clarity and feasibility.

  1. SIP Submission

• Requirements for submission:

• The proposer must hold or be delegated at least 10,000 $SUMR tokens.

• The SIP must adhere to the established template, including all necessary details (e.g., Summary, Motivation, Specification).

This threshold helps prevent spam proposals while ensuring governance remains accessible to engaged community members.

  1. On-Chain Voting

• SIPs undergo a 4-day on-chain voting period, during which token holders vote “Yes” or “No.”

• Voting requirements:

Quorum: At least 2% of $SUMR tokens must participate.

Passing Threshold: Over 50% of votes cast must be in favor for the proposal to pass (abstentions do not count toward the total).

  1. Execution

• Approved SIPs enter a TimeLock contract with a 2-day waiting period before automatic execution.

• The TimeLock allows time for community review or emergency action if unforeseen issues arise.

Rejected Proposals

• If a SIP fails to meet quorum or does not receive enough votes to pass, it is considered rejected.

• Rejected proposals may be resubmitted after revisions, incorporating community feedback from the previous vote.

• A resubmitted proposal should include a summary of changes made based on past discussions.

A Note on Temp-Checks and Off-Chain Voting

Currently, there’s no seamless off-chain voting solution that properly accounts for voting decay and vesting wallets. Since our governance operates on Base, on-chain voting is extremely cheap. Given this, if the community agrees that a proposal should undergo a temp-check, it can be conducted directly within the existing governance system, ensuring transparency and efficiency without the need for an external off-chain process.

If we find or partner with a provider that can handle these challenges, we can revisit the discussion and explore off-chain voting options.


Naming Convention

Sub-numbering System for Unique SIP Identification

Overview

The sub-numbering system introduces a structured way to uniquely identify Summer Improvement Proposals (SIPs) within the same topic. By appending sub-numbers to the primary SIP number, this system ensures clarity and scalability while maintaining an intuitive format for users to follow.

Format

The naming convention for SIPs will be:

SIP[Primary Number].[Sub-number]

Primary Number (SIP[Number]): Represents the main topic category of the proposal. Each number corresponds to a specific category of governance activity (e.g., Vault Onboarding, ARK Onboarding).

Sub-number ([.Sub-number]): Sequentially identifies individual proposals within the same topic, ensuring unique identifiers for every SIP.

Example Structure

SIP1.1: First Vault Onboarding Proposal.

SIP1.2: Second Vault Onboarding Proposal.

SIP2.1: First ARK Onboarding Proposal.

SIP2.2: Second ARK Onboarding Proposal.

How It Works

The sub-numbering system operates as follows:

1. Assignment

Each new proposal within a category receives:

The next available sub-number to ensure chronological tracking within that topic.

• Sub-numbers are independent across primary categories. For example, SIP1.1 and SIP2.1 are unrelated, as they belong to different topics.

2. Reference

Proposals are referenced using their complete identifier (e.g., SIP1.2, SIP2.1). This ensures discussions and archives are clear and clear when multiple proposals fall under the same primary number.

Advantages

  1. Clarity: Proposals within the same category are clearly distinguished, avoiding ambiguity in discussions and documentation.

  2. Scalability: As the protocol grows, the system accommodates unlimited proposals within each topic.

  3. Consistency: A standardized format makes proposals easy to reference, track, and organize.

  4. Searchability: Users can quickly locate related proposals by searching for the primary SIP number (e.g., all SIP1 proposals).

Examples

SIP6.1: Proposal to modify $SUMR rewards to XYZ vault.

SIP8.2: Proposal to add XYZ TipStream.

Proposed Categories

  • SIP0 - Governance Processes
  • SIP1 - Vault Onboarding
  • SIP3 - ARK Offboarding
  • SIP4 - Vault Offboarding
  • SIP5 - Protocol Fee Adjustments
  • SIP6 - $SUMR Rewards
  • SIP7 - Governance Rewards
  • SIP8 - TipStream Adjustments
  • SIP9 - Vault Parameter Adjustment
  • SIP10 - Governance Parameters

Process to Add More SIP Categories

As the protocol evolves, new categories and templates for Summer Improvement Proposals (SIPs) may be required to accommodate additional governance needs. Here’s a structured process for defining and integrating new SIP categories and templates.

1. Identify the Need for a New SIP Category

Trigger Events:

• A community member submits a proposal that doesn’t fit existing categories.

• A governance discussion identifies a new area of focus.

• Expansion of protocol functionality (e.g., new products or integrations) necessitates unique proposal types.

Proposal Analysis:

• Determine if the new proposal type is recurring or a one-off. For recurring cases, a new SIP category is warranted.

• Assess if the new category overlaps significantly with existing ones. If so, modify or expand the scope of the current category instead.

2. Submit a Governance Proposal to Add a New SIP Category

• Follow the standard governance process to propose a new SIP category:

Title: Propose a new SIP category name, description and template.

Motivation: Explain why the new category is necessary and how it aligns with protocol needs.

Template Structure: Provide a draft template for the proposed category, ensuring it includes all relevant sections (e.g., Summary, Abstract, Specifications).

3. Approval and Documentation

Community Feedback:

• Present the proposal in the governance forum for feedback and refinement.

Voting:

• If the proposal gains sufficient community support, move it to the voting stage. If the necessity (or not) of the new SIP template is too obvious, this can be a simple Yes/No in the proposal.

Documentation Update:

• Upon approval, update the governance documentation to include the new SIP category.

• Clearly list the new SIP category in the Naming Convention section.

4. Integrate the New SIP Category

• Assign a new Primary Number to the category:

• Example: If the last category was SIP5 (Protocol Fee Adjustments), the new category becomes SIP6.

• Provide examples for the new category in the documentation to help proposers understand its scope and application.

5. Monitor and Evolve

Review Usage:

• Track how frequently the new category is used to ensure it fulfills its intended purpose.

• Collect community feedback on whether the category and template require adjustments.

Periodic Updates:

• Conduct periodic reviews of all SIP categories and templates to ensure they remain relevant.

• Merge, split, or modify categories as the protocol grows.

We encourage the community to share their thoughts and feedback on this approach. If you have ideas, concerns, or suggestions for improving temp-checks and voting mechanisms, join the discussion and let’s refine the process together!

3 Likes

what you mean with “SUM tokens”? it is not clear to me…

1 Like

Thanks for noticing it @Piter, it’s been corrected to the correct token name: $SUMR

In general proposed process looks great @Javier. I like categorization of proposal but wanted to raise some concerns about the initial Proposed Categories to be more carefull with bootstrapping some of them initially.

  • SIP1 - Vault Onboarding
  • SIP4 - Vault Offboarding

Why we need a seperate onboarding & offboarding, that could be a single category TBH, they are related

  • SIP3 - ARK Offboarding

Here you only have ARK offboarding but no onboarding, also I think that’s too granular and I’m concerned with fragmentation of categories, too much can be problematic but also too little will not be usefull. We need to strike a balance here.
So “onboarding & offboarding” are related an they would fit together nicely.

  • SIP5 - Protocol Fee Adjustments
  1. shouldn’t that be generalized to just “Protocol Parameters Adjustment”? what gives we need that one parameter have a separate category?
  • SIP6 - $SUMR Rewards

This category could be more improved, as rewards are added to fleets for (protocol usage rewards) and they can be any token not only $SUMR, so it doesn’t make sesne to limit a category to just $SUMR token. in the future this would require a separate cat. or extending this one, we can do that already because we konw how the system was designed to work.
So I would propose to rename this category to “Protocol Usage Rewards”

  • SIP8 - TipStream Adjustments
  • SIP9 - Vault Parameter Adjustment

For those above I would like to see some examples first before we create them to better understand if the assumptions they are indeed needed from the start are correct. Better to delay creation of them later if they are not very clear.

Still not clear what is “2% of $SUMR tokens”, we need to clarify is it circulating, delegated or total supply.

Here’s a drawing of the governance flow.

I suggest introducing a minimum RFC time before a vote can be put on chain (three days, maybe).

I would also highlight this. I would assume it’s 2% of the votable supply, defined as the number of tokens that can actively participate in governance (usually, this means delegated tokens).

Can anybody trigger the execution of a green-lit proposal? Or just the author?

1 Like

Hey @Javier thanks for the proposal.

Agreed with most of the above feedback.

Two suggestions to keep the process lean:

  • Group categories 5-10 into simply something like: Governance parameters
  • If any party wants to onboard multiple vaults at once, e.g. during the initial deployment, then it is encouraged to group them into a single post for readability. Votes should probably happen on vaults individually still. Title could then be: SIP1.1-SIP1.10 Onboarding XX, YY, ZZ …

PS. Your current edit misses category ‘2’.

@Piter @FBrinkkemper @rspa_StableLab

Thanks for your feedback, I’ve put together your comments and summarized the changes in this reply.

RFCs:
Add a 3-day RFC period before a proposal can be submitted on-chain. RFCs should be clearly marked as such to distinguish early-stage discussions from formal governance proposals. After the RFC phase, proposals should be updated with community feedback before being submitted as formal governance proposals.

Quorum:
After carefully reading your feedback and analyzing it, I believe that the minimum quorum should be 35% of the Delegated Supply. This results in a quorum of 60.03M. The rationale behind this, is that given how the delegated votes are concentrated, this ensures at least 2 delegates to vote in favor.

SIP Categories:
I also agree here that we should aim for simplicity, so from your feedback I made this new list of proposed categories to start. These categories can be adjusted later.

  • SIP0 - Governance Process
  • SIP1 - Vault Management (Onboarding & Offboarding)
  • SIP2 - ARK Management (Onboarding & Offboarding)
  • SIP3 - Token Rewards
  • SIP4 - Governance Parameters
  • SIP5 - Special Governance Votes (One-Off Proposals)

What changed?

  • Unified onboarding and offboarding into a single category for each.
  • Changed $SUMR rewards for Token Rewards to make it more flexible and simple to understand for new users.
  • Unified most of the categories related to changes in parameters in a single category. If later we find this category to be confusing, or needs more granularity, we can add new categories.
  • Added Special Governance Votes, for one-off proposals such as SIPX: Whitelist Reward Contracts to allow SUMR Rewards to be claimed and bridged who might not fit into any other category.

Happy to hear your feedback.

3 Likes

Looks good to me, thanks for the update. No more comments on my side.

1 Like

Excellent. I suggest labeling RFCs with [RFC] at the start of the title. That’s somewhat of an informal standard. After successful ratification we can then change the title to [SIP##.#] with the correct numbering.

I agree this is a reasonable starting point. Let’s see who it goes and if Summer has enough active and engaged delegates this can be increased.
One of the joys of having good delegates and active token holders delegating is that quorum can be quite high and governance security with it.

2 Likes

Considering the positive feedback on the updated items, this proposal will be submitted for voting tomorrow at 4pm CET.

1 Like

Regarding the green-lit proposals, yes anyone can execute via Tally UI or via SummerGovernor.

1 Like