Sommelier Improvement Proposal Guide (SIPS)

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:

  1. Informal discussion & sentiment check on the Sommelier Discord or Governance Forum.
  2. Formal Proposal (SIPS template) on the Sommelier Governance Forum​
  3. Proposer changes status from “Draft” to “Proposed”
  4. SIPS Proposer submits Proposal on-chain to start Deposit Period
  5. Voting Period begins
  6. 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

  1. 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?
  1. 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.

  1. 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.

  1. 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.

  1. Post Voting Process

What determines whether or not a governance proposal passes?

There are four criteria:

  1. 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)
  1. A minimum of 40% of the network’s voting power (quorum) is required to participate to make the proposal valid
  2. A simple majority (greater than 50%) of the participating voting power must back the ‘yes’ vote during the 14-day voting period
  3. 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.

  1. 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.

11 Likes




This website does not constitute an offer to sell or a solicitation of interest to purchase any securities in any country or jurisdiction in which such offer or solicitation is not permitted by law. Nothing on this website is meant to be construed as investment advice and we do not provide investment advisory services, nor are we regulated or permitted to do so. This website is provided for convenience only. Sommelier does not manage any portfolios. You must make an independent judgment as to whether to add liquidity to portfolios.

Users of the Sommelier website should familiarize themselves with smart contracts to further consider the risks associated with smart contracts before adding liquidity to any portfolios.

Note that the website may change, and we are under no obligation to update or advise as to these changes. There is no guarantee that the Sommelier Mainnet, including any software, products or token use cases mentioned on the website, will be built, or offered by Sommelier. In particular, actual results and developments may be materially different from any forecast, opinion or expectation expressed in this website, or documents contained in it, and the past performance of any portfolio must not be relied on as a guide to its future performance.

To the extent permitted by law, the company and its directors, officers, employees, agents exclude all liability for any loss or damage arising from the use of, or reliance on, the material contained on this website whether or not caused by a negligent act or omission. The release, publication or distribution of this website and any materials herein may be restricted in some jurisdiction and therefore you must inform yourself of and observe any such restrictions.