Governance Reorg Pre-Proposal

Governance Reorg Pre-Proposal

Drafted by zes

  • Community driven governance is great but lacks the execution pace needed to make SushiSwap a force to be reckoned with. Maki has been the one who created significant traction for SushiSwap since the start and the one who has a vision for the project → temporarily establish a core team led by 0xMaki
    • Bi-monthly roadmap be fully transparent → community reserve the right to veto with 40% quorum (if reaching 40% of supply, then veto)
  • Establishing a core team would allow for faster decision making → better team/faster iteration/development cycle → more innovation → better $SUSHI

Narrative

The Dharma for AMM

  • For token issuer: the best place to issue new token and create a market for it
    • One click token creator
    • One click provide liquidity
  • For liquidity provider:
    • One click provide one-asset liquidity
  • For other fellow farming protocols
    • API for other protocols to easily create pool and farm
    • low impermanent loss (kinda hard to implement lol)

Product Roadmap

  • Need to determine vision and narrative first → and then strategy → and then product roadmap

Logistics Roadmap

  • Growth fund
  • Hiring

Transparency

  • Quarterly/monthly roadmap
  • Live agenda (daily/weekly sprint update on progress)

tfars iuyt balitd, iykyk

Let’s discuss and refine this proposal it is vague on purpose so we can talk and improve upon before submitting a correct proposal !

14 Likes

Will there be an public channel for people who may want to join or contribute to the core team?

1 Like

Love this great start to Sushiswap’s organization @0xMaki! Thanks for continuing to lead the community.

RE: Vision & Narrative - I agree with @0xMaki 100% that this is one of the most important things to address immediately, and IMHO THE most important thing to decide on ASAP. I’ve worked in the trad. venture capital/startup world for 20yrs and one thing holds true for successful ventures regardless of whether we’re talking about trad./blockchain/defi worlds…They all have clear and unwavering Missions and Visions. We have an opportunity to differentiate on this point alone. Uniswap only describes “what” they are: " Uniswap is a decentralized protocol for automated liquidity provision on Ethereum." They don’t say “Who” or “Why” they exist. To give everyone some food for thought as I’ve written my fair share of vision and mission statements:

“Sushiswap’s mission is to be the world’s leading permissionless decentralized AMM”

“Sushiswap’s Vision is to make the benefits of decentralized finance applications accessible to every person in the world”

RE: Governance Platforms: I’ve seen a lot of discussion in Discord @Governance around what sort of governance platforms/protocols to be considered. We need to collate these and create shortlists for voting ASAP. I.e. Aragon: There needs to be transparency around our discussions with them and our consideration of working with them. Same for any other options.

RE: Governance Working Groups - I worked in the ICANN domain community for over a decade and am a strong proponent of their multi-stakeholder and working group frameworks. Their success in running the DNS across a global constituency and a diverse community of countries, cultures, languages, time zones, etc., is nothing short of a miracle of multi-stakeholder governance. I strongly encourage us to implement a similar Working Group framework driven by volunteers with oversight from the Sushi Core Team. See this link for background on the ICANN Working Group framework: https://icannwiki.org/Working_Group#:~:text=ICANN%20Working%20Groups,their%20expertise%20on%20certain%20issues.

RE: Technical Governance - It’s equally important that we implement a technical governance that embodies the spirit of decentralized governance but that also ensures that development and innovation progresses in a methodical manner. Again, I point to another globally recognized multi-stakeholder organization, the Internet Engineering Task Force (IETF) (https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force) and their “Request for Comments” (RFC) format. By setting a technical (and other) proposals format, we will be able to keep track of development in a systematic manner while at the same time maintaining the decentralized governance principals that we live by.

In summary, I believe our task of establishing our governance principles and standards requires these three aforementioned to be immediately addressed and instituted. Finally, we need deadlines to hold ourselves accountable and to keep things moving forward.

6 Likes

tfars iuyt balitd!

I fully agree this is the way we need to go, perhaps in time the structure we take will change, but for now, we need a clear and strong voice to represent the entire community’s vision as best as possible.

That said, I imagine the community would like to know what type of positions you are looking to hire for this core team.

3 Likes

Both mission and vision statements are on point, this is the type of discussion we need! cheers

2 Likes

RE the vision & narrative: we should play the permissionless ownership and sushinomics card, everyone can own part of the revenue generation protocol. to differentiate ourselves from uniswap.

2 Likes

Take a stab at it! The more versions we get, the faster we’ll settle on one! BTW - I added permissionless to the Mission per your suggestion slight_smile:

