Sushi 2.1 - Introduction of a Community Oversight Committee

Proposals
1

Summary

I envision this document will likely become a constitution for Sushi and as new items are added / old ones modified / etc, the version will update. With the release of Sushi 2.0, there were a few items that the community wanted to sharpen, namely oversight around aspects such as the compensation committee. These updates seek to build upon the foundation laid out by Jiro & team in Sushi 2.0.

Specification

See my blog post here. All changes are highlighted in yellow

Major changes contained within Sushi Roadmap v2.1:

  1. Introduction of a Tokenholder Relations role/responsibility
  2. Introduction of an independent Community Oversight Committee
  3. Introduction of a process for updating this Roadmap
  4. Introduction of an Org Chart & clear definitions of senior positions required for the DAO to run appropriately (which will be filled either internally or externally)

EDIT 5/23 ive reoganized the 2.1 proposal into a more wiki-like structure:

NEW LINK:

OLD LINK FOR DOCUMENTATION PURPOSES:

Polls

Tokenholder Relations
  • Yes, create TR
  • No, do not create TR

0 voters

Community Oversight Committee
  • Yes, create the COC
  • No, do not create the COC

0 voters

Roadmap Updates Process
  • Yes, formalize process for updating Roadmap
  • No, do not formalize process for updating Roadmap

0 voters

Org Chart & Management positions
  • Yes, institute the Org Chart & listed positions
  • No, do not institute the Org Chart & listed positions

0 voters

-pocketsquare

5 Likes
2

What flexibility is there to evolve the hardcapped salary projections for the listed org chart roles?

For instance, “$200k USDC for Product” is assuming we will only hire 1-2 product managers for this multi-billion-dollar ecosystem? That is laughably low/understaffed. IMO effective PMs are the critical force multipliers needed to optimize the building, launching & scaling of all our product lines.

What would the process be to hire multiple new PMs? Snapshot, approval by multiple committees, all of which thrown in complete chaos if one random Comp Committee member says No?

Just want us to keep our eyes open for what kind of hard friction points we are creating here. Overall, great proposal & a big improvement. But would hate to have all this hard work go down the drain when one person is able to hijack & hold hostage what the exec team members want to do in the best interests of the products

Remember our last CTO snap quitting when he felt like he couldn’t take appropriate action to solve problems without constantly begging for community/committee approval?

IMO we may have too many “committees” here instead of just empowering the elected exec team to do their damn jobs without interference for the window of time they have been appointed to do so

3

Thanks for the feedback. Would you mind detailing what committees there are outside of the 2 proposed here? And who is the ‘elected exec team’ specifically (names)? The Comp committee, which is part of Sushi 2.0, is there simply to act as industry experts and come up with & negotiate appropriate compensation packages by industry standards. The Community Oversight Committtee is there to simply approve the budget proposed by the Comp Committee. Without the COC, you open the Comp Committee up to abuse, so thats purely the defense mechanism there.

Are there more? You seem to allude to there being many more. I only count the 2.

Regarding anything else in the proposal such as the PM compensation etc, anything that is not highlighted in yellow was part of Sushi 2.0 and not something that I created so I would direct those questions to the thread below which is actively being voted on on snapshot.

As far as flexibility goes - I think anything is up for debate. However, we shouldnt get lost in the specific comp numbers. What I’m trying to create here is just what you say: empower the compensation committee to determine an appropriate industry level of compensation and bring that to the Community Oversight Committee for budget approval, then go out and do the hiring. Otherwise, every time we need to hire someone with a substantial package, it needs to go through governance and quite frankly we dont have the engagement or industry expertise within the governance process to make that work.

1 Like
4

Thanks for the writeup pocketsquare, it’s a nuanced application of TradFi principles to Sushi’s specific needs.

I’m interested in how we could ensure the CoC members can be replaced directly via snapshot voting. Can we fine tune the details on how this would work, in terms of multisig authority turnover in a non-amicable departure?

Personally, I feel that having terms measured in years is too long for a brand new system, and that 3 or 6 months gives the community more opportunities for feedback early on. A more technical question on voting for the CoC, but we need to determine if we are going to use statutory or cumulative voting to fill those seats.

For those against a CoC, let me provide at least one practical reason why. Currently, there is no legal mechanism by which to enforce the distribution of profits to tokenholders. The system today relies on us having a management in place that obliges and serves fees to the sushibar. That is fine when we trust management, but to future-proof this we need a mechanism by which to enforce management changes by tokenholders directly – this would be the CoC (board of directors).

Great to see this plan get traction, as I know you’ve been an advocate for some months now. Please let me know if I can help in any way.

5

