Sushi Governance Process and Cadence

Sushi Governance Process and Cadence


Creating a process and cadence for proposals in the Sushi Governance process is crucial. We also need to look at suggested timelines for votes on Snapshot. It would be useful to set up a Governance Committee that can ensure the correct process for proposals to make it to Snapshot for voting. They can also help advise and shape any parts of the proposal to ensure its delivery is understood to its full capacity. There are also proposals that have passed a Snapshot vote, and need further review, or strategies on how to execute and implement them.


  • Create a committee to own the Governance process within Sushi. This committee can help strengthen ties between the community/DAO, DeFi power users, Ops/Core, influential investors, and the proposers. Creating a process will help increase awareness, engagement, and transparency. It may only need to be 2-3 people to be effective.
  • Have the committee revisit existing passed proposals, look at ways to execute or implement, and outline the steps required to do so.
  • Dedicated time period for votes. Perhaps a specified time for standard proposals (7 days), and expedited timelines for time-sensitive proposals with proper exposure (4 days).
  • Review SUSHIPOWAH threshold: Same, lower, higher?
  • Transparent reporting for the community/DAO with up to date developments.
  • Providing further engagement from the Sushi Marketing team to raise awareness through Twitter, Discord, medium, etc.
  • Direct outreach to those involved in the Proposal Committee with a detailed outline of what is up for bi-weekly review.
  • Further promotion and exposure of the Sushi Forum call.
  • Directing more attention and traffic to the Forum site for deeper engagement. Incentives such as POAPs for engagement are something that has been conceptualized.
  • Leveraging the Samurai’s and the Journalists tools such as the Sushi Times for greater reach, exposure, and interaction.
  • Greater frequency of updates to the community during this concentrated period of building and shipping.

Details of the workflow around the lifecycle of proposals:

  • Proposals can continue to be brought in directly to the Forum for review by community and team members. Polls and comments can be tallied.

  • Proposals posted before Monday 23:59 UTC will be up for discussion during the Weekly Community Forum Call held on Thursday’s at 19:00 UTC.

  • After Proposals have been discussed on the Weekly Forum Call, they will remain up for review for 1 week.

  • Feedback in the Discourse Forum can be applied to the proposal as edits over the week. If the proposal is gaining traction and has positive sentiment towards it in a poll created, it will be brought up at the Weekly Forum Call the next week.

  • We will review the proposal again, and have any final comments on it. If positive sentiment and no objections to the proposal from community or Core, then it will be put in queue for Snapshot voting. We can discuss the window length of the vote, but will propose either 4 or 7 days as options.

  • Snapshot voting will have a bi-weekly cadence with a start date as Monday ~18:00 UTC.

  • With the increase of SUSHIPOWAH (SPOW), we will allow more participants to weigh in on the voting process. With the proposed pools, here is a current idea of how much can be added:
    → xSUSHI-ETH: 1.4M @ 2:1 = 2.8M
    → SUSHI-FRAX: 220k @ 2:1 = 440k SPOW
    → tSUSHI (Tokemak): 4.9M SPOW
    Total Added: ~8.14M SPOW for Governance

  • There will be a dedicated person or persons in the Governance Committee who will be in charge of ensuring Snapshot cadence protocol is followed for posting the proposals for voting.

  • All proposals that go up to Snapshot will get marketing and awareness from Sushi. Announcement Tweets on Twitter from SushiChef account, ReTweets from various Sushi members, announcements in Discord, articles in the Sushi Times, Medium articles, coordinated efforts with protocols involved with the proposal, etc. Hopefully with this coverage and inclusion of extra SUSHIPOWAH, this will be sufficient coverage to inform the voting caucus.

  • In order for a vote to pass, it needs to reach a quorum where it meets or exceeds 5 Million SUSHIPOWAH in favour of it.

  • If the vote fails, the proposal can go back to the drawing board and begin the process again.

  • If the vote does not reach quorum but has overall positive sentiment, we can look at posting the proposal again with any required adjustments from voters, and attempt to increase exposure.

  • If the vote passes, a communication group will be created (if not done already) to work towards next steps with the Core Team to issue any funds, or provide required support to implement the proposal.

  • The Governance Committee will continue to engage bi-weekly or monthly at a minimum with the proposer to ensure the proposal gets implemented correctly and has the support required.

