Sushi DAO Restructure Proposal

By Alex Woodard(Arca) & Dean Eigenmann(Dialectic)

Since Maki transitioned to an advisor role, Sushi moved to more of a flat organizational structure. However, DAOs and Digital Asset projects are still very nascent and require structure to continue to grow. Over the past year, Sushi has seen tremendous success in community-driven DAO and protocol efforts, but as the protocol scales, it needs proper resourcing, processes, and principles for the various teams that are building under the Sushi DAO. This proposal outlines the details of what the new DAO structure of Sushi core will look like to provide more organizational structure that allows the team to ship best-in-class community-owned products while providing more oversight to the Sushi community. Additionally, this structural proposal will be used for future DAO’s, similar to Sushi Samurai’s, building on top of Sushi and Sushi’s treasury. TL;DR: The following updates to the framework of Sushi DAO are proposed in this post:

  • Establish a new formalized entity through a community mandate.
  • Establish a new operational multisig within this new entity.
  • Establish a new organizational structure for current and future DAO’s that allows Sushi to be properly resourced and continue to scale.
  • Establish further checks and balances between the various teams developing under Sushi and the Sushi community.
  • Establish further frameworks to install community-driven leadership and vision.

In just one year’s time, Sushi has grown from a single-product DEX to establishing itself as a key player in Defi with a community-driven DeFi suite of six complementary products. This growth has been phenomenal but has led to natural growing pains that need to be addressed. In order to scale, each product line must be properly resourced to fully execute the community vision. This proposal aims to adequately structure Sushi Ops DAO, and future DAOs developing Sushi, with a formalized entity, processes, structure, and community leadership in order to capture and capitalize on future growth.

The Current Team structure
Sushi Ops currently operates under a flat-org structure. Whereas this has the benefit of allowing core contributors to flow between product lines and work on what they are most interested in, it isn’t scalable and leaves some product lines under-resourced.

Proposed Entity, DAO/ Open-Source Contributor re-process with community mandate


The goal of this new DAO structure is to better align the core Sushi team with the community by providing governance oversight to the core contributors, and accountability, by creating a structure that allows Sushi to continue to scale its product offering for the years to come.

Structure and Entity Transition Plan:

  • Creation of a new Ops entity under the Sushi DAO to formalize processes and structure.
  • Creation of Product Teams, with an organizational level hierarchy for onboarding new contributors.
  • Creation of a new multi-sig with community mandate and more governance oversight.
  • Moving funds over to the new entity to fund operations through the year.
  • EOY - Leadership will put out a proposed budget 2022 roadmap, Q1 Roadmap & budget requesting funding from governance. Explained further in the leadership section below.

New Entity:

The Sushi dev studio will establish a legal entity that provides oversight and protection over the contributors. The entity will follow the legal frameworks of a DAO with governance oversight.

New Entity Structure:

The structure of the new entity will do two things. 1) The creation of product teams, and 2) The breakdown of contributors through the creation of an OSC (Open-Source Contributor) levels model.

OSC Level Separated by Different level of Trust

The DAO is streamlined into Entry → Contributor → Trusted Contributors → Do’ers, each with different trust levels. This model has a distinct ownership-based and decentralized way of participating in Sushi DAO while remaining structured in decision-making alongside the community. It is also a tested framework and one that has been used by Sushi’s partner.

The proposed OSC (Open-Source Contributor) Process:

Sushi Factory Level:

Sushi is DAO, and anyone can come into the Sushi Factory, which is a group of contributing members who receive a 1-month grant to work on their own RFPs (request for proposal). This will be achieved via the Sushi Gigs Platform which is being built by the internal team. These RFP’s will be approved by the community, with any further grants and product lines developed going through governance. This allows encouragement for ideas and talents to flow into the DAO, and further build the community on a larger scale.

Sushi Contributors

Sushi Contributors compose into product teams that cross-function with each other. They work closely with the Sushi Factory to ship products, work with projects, and bring products to market

