This proposal outlines clear, discrete, achievable and impactful objectives that do not require a Fortune 500 style restructuring or some sort of ‘bail in’ by a 3rd party.
Sushi is not a pick-and-choose, assemble it yourself a la carte menu of defi and degen products.
Sushi has a team of chefs that pick out quality projects, programs, incentives, etc, that make apeing into defi that much easier.
Sushi should be the default choice for people wanting to discover, trade, ape, and invest in DeFi.
No, not that Omakse, the actual Japanese term, Omakse
These are action-items/goals that this proposal seeks to implement within 90 days. It touches three main parts that are integral to the sushi community.
- Get SUSHI/xSUSHI listed as an asset on MakerDAO
- Better parametrize incentives with new options
- 24.14%SUSHI is currently staked, what can we do to improve this (promotions, airdrops, etc?)
- Explore possible implementation of veSushi, an xSushi LP deposit grants voting rights on incentives (this may be suboptimal, which is why i am suggesting to explore it vs. implement it)
Setup a formal intake page for existing pools to request consideration for incentives other than the current google form process.
Offer Onsen benefits to those pools who are willing to provide a matching incentive
Establish a collaborative program with Market Makers that offers them the ability to provide quotes to orders (i.e. RFQ system )
Improve search functionality on frontend to more easily present users with assets trading on Onsen (e.g. push notifications, a seperate tokenlist perhaps, etc)
Integrate improvements to the existing routing contracts (on chain)
Integrate improvements to the existing routing logic (frontend)
Establish a referral programme for order flow
Create a new BentoBox Strategist program: BentoVault
Yearn has recently decided to no longer offer strategists a percentage of net profits from their plays, instead it chooses a collective payment scheme for all strategists. This presents Sushi a unique opportunity to capture some of this potential talent and offer an incentive for producing for Sushi: a percentage of the estimated net profits can be paid upfront (if and only if it has been vetted and proven to a high degree of probability) as a bonus.
Sushi makes it easy for anyone to become a defi chef. There is no bigger meal than that of want().
- Make and market Bentobox like they are equivalent to Yearn Vaults
- Leverage potential incentives by other networks to boost new and existing strategies as well
- Start dogfooding Sushi rewards in bentovaults (why should other vaults farm and dump sushi?)
How is this different than inari you ask?
Inari presents the user with depositing an asset into Bentobox, whereas BentoVault presents the user with purchasing into the underlying Vault. This is a significant difference in UX for the end user: they don’t have to first purchase the token then deposit (this is 2 separate tx’s), they just have to buy (1 tx).
Improving the routing on both on-chain and off-chain is not difficult. What it takes though is community approval.
We have already developed improved routing contracts that will facilitate OpenMEV/Sushi Guard. This is actually a big change as previously this was all off-chain. What this means is there is now 90-95% of OpenMEV profits directly attributable on chain, where before it was a trust-based relationship. This is a big potential win for Sushi in that profits can be used in real time potentially for providing boosted incentives, rebates or for other purposes.
The important part of this is to be data driven, here is a github repo with some of the metrics and KPIs are being used + additional can use to improve the impact of incentives. Think gauges
Currently this is the intake form: Onsen Onboarding & Marketing Playbook - Google Docs
Onsen applications are examined based on existing liquidity. We can easily add an additional optional requirement of matching incentives for some % of total time that the asset is on offer at the bar.
There is already a preliminary portal that can be used for this see https://sushi-partner-portal.vercel.app/
Three main items:
- Implement price aggregation search for better pricing
- Improve frontend computation logic with improvements from
- Explore the usage of limit orders for a market maker RFQ system
The first two points are largely done on our end (we used this for testing some assumptions and to see what we should focus on for improving OpenMEV). We can implement this as a beta page for Sushi users to try out. Additionally new weights can be attached for assets that are in a Tokenmak reactor / Onsen / other promotional/incentive programs.
This third third point is more of an exploratory idea that I thought should be mentioned, this is an idea and not
Market Makers would be interested in participating in a new quoting system for Sushi pools. In fact I have already spoken to some and have gotten tentative agreements. These would be on Onsen pairings plus Miso launches. They would get a discounted trading fee across the venue in return they would have to commit to quoting some $DOLLAR value of quotes.
Best of all this system would largely be leveraging the limit order capabilities that have been launched.
These points are for the community to discuss and provide feedback/ideas.
Tokenmak reactors are one of the more exciting things that can be used to great effect, and yet it seems there is little attention paid to this game changing protocol.
This ties back to improving documentation and developer relations. When you start thinking about the compounding effects of Onsen + Tokenmak + etc, you start wondering why anyone thought Sushi was in “trouble”.
This is an often neglected part of work, but it’s absolutely necessary. We want to be the default choice for developers to launch new products or offer new services to our userbase.
Being the default choice is a powerful primitive. For example, ask any developer what they would use to be able to accept credit cards online. 9/10 would say Stripe.
Here is a preview of something I put together over the weekend:
Matthew is adopting this among other changes in the new Interface monorepo here GitHub - sushiswap/interface: Interface
This is a formal proposal that is open to community input and discussion. It is a draft version, so please excuse any irregularities or errors. I wanted to get this posted before the community call so that it could be discussed if the community thought it proper to.
Impower multisig to dully authorize these changes and implementation
Negative, do not implement any such changes as detailed