Hopefully with this framework, we can start to build out a process that is clear and effective that can ensure the success of governance in Sushi.

This is a framework for now, and specific details can be fleshed out in the discussion around this. Some polls will be available as a temperature check for feedback.


Improving the current governance structure to ensure process and clarity. Also grow participation in governance within the Sushi Community, and inspire others to get involved.


Too complex, and would require too many resources. Process if sufficient as is.


Process and Cadence

  • Implement process and cadence to Sushi Governance
  • No Thanks

0 voters


  • No change to current SUSHIPOWAH

0 voters

Snapshot Length

  • 7 Days
  • 4 Days
  • 4 or 7 Days depending on proposal needs

0 voters


Proposals could have different phases instead of having one giant proposal. The guideline below is more for product-based proposals, but We may adjust this framework for different proposals later.

Proposal Phases

People can put together the first round of their idea, and the community could provide some initial feedback.

After they can put together the 2nd Draft with feedback more solid details, Any sketches, diagrams, wireframes, or other low-resolution expressions of the concept to help understand the feature’s shape, size, and requirements. This could also include screenshots of competing or analogous products/features.

This could be after the 2nd Draft is approved so the team can start work, perhaps an initial round of funding. The required deliverables for this stage can be:

Detailed Feature Spec, Requirments & Dependencies
Experience blueprint, wireframes, static designs, Figma prototypes
Proof of concept, the first round of design

Detailed content requirements
Determine the exact content and copy (images/graphics and text) needed for the feature.

Time estimates, timelines, and risks
An estimated roadmap with a timeline of when the proposal team will complete deliverables. Identify any risks that may cause the proposal to fail.

After the complete outline is approved, they will receive funding to align with the roadmap provided. The proposal team can share progress reports with the community during the build process.

The proposal team will share the final product with the committee; this can be vercel links etc., and the committee can decide if the product is ready to ship

The committee & core can evaluate the proposal’s impact on the ecosystem, and the community can reward the team if the project hits the desired KPIs.

If we create a culture where proposal teams have to meet min requirements and check-in periodically before payment, it prevents people from making half-done products then running off with the money. In addition, it helps create a culture of transparency with projects.


@Tangle thank you for your relentless efforts in governance previously and your willingness to refine and improve the process.

As somebody (@Tangle) who spends a majority of the time interfacing with the community, I think these considerations are important. It reveals valuable pain points.

I will point out a few thoughts which make sense and should be implemented:

First of which is the point below:

These three pools and assets are great additions to expand voting power and participation. The addition of tSUSHI alone will add 404 eligible voters into the ecosystem

SUSHI-FRAX adds 57 voters and xSUSHI-ETH 122 voters.

While it is interesting to see the addition of SPOW it is important to look at the contribution in terms of voters.

Quick question - how do you decide between a time-sensitive proposal (4 day voting period) versus a standard proposal (7 days)? Is there a certain cost threshold or subject?

I would welcome these changes to boost engagement in Discourse, create a more cohesive community call, and provide regular cadence - and understanding - to Sushi’s governance.


Feels like the process and cadence and the Sushipowah topics are less important to me than a faster process on the Snapshot voting.

As there were concerns during the forum about a potential for tons of decisions to be voted on, I think a priority should be a rapid processing of snapshot votes. Again, I say this as we actually need to make core contributor compensation/equity a top priority and if we’re going to put these things up for a vote, we need to move quickly through governance and other administrative matters.

1 Like

Tangle, this is lovely proposal. Some thoughts:

Sounds like what Samurai have been doing. Should be elected within them.

