Proposal to reorganise Sushi’s governance and operations.

With inputs from some core team members, samurais and community members/contributors.

Inspired from Yearn and YIP-61, Synthetix and spartan council, ORCA, Sushi Kisha club proposal, INDEX COOP, Naim’s proposal, Gabe’s proposal, Anett’s proposal.

This proposal is not final and comes with other proposals from community like Arca’s one. We would like to hear community feedback on this and potentially merge ideas from all proposals that have been made these last few days into a final one.



  • Create a life cycle process for future proposals in order to clarify and simplify the governance.
  • Implementation of SafeSnap to allow on-chain execution of off-chain votes from Snapshot.


  • Creation of a delegates board to improve transparency and internal governance.
  • Creation of a code of conduct.


Sushi has been running for more than a year now and has imposed itself as one of the “blue-chips” in DeFi.

Sushi is a community owned project that is ultimately governed by its community.

We are close to 2022 and nothing seems to have changed. We believe all core team members are doing their best to help Sushi advance. However, the community has also started raising some concerns as they feel that Sushi lacks transparency, proper communication and acts like a centralised entity.

Some examples highlighted include:

  1. Trident and Shoyu being great products and respective teams are working a lot to ship but are months late and no one seems to be accountable for it.
  2. Some partnerships and multichain expansions have also been executed at the expense of the Sushi treasury without seeking the community’s opinion e.g Harmony, Moonriver, Celo, FujiDAO.
  3. Contributors hiring guidelines are unknown thus giving no information on OPS real budget and expenses.
  4. OPS treasury is refilled by the Sushi treasury without needing to submit any sort of treasury report or budget estimations to the community.



Creation of a new proposal lifecycle as follow:

  1. Proposals titles will now be named: SGP#{proposal number}: {proposal title} [type (ex: SIGNAL, DRAFT, IMPLEMENTATION etc…]
  2. Proposals must be submitted on first and for at least 7 to 14 days to allow enough discussions around it.
  3. Proposals must be posted on forum with a poll, with at least 2 choices: for and against. A quorum should be determined to make sure only proposal with positive sentiment and enough tractions go to Snapshot (quorum is still TBD as it’s hard to prevent Sybil attacks on forum).
  4. Proposals must be discussed at the weekly Sushi forum call.
  5. Once all previous points met, the proposal will be posted on snapshot by members of the Sushi Delegates.
  6. To reduce the need for active monitoring of snapshot by the community, proposals ready will be posted on snapshot on the first or third monday of the month and the official Sushi twitter account will tweet about it.

Implementation of SafeSnap:

Implementation of the SafeSnap module on the treasury multisig to allow the execution of off-chain votes on-chain while keeping the veto ability of multisig.

The implementation details can be found in this proposal.

At a later stage we would like to introduce a rework of the sushi-powah model to give more voting powers to active community members and long term holders.
In the meantime we propose to add xSUSHI-eth LP, SUSHI-FRAX and tSUSHI (tokemak staked Sushi) to improve governance participation.


Creation of Sushi delegates board to improve current internal structure as well as provide more transparency to the community.

Creation of the Sushi delegates board:

Sushi delegates will be composed of one member from each Sushi department + 1/3 of community elected members (rounded up).

They will act as coordinator, guardians of the governance and provide transparency and accountability.

At the beginning of each quarter, each Sushi department will elect a new delegate or keep current one that will join this board.
Department will be: Dev, BD, Design, Marketing, Samurais.

Community will also elect delegates that will sit at the delegates board and act as a community representative.
They will represent 1/3 of delegates board (rounded up).
Every quarter a signal vote will occur to determine if a new community delegates should be elected.
If the vote reach quorum then a forum post will be created to allow everyone to post a candidature, after 14 days, a snapshot vote will happen and candidates with most votes will become the new delegates. during this process, old delegates will stay at delegates board.

Delegates will be compensated in the form of UMA KPI options (AMOUNT AND DETAILS TBD) to make sure they stays aligned with the project growth, act as community representative and thank them for this extra work.

Delegates are limited to 4 consecutive mandates, they can candidate again after a break of one quarter.