Sure - I am open to ideas as I’ll admit I’m not a multisig expert. I see non amicable departures of COC seats as low risk though as they should be community members and not really have much more power than just OK’ing various budgets proposed by the team.

I hear you but generally it takes 6 months to learn a new gig so I feel like that might be too short. Especially as this turnaround gets implemented, things are going to take a while (like getting legal structure up and running). I’m also not trying to impose anything that will be too taxing on the community in terms of constant governance processes and also something that isnt taxing on the team. If they are constantly dealing with new people, new opinions, etc I am afraid it might slow them down. I want them to be able to focus on shipping. Really this is just meant to be a community-by-proxy so that they can operate autonomously with respect to certain day to day items without having to go through full governance. Perhaps once things are humming, we revisit the length and tweak it down the road as deemed necessary?

As always, appreciate the feedback!

1 Like
6

I made the following adjustment to clarify some language based upon feedback received

  • The COC is the final authority for posting Snapshots that pass the temperature check stage
  • It is the COC’s ultimate responsibility to ensure that governance items that pass the temperature check phase are ultimately posted to Snapshot

The spirit of this point is not that the COC is the only one allowed to post snapshots, but just that it is their ultimate responsibility to ensure that items do make it to snapshot (ie they should have the ability to post if necessary). The team should be able to post themselves, but this is meant to be a gatekeeping failsafe.

7

Currently, everyone with enough XSUSHI can create a snapshot. People with 200k+ XSUSHI can also post snapshots do you want to change that policy or?

1 Like
8

I am more concerned if the snapshots get executed in a timely fashion and improved communication around it (it is a bit improved by Truda’s notes), but going back to snapshot posting. Documentation about when a proposal can go to snapshot and what quorum and/or majority is needed for the proposal to pass will be a good improvement.

1 Like
9

There are 2 parts: ability versus responsibility. I dont want to change the ability, i only want to assign ultimate responsibility

1 Like
10

Am working on this. Will have a proposal up in a day or 2

1 Like
11

Entirely agree with this - we have seen increased confusion around the governance process and execution of votes. More clarity is needed.

Returning to @pocketsquare’s original proposal:

  1. Tokenholder Relations - Abstain

  2. Community Oversight Committee - Yes

  3. Roadmap Update Formalizing - No

  4. Org Chart - Yes

I fear that some of these additions will add unwanted rigidity to the DAO and product development. Others are no-brainers - such as an Org Chart and an Oversight Committee.

How do you divide responsibility between Community Oversight and the core team? What rights are they allotted that the Core team does not have?

Tokenholder Relations feels a bit too similar to Investor Relations in traditional finance. How do folks report on this without a standardization for financial reporting in Web3 or a regular cadence for updates?

What will be the size of these two groups? (Oversight Committee and the Tokenholder Relations)

1 Like
12

Should’ve been under business development role. Remember how lacking the communication with other protocols were. Especially when said protocols had sushi bags.

The role you describe will overlap both Samurai and Marketing. Either split it between them definitively, or form an ad-hoc group (1 sam 1 marketing intern) to handle it.

If core clique intends to listen to the community, such formalization is not needed. If they don’t - there’s no point in having it. Because plenty of ways to ignore COC’s decisions.

Nice to see you attempt to formalize conflict resolution. However, given our current predicament, where any call for public vote ends up stonewalled with Arca bags, or w/e entrenched entity (looking at you, Alameda), an COC as a whole will likely get voted out before any opposition that the said whales back. It’s kinda recursive.

Too much entities. Such bureaucratization will result into infighting departments and higher speed of plundering the treasury.

CFO should be just one plain accountant or a contractor. Tokenomics is too broad of a task to be granted for one person.

Yearly budgets should be quarterly with strict KPIs attached.

I am still against ear-marking bigger half of the treasury.
I am still against the lack of transparency for budget expenses.
I am still against rewarding community members vying for a chair with treasury salary. The appreciation of the sushi they already hold should be a sufficient reward already.

Not that anyone cares. The encapsulation of management has been completed.

1 Like
13

I dont particularly care where it sits. I put it with Marketing in 2.1 but it can sit within BD, that would also make sense. The spirit of it is simply to create a formal person (can be a current team member doesnt have to be a brand new outside hire) to be the main contact point for funneling token holder contact through rather than going to all the various producers. Developers should be left to develop.

I hear you but throwing our hands in the air and saying it isn’t worth addressing is not productive nor helpful. This isn’t necessarily the final version, but its a step in the right direction IMO. If there are ways to fine tune this in your opinion, I am definitely open to collaborating on it.

I agree there is a lot to take in here but again, several of these positions can / are already filled and this is just formalizing reporting lines and accountability of process which is necessary for right now.

