Proposal: SIMP - Sushi Improvement Proposal format

Proposals
#1

veSIP - an improvement for Sushiswap proposals

voter extension for Sushiswap Improvement Proposals

Table of Contents

Abstract

This is a soft proposal suggesting to adopt the Yearn YIP specification as veSIP and adopt the additional changes and improvements so that it can be adopted by the Sushiswap community for use in governance proposals and community improvements through governance.

:no_entry: Disclaimer

This proposal is intended to offer a different narrative to the current status quo of proposals.

  • It does not offer a new CEO.
  • It does not offer a magic bullet to all the ills of consensus making
  • It does not offer nor claim to provide a way of making $SUSHI price go up
  • It does not offer a new product or feature that will be the next killer dApp

It also does not

Try to solve all of the purported issues at once
Have multiple touch points
Change anything to do with how current engineering and back office processes are handled or executed
Change any multisig signers
Ask for any money or funding
Offer any money or funding

:open_book: veSIP

voting enabled Sushi Improvement Proposal (veSIP) will depreciate the current SIMP (Sushiswap Improvement Proposal) regime.

This document is split into two primary sections:

  • Patterns and metrics forevaluatingg proposals

Key Results

This is a list of clear and reasonable improvements that will help facilitate a more effective and reasonable governance process for Sushiswap

  • Establish a more formal SIMP Process (Sushiswap Improvement Proposal)
  • Make governance easier to navigate and reason about by having articulated proposals that can be empirically validated
  • Enable a more informed voting marketplace by providing details to better judge proposals such as testing/security support.
  • Proposals must meet certain minimum criteria.
  • Proposals must be a clear and complete description of the proposed enhancement. The enhancement should represent a net improvement.

SIMP Statuses

WIP - a SIMP that is still being developed.
Proposed - a SIMP that is ready to be reviewed in a governance call.
Approved - a SIMP that has been accepted for implementation by the Yearn community.
Implemented - a SIMP that has been released to mainnet.
Rejected - a SIMP that has been rejected.
Withdrawn - a SIMP that has been withdrawn by the author(s)/editor.
Deferred - a SIMP that is pending another SIMP/some other change that should be bundled with it together.
Moribund - a SIMP that was implemented but is now obsolete and requires no explicit replacement.

Defining Patterns

We use the term “pattern” meaning relevant to our protocol, and “anti-pattern” to represent a more subjective interpretation or one that is hard to automate to determine should it be included or not.

Anti Patterns for Governance Proposals

Proposals that addresses a problem that has not been defined
Proposals that addresses a problem that no longer exists
The Proposals addresses more than one problem
Proposals that has no stated purpose
The language of the Proposals is vague or complex
Proposals is unable to achieve its stated goal

Viable Governance at Scale

Problem Components

For our purposes, a Problem needs three components:

  1. AN INSTABILITY
  2. THE CONSEQUENCES of that instability presented
    a. most often as the “Costs” of leaving the instability unstable;
    b. sometimes as the “Benefits” of stabilizing it.
  3. READERS who constitute a community of discourse defined by
    their interest in a topic and who will accept or are open to
    accepting the cost/benefits.

Axioms and Principles for Governance Actions

  • Requirements (the need for a new law) is realized by Principle (the to-be law)

  • If you are in the business of producing proposals, then the proposal is a ‘Business Object’

  • Proposal elements are not passive.

Note this document does not seek to define an imperative set but rather relational sets.

Patterns for Finding Important Governance Patterns

We use the term “pattern” meaning relevant to the protocol, and “anti-pattern” to represent a more subjective interpretation or one that is hard to automate to determine should it be included or not.

Patterns

  • Law that addresses a problem that has not been defined
  • Law that addresses a problem that no longer exists
  • The law addresses more than one problem
  • Law that has no stated purpose
  • The language of the law is vague or complex
  • Law is unable to achieve its stated goal

Anti-Patterns

  • Proposals that address problems that have not been defined
  • Proposals that address problems that no longer exist
  • Proposals that address more than one problem in different domains
  • Proposals that lack a stated, measurable problem solving the goal, or purpose
  • Proposals that fail to achieve their goal or lack stated goals
  • Proposals that lack a citation of references
  • Proposals whose burdens are greater than their problem-solving benefit
  • Proposals whose problem-solving benefit and burdens are equal
  • Proposals whose results cannot be measured
  • Proposals that interfere with other proposals
  • Proposals that duplicate other proposals
  • Requires Review
  • Proposals that are not enforced*
  • Proposals that are overly vague or complex*
  • Proposals that have not undergone QA analysis within a specified time frame

veSIP

