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.
See my blog post here. All changes are highlighted in yellow
Major changes contained within Sushi Roadmap v2.1:
Introduction of a Tokenholder Relations role/responsibility
Introduction of an independent Community Oversight Committee
Introduction of a process for updating this Roadmap
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:
OLD LINK FOR DOCUMENTATION PURPOSES:
Yes, create TR
No, do not create TR
Community Oversight Committee
Yes, create the COC
No, do not create the COC
Roadmap Updates Process
Yes, formalize process for updating Roadmap
No, do not formalize process for updating Roadmap
Org Chart & Management positions
Yes, institute the Org Chart & listed positions
No, do not institute the Org Chart & listed positions
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
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.
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.
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?
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.
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.
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)
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.
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.
@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:
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.
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.
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.
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)
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.