We should assign specific powers. I propose starting w/ the ability to edit the pairs in farms, since that is needed ASAP.

Performance Bonus Proposal

  1. Introduction of the Performance Bonus (monthly)
    GM & Team Performance Bonus
    The team should have a high focus not only on the daily regular operation/development (salary pay) but also to continuously increase the value for token holders and be directly extra compensated for that (Performance Bonus Incentive).
    The team should feel recognized for the results of the increased value added for the token holders. Imho should be higher than the salary => salary should cover only the basic needs and to represent only a safety net for the team. Main goal of increase value should be aligned with the incentive and everybody in the team should feel always this is the main target not the basic salary.

Performance Bonus Value= 1-1.5% x Increased Market Cap (excluding inflation !)
Calculation and distribution => monthly, for ex. every 10th of the month, calculate the average market cap of the previously 30 days.
Ex. : Market cap on 10th actual month - Average Market cap of last 30 days = Increased Market Cap
Payment => buyback Sushi -> distribution to the team, vested for 6 months with 1/6 monthly release
Team distribution => equal parts to all full time “employee” or a different scheme proposed by GM

Start date: 25/09/2020

  1. Create the Advisory Board (7-9 members)
    There are many excellent crypto experts that voluntary helped during the last weeks with brainstorming, strategy, discussed/written highly professional articles, opinions, suggestions, technical support, etc. and dedicate their free time just for passion (no compensation).
    Unfortunately, most of them cannot be fully part of team (missing time, many projects, low compensation), some get offended by negative/aggressive talks/comments on forums, tweeter (from us, competition, haters, etc.), slowly moved away from the project and now are very discrete vs. the project, maybe just observing.
    I strongly believe that we need them to remain involved with us and participate in brainstorming, strategy, talks, etc. on daily basis.
    We need the return of that positive energy and vibe internally and externally. 1-2 Token holders could be part as representative of the community.

Advisory Board

  • composed by any interested, with various skills, who helped in the last month, still want to help but cannot dedicate full time (es. SBF, Larry, Adam, etc., 1-2 community/token holders representatives)
  • available for a daily 0.5-1 hr meeting as of now, later every 2-3-7 days or when requested by the team to discuss strategy with the team, brainstorming, new ideas, networking, crypto market innovations, crypto market status/direction, new services, external collaborations, external events, meet ups, etc
  • provide feedback/support/suggestion/help to the GM and operational team daily
  • no salary compensation
  • only part of the performance bonus (70-75% GM & Team / 25-30% Advisory Board)

Start date: 25/09/2020

Omakase DAO

In this post, I point out the main differences between traditional governance and blockchain governance from a political philosophy point of view. I then propose practical solutions for SushiSwap to create the first philosophically- and pragmatically-sound DAO.

As we stand looking at the dawn of a still-untapped blockchain application, Decentralized Finance, new mechanisms need to be employed to tackle blockchain-specific tasks. For this, we need to look towards normative considerations of political philosophy, rather than try to re-create structures known from traditional finance or even traditional politics.

Systemic revolution of decentralized governance

Decentralized governance is revolutionary. It’s not revolutionary because it’s based on blockchain, it’s revolutionary because it systemically shifts the paradigm of what we think is possible within political systems. Namely, we’ve historically come to understand political systems as a two-fold process: the establishment of laws and the execution of laws. This holds true for both modern and ancient systems. Fundamental rules keeping communities and nations in existence are a persistent concept: it’s impossible to imagine a society in which each continually acts on his own accord without any mutual rules, as one’s needs will eventually clash with someone else’s. Hence, laws are necessary and some sort of entity is needed to create them. Following the classics of political philosophy, I’ll call this entity the Sovereign.

For the laws to be more than words on paper, consequent enforcement needs to take place. I call the enforcing entity the Government.

In all of today’s political systems, the Government consists of a small number of citizens. At the same time, the Sovereign’s numbers vary in as far as the practical definition of the Sovereign also naturally varies from state to state. It can be said, however, that in no existing political system does the Sovereign equal the whole population: for laws to be efficiently created, a group of elected (or not, in non-democratic systems) representatives is responsible for creating, proposing, and voting on laws.

The Government and the Sovereign on the blockchain

The revolution of decentralized governance means this: Every active participant of the system can influence the law-giving process and be a part of the Sovereign as a result. The traditional Government, on the other hand, is completely replaced by the Code. The blockchain code becomes the entity responsible for enacting decisions made by the Sovereign. This means two things:

  1. The will of the Sovereign will always be perfectly-enacted, as it’s the governance participants who write the laws into code, propose, and vote on them. The execution of the code is completely objective and can only be influenced through passing of new laws by the Sovereign: the law is as good as the code written.
  2. The Sovereign doesn’t need representatives to vote on laws proposed: any participant is able to express their opinion on any law-to-be.

