Sushi DAO Restructure Proposal

If there is one thing Dean Eigenmann can build its scalable systems and it looks like him and Alex have done an excellent job. Sushi is in dire need of restructuring and this one looks to be better at handling its current size and scope, especially with the various prongs Sushi is constantly pushing, definitely has my support and vote. I also think a council would have been able to stop some current community-dev animosity which has only been able to grow because of the lack of community involvement in the current structure!


To get an idea of community feelings with a simple temperature check

  • Ye
  • Ne

0 voters

1 Like

Hello everyone !

First of all, thank you Arca, Dialectic, Samurais and others members who worked on this proposal.
We, the team and the community, really need this and I can say I’m happy that you still believe on us.

I agree with everything wrote, but still have some question, because we have to admit our weakness.

Which type of entity ? Which country ? Who will own this entity ? Does this entity will own the domain, Google account, Twitter - Telegram account , Amazon account etc … ? Who , at the end, is able to sign a contract ? Do we ( team ) need a no-disclosure agreement with this entity?

I have to say, I would love to see a sushiPRO team. I was been hired especially for this.
My vision was and is simple : having the same UX than Binance / Bitmex / Deribit , with the same features. More users, more volume, more fees for LPs & xSushi holders.

A professional transparency report is needed , and at least a real accounting with evidence, no only a transaction on etherscan.

I believe Samurai team is a good start

Probably a pain point, since onboarding new contributors is the role of the entity , right ?

It seems to be a perfect plan for the future. When we need deeper changement, it can only come with the community agreement.


Amazing - this is a really great model and bridge between.

I’d suggest “Community” could be separated from within Marketing, and expanded into either it’s own field, or it’s own product offering.
Community Engagement, Internal Comms, Culture stand separate to pure Marketing imo and will need a lot of specific work done.


@Alex17 thanks for taking the time for this thorough write-up. I am glad to see Dialectic is joining in to support the cause.

Throughout the past few days we have seen a few different proposals, suggestions, and commentary; it is great to see a solution with more KPIs and detail.

Creating sub-entities and product specific teams for Sushi contributors will help better prioritize SushiSwap’s goals and adhere to timely product delivery and quality assurance.

Furthermore, this division creates synergies and aligns Sushi contributors based on their experience and skillset (see @GoldenNaim). I enjoyed your parallels to TradFi and normal businesses, such as below:

This helps readers better understand the scope and goal of this proposal.

We at Flipside are very excited to see this proposal brought forward and would support implementing it at its core and moving this to a vote.


That’s a lot of words to hide the disenfranchisement of the community.
“Yearly mandates”? Councils within councils. A legal entity within a law space of likely a US-based domain, which would put a huge attack surface from SEC et al.

Where is the mechanism of real-time feedback? Revocable mandates? Mechanism for immediate escalation of the issues the community may raise?

Where is the mechanism to make the community vote binding?
Core has already shown to ignore indefinitely delay the resolution of the issues community voted for.
We are no shareholders in legal plane and certainly won’t afford a legal battle with whichever corporate entity will usurp Sushiswap.

So far this is a pretty dress for “we really care for the community for the whole election day once a year, where we pretend to act on its behalf, and the community pretends to be the one delegating power”.


Hey Alex and Dean, this is a great proposal ! It gather multiple ideas that have been posted these last few days by the community and core.

I still have few questions/requests before putting a final vote on it:

  • Would like to add a code of conduct for contributors, trusted contributors and do’ers/council. I believe having clear rules on conflict of interest and greed could have partly avoided the current drama.
    Nori (core team) is working on a version derived from GitLab’s one.
  • As Naim said, the entity part needs more details.
  • In the structure chart it shows a Head of each department (COO, CTO, CMO…), what would be their power compared to other contributors and do’ers ? who will elect them ?
  • I think adding a chart or array resuming the power of each type of contributor (entry, contributor, trusted contributor, do’er) would be cool.
  • In this new structure, will the concept of core be replaced by trusted contributor ?

In this case we need to make sure that product teams work closely with do’ers and share all operational costs and data with them.
Not sure if I understand clearly how funds are handled, this quarterly grant is emitted for one product (1 grant per product) or for the whole suit of Sushi products (one big grant) ? OPS will only hold this funds or will it also has funds for other purposes or unexpected expenses ?



Thanks for posting this Arca, I know you have been working on this for a while, and appreciate you standing by in these times.

A few things I would like to touch on are accountability, product coverage, governance, and community.