Is this for the finished proposals? I don’t think it would be enough for the under debate bigger ones like new sushi governance.
If for finished - I propose to create a dedicated discord channel, which will issue daily alerts and reminders of what proposal are being put to vote on that day.
I was considering a 14 day process for voter gathering with daily reminders and option to expedit the resolution, if the quorum is reached early. But if only finished proposals are put to vote - 7 days should be enough, provided we notify everyone as much as possible.

Could be Samurais as well. Although direct outreach might be better handled by some sort of PMs, if we end up creating one.

Voting turnout is important. We might advance the POAPs to carry some sort of meaningful value behind them. See how RomeDAO issues NFTs with special roles/benefits to participating users.
Or we could go plainly incentivize every voter with a tiny amount of sushi like UMA does.
Anyhow, we really need to quantify our community numbers. A few dozen views that non-VC/Core submissions get is disheartening.

Again, is good for finished proposals. It’s too little time for the ones being drafted / seeking community input and would unnecessarily waste discussion time.
I would propose a flag that the proposal creatior can set: as in “ready for review” that would trigger the flow you describe.

Would this be enough for community votes to gain traction? Would love some stats on how previous proposals wore voted. Perhaps, the new analytics group that were approved would be up to the task?
Very interesting to know the %% of the community that actively votes vs total voting power available.


It is very likely that any votes we might have before new rules are voted in will be via the current rules. So as long as quorum is reached - all good.


Good to know. Less familiar with existing rules. This is probably the largest DAO in which I’ve participated. So, playing catch up.

1 Like

Fantastic proposal!

Regarding incentives, I have considered writing an incentive proposal around POAPs and to get more people involved in voting, including smaller holders. The idea would be to provide a raffle at based on those with the particular governance POAP. The raffle could be a small amount of $Sushi to one or more individuals that enter the raffle which would require voting and a particular POAP in their wallet. Social media could play a large part in getting the word out about the vote and raffle incentive.

To me it seems there is a balance between too much incentive and too little incentive, so it is hard to determine the appropriate amount. The main concern I have with my idea is incentive to pass or not pass snapshot votes, which is why the incentive to vote would be the same regardless of the outcome. If people think my idea makes sense I will write a separate proposal or some of these features could be added to this proposal.

Looking at claim rates on the POAPs it appears social media has a big impact on the number of people that vote.

2nd Analytics Vote 609 POAPs minted.
Collateralize Tokemak Reactor: 798 POAPs minted.
1st Analytics Vote: 587 POAPs minted.


Honestly I do not feel comfortable with the idea to incentivise people just because they hit the “vote” button on a snapshot. Let’s face it - many of them will vote just to get the POAP and the possible sushi reward, they won’t even make the slightest effort to inform themselves what they are voting for…and I do not see it as something positive. If there is a need of incentivising, then let’s incentivise the activity on the proposals and discussions. Sharing thoughts and ideas is much more important than just clicking on “vote”. I also don’t think that the “Do that and you will be rewarded” is the right approach, “You have done that, so that’s why will be rewarded” sounds much better to me. Sometimes ago I shared with Tangle and some of the samurais an idea which could probably work: There is an automated system rewarding “Badges” at the Even it is not the perfect one, it gives quite good info about how active on the proposals a user is and how his thoughts are accepted by the community. If we are going to incentives, so let base it on the types and numbers of badges earned by each user… this also will mean that we will reward not only the future involvements, but also the past ones - which is most fair.

1 Like

The idea, albeit naïve, that a growing portion of those mindless clickers will start reading up on what they are actually voting on. And eventually become involved into the governance.

We could go alternative rout and sanction every holder that doesn’t vote.

In any case, no community involvement plays into the hands of the actors seeking to usurp the control of the protocol. Maybe that’s what community deserves.

Probably, but don’t you think that incentivising the reading and the activity in discussions will have better effect? I am sure that at least 90% of those who read will vote… and they will be informed on what they are voting

