Hey everyone! 
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
- 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.
- Discussion & Refinement
• Community members provide feedback to refine the idea.
• The proposer integrates insights from the discussion to improve clarity and feasibility.
- 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.
- 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).
- 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
-
Clarity: Proposals within the same category are clearly distinguished, avoiding ambiguity in discussions and documentation.
-
Scalability: As the protocol grows, the system accommodates unlimited proposals within each topic.
-
Consistency: A standardized format makes proposals easy to reference, track, and organize.
-
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!