Quarterly i think would create a bit too much red tape / governance process and detract from the day-to-day producing but I agree strict KPIs are needed. A) they need to be defined and B) they need to be able to efficiently be measured. Again, something we may need to define in later versions but this first broad-stroke can be more high level.

1 Like
14

@pocketsquare This is fantastic work and we are supportive of the formation of the Community Oversight Committee. It is a step in the right direction and promotes decentralized decision-making while managing scale. Two questions for the community’s consideration:

  1. Should certain items be subject to a direct community vote even with the COC? For example, hiring of executive officers is a key strategic decision. The COC can propose officers to-be elected (including proposed pay packages) and the community can vote on the hiring. This is a “belt and suspenders” approach to governance however we think it is valuable for key items because the community has direct oversight.

  2. How will the COC be held accountable? Will there be quarterly reports that summarize decisions made, COC member attendance at meetings, etc? Regular reporting provides transparency and holds COC members accountable.

C3

1 Like
15

Re: 1 … yes, i see the COC being like an advisor to the community. Putting forth recommendations on larger decisions. In the case of management type searches, they can be part of an interview process, and ultimately relay their findings and suggestions to the community for vote. They act as a sort of information relay to the community who doesnt necessarily have the time to get really in the weeds with every decision.

Re: 2 … accountability is a big focus for me. Nothing works without accountability, so having the COC be accountable to the community is important. I structured this by saying they need to be re-voted in every 2 years. Trudahamziks proposal, which we will likely combine ours, said 6 months. Maybe we meet at 1 year terms with re-elections. There is also a bullet about loss of confidence in a COC member. If the community feels that a COC member is no longer acting in the community’s best interest, then the community can propose a special election to remove them. As for reporting … yes, some reporting would likely be required, but there is also a bullet to make it mandatory that COC members attend at least 1 community call per month to discuss whats going on and update everyone.

2 Likes
16

Just centralizing everything in this thread.

Firstly, ive rewritten the governance items, including my potential proposal, in the following gitbook which is in a wiki-like format which should help discussion (ie, ‘lets discuss item 1.2.2 i think it should be xyz’)

Secondly Re the concerns raised in the May 11 All hands (per notes found here)

MY COMMENTS IN ITALICS

Community Oversight Committee

  • Boring & 9x9x9 are happy to fill 2 of the seats → great, several large stakeholders are already acting in an advisory capacity but one of the core principals of being on the COC will be attending community calls and acting as a communication conduit between the community and the dev team (so that they can focus less on community communication issues and more on shipping product)
  • Team Concerns:
  • Legal issues (Jurisdiction) → concerns can be discussed but need more specifics re: concerns
  • May not be ideal logistically e.g Small requests require multi level of approvals → intention is not to muddy small decisions. See item 2.2 Oversight for the DAO in the above link which details the COC’s reach. The only items that the COC should be approving are annual operating budgets, management level compensation, transfers from treasury to ops wallet (which is infrequent), and ensuring snapshots are posted. Day to day operational decisions are at the sole discretion of the Sushi team.
  • Need to define clear responsibilities e.g Level of involvement → see above
  • Who should sit on the oversight committee? Should they only be large Sushi holders? What are the ramifications if they sell their entire Sushi stack? Should they then be removed? → having a financial incentive is helpful but i dont think required. Anyone, assuming they present their case and are working towards the benefit of the DAO i think should be able to put themselves forward. And holdings should not preclude someone from serving. Per item 2.3.3 Special Elections if someone is deemed to no longer be operating in the best interest of the community, they can be removed by a special election. Therefore, holdings doesnt necessarily matter, just that the person operates in the best interest of the community.

Again all of this is up for discussion and I encourage feedback.

4 Likes
17

Hi @pocketsquare - thanks for synthesizing this.

Expressed this to others earlier but would love to re-iterate my interest in joining the team.

I would like to join the Community Oversight Committee as a key community member.

As a partner of SushiSwap with vested interest - Flipside believes in the long-term vision of aligning the core team and community. A few qualifications about myself:

  • New User of the Month @ SushiSwap in October 2021

  • Review Committee @ Aave Grants DAO

  • Transferability Committee @ Paladin

  • Protocol Specialist @ Flipside Crypto

These are only a few of my accomplishments across Ethereum. As a greater team, we are involved across a myriad of protocols and DAOs on different L1s.

A delegate, an advisor, an investor, and a builder - worth discussing more about the fit?

cc: @BoringCrypto @Trudahamzik @9x9x9

3 Likes
18

Certainly worthwhile. If/when this proposal passes, the next step will be to nominate/selfnominate candidates and put through a governance process to vote in.

3 Likes
19

SushiSwap DAO Guidelines analysis
This is the link to SushiSwap DAO Guidelines