Totally agree with this, and I believe POAP was looking to work with Discourse on ways to implement POAPs with the badges. I am very much in support of that, and will follow up on any progress. The compounding or crossover of POAPs like Community Engagement, I Voted, and Discourse, could definitely help create a more engaged audience and community.


I appreciate both responses and had similar concerns. There are definitely ways to improve community engagement without monetary incentive to vote and I will put my proposal on pause for now.

Thank you Tangle and others for opening the discussion. Throwing in a couple points below.


The quorum mechanism is not well understood – including by me! I thought the 5m threshold was for total turnout, not votes in favour. I have seen some confusion about this on Discord in the past.

I’d advocate for aligning quorum with voter turnout, because:

  • It’s easier to meet. Given present voting levels, asking for 5m votes in favour requires near unanimity.
  • If community governance is going to be increased then it’s not hard to imagine proposals that are contentious/divisive but that still need to be resolved.
  • A proposal might have more than two options, splitting the vote.

Whatever the mechanism, though, it would be good to do more to communicate the rules and let voters know where they stand. If Snapshot updated their UI to include a ‘votes needed to pass’ meter then that would be ideal. In the meantime, perhaps it could be drilled in more thoroughly by Sushi in general communications. In doing so, it might also be worth considering ditching the word ‘quorum’ in favour of a plain language explanation.

Voter turnout

I haven’t managed to get it all in order to post in detail, but I spent some time recently going through Sushi’s Snapshot data (up to 1 December 2021, filtered to votes with > 200,000 powah). A couple of points from that which might be relevant now:

  • I think everyone knows it, but the current system is very reliant on a few big voters. However you feel about their level of influence, it makes Sushi governance vulnerable to paralysis if they leave. To 1 December, there have been 25 proposals with turnout > 5m. If you remove the largest voter from each of these proposals, 40% of them don’t pass; if the largest two wallets are taken away, 68% of them don’t pass. The most recent vote on Community-Enabled Analytics would have failed if any of the three largest wallets hadn’t voted. It feels we are in a particularly fragile position at the moment.
  • If quorum is based on total turnout (see above), then large holders acting in bad faith can abstain rather than cast a minority vote to prevent a proposal from passing.
  • Getting more small holders engaged with governance seems like a general good, but won’t move the powah needle very much unless it’s a really big influx. Trimming out the top and bottom 5%, average voter powah is around 186.
  • I expect it’s already being done, but identifying and where possible cultivating relationships with large holders seems like the most effective way of increasing turnout. Presumably some of the big wallets are anonymous, but others are known. If large holders could be encouraged to vote early this might reduce their influence, on balance, by decreasing their options to vote (or not vote) strategically.
  • There’s some evidence that batching votes together helps turnout, or at least doesn’t hurt it: multiple votes on the same day tended to have higher engagement and retain voters across proposals. On 13 August 2021 there were 5 snapshots for votes on multichain expansion, Kanpai, oSushi, Shoyu, and the Samurai. 1185 unique voters participated across the 5 proposals, with around 80% voting on all 5.

Hope some of that is helpful. I’ll post some more notes if can dig in a bit deeper. Voting yes on the sushipowah expansion, which seems like a good step.


There were experiments like quadratic voting to revalue the weight of smaller holders. But it would have to be balanced against big holders splitting their share to spawn new wallets that would vote as one.

Thank you for sharing your findings. Data-mined observations are much appreciated.

This is the most important thing that needs to be implemented immediately

Just to add re the point above on batching proposals – here’s number of votes per hour for some of the recent proposals. The five in blue are from 13 August 2021, and the three in pink from 30 March 2021. Can see that those proposals open strongly – perhaps by creating a bit of hype/excitement around the mega vote & a sense that things are moving quickly – whereas the recent Tokemak and Community Analytics ones have been flatter.

Looking at these I also wonder if 7 day voting is necessary from the perspective of turnout: in most cases voting is happening in the first couple of days with a little kick at the end. Going back to the earliest proposals they were up for 1 day only (!), and gradually the snapshot durations have been getting longer.

1 Like

Not to mention truly identifying invested community members.