Accountability is something that has not only lacked in Sushi, but even in our everyday society. both elected and non-elected officials have the power to create laws and structures that effect us all, and rarely feel the gravity of a poorly made decision like the average individual does. So dovetailing off of this theme, perhaps there is a way for us to provide some game theory towards ensuring that those who are in any type of hierarchal decision making positions have aligned incentives. By delivering and achieving projected targets, along with aligned behaviors that favor the protocol, there could be ways to reward these actions. Failing to do so on the other end, could have repercussions. We may find benefit in having some type of process in place to create disincentives, to deter bad behavior. Being in a hierarchal position requires great responsibility, and should be looked at as somewhat of a steward of the protocol. KPI Options have been tossed around a little bit, so could be something to look at.

In regards to product coverage, I am not sure if it is just the way the diagram has been designed, but in regards to Project Manager, I feel like one individual is not enough to cover all of the products at one time. I feel we could be more effective, productive, and provide better coverage with additional roles here.

As for governance, I think we can set up a proper cadence around how this should work. We can provide a clear outline for what to expect from inception of a proposal idea, all the way to execution after Snapshot. I will add the governance ideas into a post or another proposal soon.

On the final point of community, I will piggyback off Kakumei and echo that Community could likely be a whole section. The community needs to have a strong voice through this process and into the future of the protocol. Without having the right voice it may not inspire the community to engage, and continue to flourish. Voter share is one thing, but guiding decisions to help get there is another.

Thanks again for your continued support Arca, and I look forward to what this discussion evolves in to.


IMO controversy can ultimately boil down to an unclear/subjective project/DAO structure, and the better defined roles and better defined checks and balances for who and what those roles are is the best outcome of all of this.

With that, I want to callout specifically the importance of the Council/Do-ers and some additional structure that I think is missing:

The intention of this restructure should not be to formalize additional governance burden, but rather to create a system of checks and balances that gives contributors/core team members autonomy and agency to act in good fatih while monitoring that activity and assessing through the Council/Do’ers

In my experience, an ivory tower type role responsible for playing mediator and ruler above both community and team is an effective way to structure a DAO looking to protect community ownership while avoiding unecessary inefficiencies.

In order for the Council/Do’er organization to servce it’s proper purpose, every aspect of it needs to be explicitly formalized:

In terms of council formation:

  • How do you get appointed to Council?
  • Who elects you?
  • When do you get appointed?
  • How is the council monitored and upgraded?
    • Reviews of existing members
    • Protocol for expanding or contracting membership
    • Structure in place for underperforming/unhappy/looking to exit council members

In terms of what the council is responsible for:

  • What and how much control over the sushi team does the council have?
  • How do they operate to check the team? Are they proactive or reactive?
    • Using BitDAO allocation as an example: Should a council hold up token allocation and determine proper procedure, or should the council monitor those engagements and flag bad behavior as they come across it?
  • How do they peform actions for or against the team?
  • What are the procedures for on-boarding/off-boarding and other

IMO there’s still a lot of gray area - and speaking of that, who is responsible for gray area?

I would like to see an explicit structure of:

  • Recurring (perhaps quarterly) appointments/replacements/affirmations of Council members
  • The community’s primary governance responsibility is appointing, replacing, affirming these council members
  • The Council’s purpose is to manage the Sushi core team
  • Sushi core team has agency and autonomy outside of the scope of council control

In actuality, there’s plenty of DAO evidence to suggest that appointments to privileged positions that make ownership and governance decisions for a complex organization like Sushi is better than continuing to expand governance voting, which has its own set of problems (whale dominated, voter apathy, unfair tracking of voting weight, etc.)


Thanks for doing this. Need to read this tomorrow with fresh eyes, but it looks like a solid path from the skimming.


thanks for doing this, much clearer


I would like to see the team members have some sort of financial incentives aligned with Sushi price, like stock options that vest.

This could be a separate issue (I.e. team compensation) and/or one that is dealt within the structure at the appropriate time, but thought I would put it out there.



Great proposal. You have my votes.

Just want clarity on what exactly you mean by creating an entity (assuming C Corp in U.S.)

For those wanting to avoid the radar of the SEC by not creating a legal entity, that is not the right thinking. We are going to run into regulation very soon and we need to start legitimizing our processes and gearing up for compliance that other exchange businesses follow – Anti-Money Laundering (AML) and Know Your Customer (KYC). Also as someone on Core Team said, we need company bank accounts to pay vendors, etc.


The proposal to subsume Sushi into a legal entity is a trojan horse.

All that is required is a business services company which acts as an agent for the DAO to sign contracts to purchase services. The company raises invoices to the DAO, receives payment in crypto, pays tax on its income and deducts its expenses.