Roles and Responsibilities:

  • At least one member of the delegates to join the weekly forum call to take feedback and answer community questions.
  • Stay active on the forum, moderate talks, help on proposals creation, and porting them to snapshot once criteria are met.
  • 6 of the delegates will be elected as signers of the OPS multisig.
  • Hold bi-monthly meetings together.
  • Crisis Management* (All internal issues) with the help of third party (e.g. lawyers, auditors).
  • Emit a roadmap at the beginning of the quarter.
  • Emit a report at the end of the quarter on what have been done, new hiring and firings, what’s coming, treasury report (report example wip).
  • Validate hiring and firing with the help of the human ressources delegate.
  • Validate compensations and salaries with the help of the human ressources delegate.
  • Communicate on delays and ETAs.

Crisis Management: When internal issues between contributors, it will be asked to them to handle it internally with the help of the delegates. Delegates will have the last word.
Delegates will also handle emergency decisions that can’t wait for a vote (e.g. hack).
They are encouraged to engage external lawyer or auditors to help on these different crisis management.

When delegates don’t agree with each others then the decision is voted at majority.

Here is a diagram explaining the delegates quarterly renewal process:

Power in this new structure will be distributed as follow:

POWER/ENTITY Delegates board/OPS Community
Handle funds. Handle 200k SUSHI on OPS for quarterly expenses and salaries. Send back unused funds at the end of the quarter. Governance of Sushi treasury. Can increase of decrease quarterly amount of funds sent to OPS.
Owner of contracts. OPS multisig has ownership of contracts with high amount of funds that need active management. (e.g. MasterChef) Governance of contracts with high amount of funds that don’t need active management.
Hiring/firing inside core team. Yes if code of conduct was not respected or underperformance. Can fire only if code of conduct was not respected.
Partnerships. Can handle partnerships that cost less than 300k$. Governance of partnership that cost more than 300k$ (ex: Multichain liquidity mining).

We propose to elect 0xMaki, 0xTangle and Imsoftware (Matthew Lilley) as initial community representative to make the transition smoother as they are all Sushi contributors.
Proper elections will be held next quarter.

Creation of a code of conduct:

A code of conduct is in construction and will be finalized asap, it is inspired by the GitLab’s one and SCNightShade’s one.

Sushi contributors and delegates must always respect this code of conduct or will be fired from the team.

Every quarter, each core team member will be asked to publish a personal update on what he has been working on.

Later plans:

Once this structure is implemented, here are later plans for the DAO/governance.

  • Potential creation of a new legal entity.
  • Rework of the voting power.
  • Rework of the sushinomic.
  • Bootstrap new teams and projects with sushi rolls (prev sushi gigs).


Let’s rework the current org structure.


I like the Sushi startup.

  • For - Let’s rework the current org structure.
  • Against - I like the Sushi Startup

0 voters

Here’s a little poll for it.


While quarterly elections are better than yearly, how would community exercise their rights, if elected officials suddenly go into collusion? Wait 3 months while they wreak havoc and then ‘vote them out’?

I propose to implement a following scheme:
Every employee receives a ‘trust bar’ in a form of aggregate score that is calculated initially within 14 days of employment. The community commits their votes and then snapshot is taken.

Support votes can be withdrawn any time. If the support falls below 51% (out of all the votes cast for the position within 14 day period) - community hearings are called to address any issues that have arisen.
If the support falls below 30% emergency elections are called.


That’s we need Crisis Management, as stated in the proposal.


@hhk thanks for taking the time to think about an improved governance process.

As an organization that has gone through the process twice, we have experienced the pain points of the process but are also aware of the benefits it can offer the community.

I will speak on the Governance changes as that is more my expertise.

Glad to see you are nodding to the legacy protocols, such as below:

New emerging P2Es, such as Illuvium, have modeled their governance structure off this same idea.

A few thoughts on your proposed structure:

-Better documentation of quorum is needed (i.e. 5MM in favor to pass)

  • Having a clear understanding of quorum and milestones for votes is a great rallying point for the community and knowledge that must be understood by all proposers.

  • While I acknowledge it is hard to decide the right amount, making it transparent is important.

