What are SIPS?
SIPS are proposals to update some function or standard within the Sommelier Ecosystem. SIPS can vary widely from proposing new community initiatives, to requesting funds from the community pool, to changing consensus parameters. The SIPS process follows the same behavior as the Cosmos Governance process.
This is a high level overview of a SIPS lifecycle:
- Informal discussion & sentiment check on the Sommelier Discord or Governance Forum.
- Formal Proposal (SIPS template) on the Sommelier Governance Forum
- Proposer changes status from “Draft” to “Proposed”
- SIPS Proposer submits Proposal on-chain to start Deposit Period
- Voting Period begins
- Implementation by the parties involved with the improvement
SIPS How-to
Context
The SIPS process is not just about fulfilling Sommelier’s functional duties. A streamlined and accessible SIPS process can help cultivate a community which values open collaboration and ensure contributions are recognized and given a clear path to success.
Workflow
- Discord & Forum
This is the initial fielding research + discussion on Discord or the governance forum. This is an informal process to gauge community interest in a potential Sommelier Governance Proposal.
Here are some questions a proposer might want to answer:
- Am I able to informally get any traction for this proposal in the Discord?
- Has this proposal been tried before?
- How does this proposal get the community closer to achieving its stated goals?
- What trade-offs are implicit in this improvement’s adoption?
- Creating SIPS
Once a contributor feels they have a rough consensus that their SIPS is valuable, original, and achievable, they should submit a Sommelier Improvement Proposal on the Sommeliers Governance Forum.
The contributor should make sure that his proposal adheres to the basic SIPS guidelines. He should also tag a Governance Forum Moderator, so a SIP number can be assigned, and corresponding discord channel for discussions can be created.
- Discussion and Proposal state
The forum is the formal area to debate the merits of each SIPS. While the SIPS is on the forum in ‘Draft’ state, the SIPS author is free to make changes to the proposal.
The proposal should be up for at least 3 days on the governance forum, before moving to an onchain vote.
Once the SIPS author is satisfied with the proposal, they should change the proposal status from ‘Draft’ to ‘Proposed’, and schedule a deposit.
- Deposit and Voting period
Foundation Support for Proposal Deposits
The Sommelier Foundation from time to time may find it helpful or necessary to distribute the minimum SOMM for voting deposit to proposals that have merit and have engagement from the community. As such, any proposal DRAFT may include a request for the proposal deposit via the inclusion of the following:
“Dear Sommelier Foundation. If you are interested in the community taking this proposal and conversation to an on-chain vote, please send a signal with 10 SOMM tokens at this Cosmos address [SOMM1XXXXX].”
Deposit Period
All SIPSs are confirmed or rejected by the Sommeliers via Sommelier Governance Vote. Prior to a governance proposal entering the voting period (ie. for the proposal to be voted upon), there must be at least a minimum number of SOMM deposited (10). The deposit period lasts either 14 days or until the proposal deposit totals 10 SOMMs, whichever happens first.
Voting Period
The SIPS has a voting period of 14 days where token holders may vote YES, NO, ABSTAIN or NO-WITH-VETO. Voters may change their vote at any time before the voting period ends.
- Post Voting Process
What determines whether or not a governance proposal passes?
There are four criteria:
- A minimum deposit of 10 SOMM is required for the proposal to enter the voting period
- anyone may contribute to this deposit
- the deposit must be reached within 14 days (this is the deposit period)
- A minimum of 40% of the network’s voting power (quorum) is required to participate to make the proposal valid
- A simple majority (greater than 50%) of the participating voting power must back the ‘yes’ vote during the 14-day voting period
- Less than 33.4% of participating voting power votes ‘no-with-veto’
The criteria for submitting and passing/failing all proposal types is the same.
If a proposal has passed, the SIPS is moved from proposed to approved. If a proposal is rejected the SIPS may be moved to be Rejected or back to Draft to be revised for future consideration.
- Implementation
In the early stages of Sommelier, approved SIPSs will be executed via multisig where necessary. Otherwise, implementation of the SIPS will vary on a case-by-case basis.
SIPS Template
This is the suggested template for new SIPSs. Note that a SIPS number will be assigned by a Moderator.
SIP Name: SIP-XXX (Numbers will be assigned by Moderators)
Status: [Draft, Proposed]
Author(s): [a list of author(s) names, usernames]
Type: [Community Pool Spend, Parameter Change, Text]
Discussions-to: [Create a new thread on https://community.sommelier.com/ and drop the link here]
Created: [date created on]
Simple Summary
“If you can’t explain it simply, you don’t understand it well enough.” Simply describe the outcome the proposed change intends to achieve. This should be non-technical and accessible to a casual community member.
Abstract
A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what will be done if the SIPS is implemented, not why it should be done or how it will be done. If the SIPS proposes changing consensus parameters, write, “we propose change of consensus parameters X to do Y instead of Z”.
Motivation
This is the problem statement. This is the reason for the SIPS. It should clearly explain why the current state of the protocol is inadequate. It is critical that you explain why the change is needed. If the SIPS proposes changing how something is calculated, you must address why the current calculation is inaccurate or wrong. This is not the place to describe how the SIPS will address the issue!
Specification Overview
This is a high level overview of how the SIPS will solve the problem. The overview should clearly describe how the new feature will be implemented.
Technical Specification
The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces of the Sommelier Protocol currently exposes or the creations of new ones.
Rationale
This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.