Governance can and should remain fully decentralized and on-chain.

If there is a reluctance to deal with the logistics of this the community should make a separate proposal to tender for this company being set up ‘as a service’.

I repeat: there is no need to subsume the DAO under a legal structure in a single jurisdiction. All that is needed is a business services company which receives a regular stipend from the DAO to purchase off chain services.


With the ops multisig proposal, what’s best practice with x of n signatures? Do you need a majority to move funds or a significant minority (ie 3/8 vs 5/8). Perhaps a timelock function should also be considered with a small-ish period (24h or so)

In addition, do you have any learnings from the ENS DAO conversion to share? Delegates seem very active and engaged, based on recent twitter posts I’ve seen (up to 70% of eligible tokens voting).


First of all thank you all for the proposal and commentary on how we should go about this. You guys are doing a great job.

I like this proposal from @Alex17 and Dean,

Here are my summarized constructive comments:

  • I feel it is important for us to have a head figure, like Maki was at one point. Someone leading the charge, inspiring the team, and keeping everyone engaged. The structure proposed is very good and organized but is missing that piece. There has to be that management-focused position that is constantly keeping a macro view of what’s going on and focusing on the bigger picture.

  • I also believe we should have a head of HR position in there that focuses an attracting talent and constantly hearing out our team and their needs. They will also serve the community by constantly sourcing talent from within the Sushi factory. **Our team should be focused on building and shipping products, they shouldn’t also have to be worrying about hiring top talent, HR related problems, drama etc. This role could act as a mediator (which clearly we will need). IMO this is a key position that will keep the workplace nice and peaceful for all to thrive

  • I know compensation was brought up for after this proposal is approved, but I believe it is absolutely critical that all Sushi team members have a stake in sushi with a minimum threshold to ensure “skin in the game”. This applies to our chosen community council as well. Everyone. Of course this will also include compensating our team splendidly (as they deserve) TBD for after this proposal.

I really want to reiterate the importance of the points @Tangle brought up because I think they are all very important. As well as the others on keeping checks and balances for both core team and council.

Last but not least, everything else mentioned on the proposal seems very good to me, you guys did a great job. Lets keep it coming!


Overall its great to see the additional off-chain structure forming to help organize Sushi development.

The main missing piece is more granular on-chain structure to maintain incentive alignment and transparency for the community. I propose the addition of a minimal DAO and have the operational multisig be transitioned to an “Optimistic Approval” style multisig which has a Timelock attached. During the timelock window, the DAO can veto proposals. This enforces transparency and adds an additional safeguard for the community.

We have some code we use at Fei that can be easily ported over to Sushi for this.

I also think the Core team should receive generous Sushi comp packages with long-dated vesting and clawbacks if they do not perform.


We need closure from the team on the facts before we decide on pay and who to hire. If the details are true this will change how we decide on pay and hiring.

We need confirmation on the bitdao deal, who got the money from joe’s dona sale and why did he do this while working for sushi, what was the process on removing maki and who agreed on it.

We need confidence in the team or we will fail again. If any team member acted bad they need to be removed and a new person hired for the role.

The BitDAO Deal

Reference: there are 5 transactions of $500k us dollars worth of bitdao given to 5 wallets Ethereum Transaction Hash (Txhash) Details | Etherscan

Why was payment given to sushi members?

Who received these payments and what did they do with them?

Why was payment given directly to 5 members and not the whole team?

Why was this not diclosed?

**If any team member is using Sushi to make money without disclosing to the community and their team they should be fired for conflict of interest and bad fiduciary duty. No company allows this. We do not too. No punishment means they will do it again. **

I do not believe we can not replace any position in Sushi.

Did any team member do any other secret deals for payment using the Sushi brand?

The DONA Token Sale
Who conducted this token sale?

Who took the money from this sale?

Why did it use the Sushi name?

Firing 0xMaki
What was the process for firing 0xmaki?

Who proposed it?

Who voted on it?

Why was this not proposed to the community?

Internal Relationships

How are teams within sushi managed?

Are there any cliques or relationships that need to be disclosed for conflict of interest?


The only issue I have is breaking up teams by product. Sometimes when you do this the product becomes fragmented and there’s a lack of a cohesive user experience across products like we have now. I prefer teams by discipline


I might suggest a staff engineer role that works to establish and maintain standards & code quality and coordinate efforts across the projects, depending on the workload and involvement of the head of engineering.

1 Like

A good article on this by rekt - Rekt - Sushiswap Scandal