-Known intervals for posting votes is valuable

  • By allowing the core to focus on governance in predictable intervals, this creates a routine epoch for voting and fair (and needed!) marketing behind each vote.

  • It will also create more regular and frequent voter participation.

Quick question: If posting on Snapshot is limited to certain days, will there be multiple votes posted in one day?


Hey fig, thanks for the feedback.

I think so yea, the idea is to reduce the need for the users to monitor the forum and snapshot.

1 Like

I believe a more balanced approach to stop children infighting is a 50% community and 50% sushi development team vote for our new Leader. A true leader will balanced both and be more neutral to self indulgence of greatness. Bring Maki back to facilitate a smoother transition of Sushi to its next evolution steps… Fingers crossed

1 Like

We did this during August when 4 proposals went to Snapshot at the same time. The turn around was pretty decent imo.


I really like this. I think its really straight forward and drafted with a good understanding of project dynamics. My only comment is…

Does the OPS to be denominated in Sushi? If expenses are denominated in dollars, perhaps it would be better to have a dollar denominated budget. I would also just keep the excess in the multisig, expenses can fluctuate, so better to just keep everything there incase market fluctuations lead to rising expenses.

1 Like

Hey mason, thanks for the feedback!

We can denominate the budget in any amount I believe.

Mhhh why not but maybe in this case the next transaction between treasury and OPS is reduced so it matches the quarterly limit.

I would like to add 2 elements/open question to this proposal:

  • I really like the concept of product teams, which is not present in this structure but is in the Arca’s one.
  • I think the delegates board might have to much members, current proposal gives 9-10 members which might be to much people to handle emergency situations like hacks, especially if there is only 1 dev.
1 Like

ok - I was just thinking it should be denominated in whatever expenses are denominated in. So if expenses are in dollars mostly, then should be denominated in dollars.

for the second one, I like your idea about evening it out every quarter so its the right amount in the budget.


I voted yes on this proposal because I like the delegate structure and I think it’s required for an effective governance process, especially as DAOs scale. I do have some thoughts/comments for consideration:

  • I think there are too many total board members in this proposal. Do we really need delegates by department? This seems like overkill given that the delegate board will work directly with the Operational multisig/Trusted Contributors, as proposed by Arca, which should represent the interests of each product team.

  • Rather than department members, I would give the community-selected board the flexibility to choose contributors to sit on meetings on a temporary basis.

  • If we do decide to use departmental members, I think the community-elected delegates should ultimately represent the majority of the members, not one-third.

  • If we use department delegates, will they be compensated for this additional service? I have to think about this more, but I’m leaning towards “no”. This should be part of their jobs as leaders of the organization and incorporating compensation can lead to perverse incentives.

  • For the community-elected delegates, is this a full-time job?

  • I do think community elected delegates should be paid for this service, although I’m not sure UMA KPI options are the right choice. May cause unintended behaviors. For example, if we have a KPI option that pays out based on the roll-out of a product platform by X date, the board may be incentivized to accelerate the release prematurely. Instead, I think the community delegated members should receive tokens that vest based on their service period (e.g., one year cliff vesting or quarterly over one year). This is also aligned with how public corps compensate their board members (i.e., no performance-based comp, all service-based).



Ok, so now we have a Arca proposal, a Samurai proposal, a Dani proposal and a bunch of other options in between. If all these just put one party/person forward that will implement this proposal + anyone else who has a proposal and we can vote on who the community wants to go forward with… wouldn’t that be grand? This is why I create the interim CEO proposal.

This is not a competing proposal, but more of a META proposal. The longer we wait the more different ways will pop up to take Sushi forward, and even existing proposal will start to splinter into sub-proposals with different factions, different ideas. So why not open it up and allow ANYONE to propose a way forward (including a party or person that will implement this way forward) and let the community decide the way forward…

1 Like

Since 0XMAK signed a three-year contract (it is said), he should not be kicked out, nor should he become a consultant, but should continue his CEO’s duties!