Product Teams (written with feedback from Core Team):

Products Teams:

  • Trident
  • Kashi
  • Shoyu
  • MISO
  • Multichain

Every product team would consist of one or multiple contributors focused on product, designers, front-end, solidity, web3, marketing, & business development. Some of these contributors will be available to work on more than one product, but all products will have at least one of each. The distribution of the existing core team across these products will be determined by an internal poll that gauges their level of expertise and interest in each of the products.

Product: Define the vision and strategy for the product and product team. Full understanding of the scope of the product from initial wireframes to building out the product to designing go-to-market strategies, as well as overseeing business development and marketing efforts. They would work closely with leadership to develop quarterly/yearly roadmap, team budget, team KPI’s, present updates at company-wide meetings, and communicate with leadership and operational multisig on hiring and firing to make sure the product team is adequately staffed.

Designers: UX and UI designers are responsible for building the frontend interfaces, iterating user personas, and designing user tests. Other areas include supporting marketing with marketing assets.

Front-end: FE devs should be responsible for implementing mockups as well as a deep understanding of web3 and developing apps that interact with smart contracts.

Solidity: Solidity devs are in control of the core functionalities of the product and ensure infrastructural compatibility with the rest of the product.

Marketing: Marketing should include product marketing, content marketing, digital marketing, and work with other product teams to have consistent brand and marketing efforts across all business lines. The marketing team will cross-coordinate with others products.

BizDev: BD focuses on bringing the product to retail and institutions, as well as onboarding inbound leads.

Operational multisig/Trusted Contributors

To give oversight back to the community, operational multisig members should be known members of the core team to the community and selected through a vetted process.

While the current Sushi DAO system has been effective for day-to-day purposes, the team has heard questions as to whether it privileges a tech-only mindset. To resolve this tension, and expand the Sushi DAO, signers should be known members among the core team, who work in either 1. Technical 2. Operational or 3. Product capacities, as opposed to the current structure, which is a fully technical operational multisig team. The ops team should be diversified with interests from other departments who represent different skills and experiences. Operational members will be split into product teams outlined above based on their interests, skill set, and team needs.

The community understands what’s in Sushi’s best interest, as well as who is best to be accountable to execute that mission with the rest of the core team. Therefore, operational multisig should be selected by governance via polls on the forum, instead of the current process – internally without governance. Core members who are interested in and capable of being on the Ops multisig can submit their names, and the community can decide who should sit on the committee via forum votes.

Community Selected Council/Do’ers

Community Selected Council/Do’ers will be deeply involved in the community and differentiated into operations, product, and development. They will work together and are responsible for the following tasks:

  • Governance and community management - understand the community’s mission and execute that within the rest of the team.
  • Project oversight – Working alongside the community to develop a product roadmap, KPI’s and work with DAO contributors to fill any gaps when necessary.
  • Development of yearly/quarterly operations plan through governance and community engagement
  • Develop a quarterly and yearly grant approved via governance proposal and approved by the community, to then allocate resources effectively to each product line.
  • Develop Quarterly and Yearly updates for the community similar to tradfi 10Q/K’s.
  • Participate in Monthly AMA’s to update and hear from the Sushi community.
  • Work with the community and project managers on any onboarding and offboarding of core contributors to make sure each product team is adequately staffed.
    • Offboarding to be decided by Community Selected Council, Do’ers alongside the operational multisig members.
  • Point of contact for the community and contributors at Sushi and all other decentralized protocols.

To structure in accountability, the leadership team will be reviewed by governance. A vote to renew leadership will occur annually. If something happens that would require a faster timeline than the yearly review, governance can propose a vote. Additionally, if the core team decides that additional chefs for variance roles are needed, all new roles and people filling the roles will be voted upon by governance. A proposal to fill these leadership roles will be released immediately following a successful vote of this proposal. Additionally, we would like to work with the community on a Compensation Realignment Proposal for the core team following a successful vote of this proposal.


Alex and Dean, great writeup. Excited for community discussion.


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