Those two points offer benefits impossible in regular political systems. In an ideal world, it allows all of its participants to self-govern in an unprecedented manner.

Firstly, a regular Government will always consist of people with their personal agendas. The execution of any law will always be flawed not because the law itself is flawed, but because the executor can never perfectly interpret and enact the will of the Sovereign. In blockchain, it’s impossible by the very nature of technology, there’s no room for misinterpretations and consequently misexecutions.

Secondly, the Sovereign not needing representation in voting means that, similarly to what was said above, the personal agenda of a voting representative doesn’t play a role anymore: the laws created will always express the majority’s will.

With regards to the second point: while decentralized governance allows for all creation, proposing, and voting to be done by the Sovereign, it’s pragmatically-speaking sensible to create representatives responsible for writing and proposing laws. The reason for this is that any proposal needs to consist of executable code for the blockchain to interpret. The nature of programming in its current state requires qualified engineers to effectively translate ideas into code as potential errors can’t be easily fixed. For the same reason, it’s paramount for any proposed law (or code) to be thoroughly verified before launch.

The Constitution

Knowing the above points, the most crucial aspect for SushiSwap will always be the law-making process which goes from creating, proposing, and voting on a change’s inclusion in the blockchain. This process needs to be described in a constitution-like document which would ideally be voted in favour of by all owners of the $SUSHI token, i.e., members of the community.

Eligible Voter

I define a voter as someone financially invested in SushiSwap’s success, i.e., an actor staking either ETHER/SUSHI LP or xSushi for a given period of time. (to be defined)

Voting

Two main challenges can be distinguished here:

  1. Both blockchain technology and the DeFi landscape changes rapidly. SushiSwap should be able to implement smaller proposals without having to refer to a community vote. Ten small changes might be as important and beneficial as a single big one, but the law-making process requiring a quorum for each small change entangles the system in bureaucracy and stifles efficiency. It’s implausible to expect the community to micromanage SushiSwap by voting on each issue.
  2. Proposals of larger magnitude, impacting fundamental areas like inflation, should not be taken lightly, on the other hand. This is namely where the main strength of decentralized governance comes into play: community members should be able to express their opinion directly or at worst delegate their voting rights to trusted actors.

To answer the first problem, I propose delegating on-going, decision-making capabilities to select groups of community members, consisting of professionals in the relevant area.

The specific areas where team-led decision-making happens, still need to be defined. Their responsibilities and capabilities need to be, however, strictly defined to avoid the clashing of decision-making authority with other entities.

To answer the second problem, I propose establishing voting categories and voting thresholds.

Similarly to republican and democratic systems, different laws carry different weight in SushiSwap. For this reason also, it’s imperative for the greatest possible majority to vote in favour of the initial Constitution as it’s the most important document SushiSwap governance will ever have. For the same reason, it’s the only document requiring a supermajority for a change to be enforced in this draft.

Voting thresholds are therefore necessary, of which I propose two types:

  1. Regular majority (50%+1 vote) for a Regular Proposal
  2. Constitutional majority (75%) for a Constitutional Proposal

Proposals and quorum

Proposals need to always be created in the form of executable code. Proposals can be:

A Yes Or No Proposal. Example: Change trading fees’ rewards percentages to 0.2% going to liquidity providers and 0.1% going to those staking xSUSHI. (currently 0.25% and 0.05%)

A Multiple Choice Proposal. Example: Change trading fees’ rewards percentages to 0.2% going to liquidity providers and 0.1% going to those staking xSUSHI OR change rewards to 0.15% for liquidity providers and 0.15% for those staking xSUSHI.

In the Yes/No Proposal, a quorum of voters is synonymous with the voting threshold established previously, meaning 50%+ of all voters. Refraining from voting by eligible voters means a NO vote.

In the Multiple Choice Proposal, naturally a quorum needs to be achieved. The number of voters required for the highest-voted choice to be implemented is:

  • 50% of eligible voters for a Regular Proposal
  • 75% of eligible voters for a Constitutional Proposal

Similarly as in the Yes/No Proposal, abstaining from voting by eligible voters means a NO vote to any change happening.

Voting Period

After a proposal is submitted, voting takes place. Different voting categories call for adequate voting periods:

  • Regular Proposal voting takes 3 days
  • Constitutional Proposal voting takes 7 days
1 Like