I summarize it in one page and this makes it easier for the community

DW1
DW1978×1280 203 KB

To be able to examine them and give ideas for development
it good work the ideas are good and a lot of effortt into preparing it
some points for discussion
proposal start from the forum or the discord decision-making system is a good system, but it has some points

Of course , the sushi community has experts in the crypto industry with great experience in various fields and is able to properly evaluate any proposal but in the end they are not obligated to follow all proposals interact or comment on them

If the proposals are sorted we will find
1.There are some proposals that may be incomprehensible, specialized or complex, or explain complex ideas or long plans only someone who is expert in the crypto industry understands it
and not all in the forum is expert but of course they should participate in the decision-making
Thus, whoever reads the proposal becomes unable to vote or express an opinion, and therefore ignores the matter

2.There are very good proposals and no one votes or comment on and therefore it ignored
Although it is useful for sushi because community does not understand its importance

In fact I think any proposals or good idea if it specialize in the field of crypto or complex, will never pass through Temperature Check

Naturally strong proposals are complex and specialize in crypto this prevents Sushi from benefiting from the ideas, proposals and opinions of experts and specialists in the community
only simple, easy ideas are what find interaction and pass through Temperature Check

I read this
1.2.2 Internal Review
Once an item passes the forum temperature check phase and is deemed to have enough traction within the community to move forward, the COC shall review the proposal with the SushiSwap development team to review
Estimated development requirement & timeline
Potential risks to the platform
Potential revenue opportunity for the platform
nce this is complete, the COC will communicate this back to the community in the nex step:
​
COC begin review just if proposals pass Temperature Check
The solution is in my opinion Community Oversight Committee (”COC”) should works from the first step Temperature Check
be obligated to read all the proposals in the forum and through the comments provide a specialized opinion in a simplified way whether positive or negative explaining the benefits or harms do not ignore any proposal

Thus, this helps the community members to build an opinion and the community will be able to understand what this proposal is even if it is complex and specialized in the field of crypto after understanding good or evil within the proposal

Snapshots
1.2.4.3 Snapshot Posting
Snapshots can be posted by:
Any community member with 200,000 SUSHIPOWAH
Any senior team member
Any Community Oversight Committee member

I do not understand this point well.
can these submit a proposal to Snapshot directly without presenting to the community??
I think this is a danger can easily pass something against the interests of Sushi in this way

Community Oversight Committee (”COC”)
The committee should include members who have legal, financial, technical and other expertise the conditions or descriptions of the experiences and skills of the elected members of this committee are not mentioned
There should be specifications and criteria in terms of experience and competence to elect members to the committee

The committee COC has very broad powers
In this way, the executive team will be unable to perform its duties its role should be oversight and advice and clear boundaries should be drawn between its role and that of the executive team in order not to make the executive team at the end frozen, unable to do anything
need to add additional explaining the boundaries between the committee and the executive team

Operations
There is no responsible role for products responsible person about adding new ideas and new products and developing existing products I mean developing products as concept not as code

I think pushing sushi forward will only come through research and development and adding new features to existing products
Searching for new products in the crypto world to add to the current products range
Perhaps if in the future it is planned to bring someone who is capable of this, it will be a good thing

If there is something inaccurate in the illustration please let me know and I will correct it

20

Yes the temperature check phase is imperfect in that complex items that require technological expertise to evaluate are sometimes lacking unless the team steps in to give their view. The idea here is that the COC can help with this. The team and/or the COC can certainly step in during the temperature check phase to give an opinion. Just because something hasn’t fully passed the temperature check phase doesnt mean it cant have an internal review. But things should not progress to snapshot unless they have had a technical review communicated back to the community from the team/COC. So step 1 & 2 can happen simultaneously.

Technically thats how it is now. There is no mechanism to stop someone with 200k+ sushipowah from throwing up random snapshots, but they won’t meet quorum so would be a waste of time. The spirit of this bullet is simply to provide a person (or persons) who is ultimately responsible for posting snapshots that have passed the rest of the governance process. Someone the community can look to and say ‘hey why haven’t you put this up?’. Its a gatekeeping prevention measure.

I wouldn’t say they have ‘very broad powers’. From a multisig perspective they should need to approve any txn going out of the treasury. The operations wallet is at the sole discretion of the team for their day to day activities. Other than that, they approve things like annual operating budget (including estimated compensation budgets on an aggregate basis), ad hoc compensation committee items (which aren’t day to day items typically), and then are there to be a communication conduit for the community & the team so that it frees up the team to focus on shipping product rather than having to hop on community calls every week and constantly update the community. Beyond that the COC shouldn’t really be meddling in day to day activities unless solicited specifically by the team for some strategic input.

I think this would be the Head Chef