veSIP is based off of Yearn Finances YIP process. From the Yearn documentation:

YIP stands for yEarn Improvement Proposal, it has been adapted from the SIP (Synthetix Improvement Proposal). The purpose of this process is to ensure changes to yEarn are transparent and well governed. An YIP is a design document providing information to the yEarn community about a proposed change to the system. The author is responsible for building consensus within the community and documenting dissenting opinions.

Preamble

  • RFC 822 style headers containing metadata about the SIMP, including the SIMP number, a short descriptive title (limited to a maximum of 44 characters), and the author details.

Simple Summary

  • “If you can’t explain it simply, you don’t understand it well enough.” Provide a simplified and layman-accessible explanation of the SIMP.

Abstract

  • a short (~200 word) description of the technical issue being addressed.

Problem Components

For our purposes, a Problem needs three components:

  1. AN INSTABILITY
  2. THE CONSEQUENCES of that instability presented
    a. most often as the “Costs” of leaving the instability unstable;
    b. sometimes as the “Benefits” of stabilizing / fixing / improving it.
  3. READERS who constitute a community of discourse defined by
    their interest in a topic and who will accept or are open to accepting the cost/benefits (i.e. the protocol community)
Motivation
  • The motivation is critical for SIMPs that want to change yEarn. It should clearly explain why the existing specification is inadequate to address the problem that the SIMP solves. SIMP submissions without sufficient motivation may be rejected outright.

:bulb: We almost always overestimate our readers’ sense of the importance of what we think is important. Any time you decide to skip stating a motivating problem, you ought to look hard at whether or not your readers are so motivated that they will read your prose even if they perceive it to be useless to them

Specification
  • The technical specification should describe the syntax and semantics of any new feature.
Rationale
  • The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.
Test Cases - Test cases may be added during the implementation phase but are required before implementation.

Copyright Waiver - All veSIPs must be in the public domain.

:memo: Writing Tips

In general, use present tense rather than future tense; in particular, try to avoid using will where possible—for example:

:white_check_mark: Recommended: Send a query to the service. The server sends an acknowledgment.
:x: Not recommended: Send a query to the service. The server will send an acknowledgment.

While writing, authors should avoid framing issues using the gap problem pattern and instead utilize the error pattern.

:x: Gap Problem: something outside the readers’ current knowledge that they ought to understand;
:white_check_mark: Error Problem: claims that there is something amiss in the knowledge that the readers think they have.

Voice and Tone

too formal

  • :x: A gauge is a metric that is composed of a single numerical value that can arbitrarily increase or decrease depending upon the value of which the metric is tracking.

too casual

  • :x: A gauge is a number that can go up and down for a couple of reasons, like if it gets more trades or higher gas costs.

just right

  • :white_check_mark: A gauge represents a single numerical configurable parameter that changes based on the underlying asset.

Closing Remarks

This soft proposal welcomes feedback, questions, comments, etc. Nothing about the actual requirements for governance are changed, only the submission process. This process is typically discounted and seen as merely a formality: it should not be treated so haphazardly.

Cheers!

3 Likes
#2

Sounds good ! Better readability for proposals.

1 Like
#3

I salute the time and effort you underwent to produce this.

I welcome an effort to instill some coherence of forum discussions.

However, we already have tentative template for improvement proposals and cadence.
So far, not many proposals required such strict structure. And we don’t get many proposals these days.

As long as this proposal becomes a guiding line, and there are no explicit sanctions from deviating from it, I would vote in favor.

1 Like
#4

Most of this is guidance - the only actual material component is the outline for submitting a proposal itself, which is based off of EIP/YIP process.

Facilitating conversations and getting input is the desired goal really. I don’t think we would want to reject out of hand some proposal that neglected to include a motivation section in their proposal ya?

#5

@sambacha as someone who spends their time in governance and forum I acknowledge the need for an improved and streamlined process.

I applaud your detailed post and willingness to tackle this pain point.

Although I disagree with the naming of this process (“SIMP”), this framework has some merit:

Establishing a clear and detailed series of status is important. It also seems as if you meant to say Sushi instead of “Yearn” in the third line?

One thing I will push back on is the the name of this - veSIP seems a bit misleading. “ve” has been a naming conventions to indicate a voting asset, yes, but also a locked asset.

As this is a framework for governance and not a new asset, it may be best to reconsider this name.

1 Like
#6

Yes I did not mean to leave the SIMP terminology there, it should read SIP for those points.

Thank you for pointing that out, i have fixed it!

yup fixed the title, that was left over from the original proposal which was alot more than just this. Got some feedback that correctly pointed out it was overly complex.

Cheers and thanks for taking the time to respond!