Sushi Meiji Restoration

Thanks, glad I could be of help. Feel free to tag me on the discord if you would like an expansion on any of the ideas, including more full bodied examples of how they’d work.

1 Like

Discussion is also available in the Sushi discord now under the Meiji section, with sections pertaining to a oSushi and the new DAO for those interested in participating on discord

1 Like

I’m just catching up on reading on the Meiji DAO proposal. This feels entirely necessary.

Does this extend our emissions? It would seem we need to make a plan for a way to continue emissions indefinitely? Am I wrong in that analysis? Sorry for rudimentary questions here, but am just a beginner when it comes to tokenomics.

I’m thinking of a way that we can do a SUSHI buyback in order to continue emissions. Are there reasons we don’t want emissions to continue indefinitely?

This may answer some of my above questions.

So ideally, I’ll have some of my SUSHI locked up in gauges, but to continue participating in governance voting, I’ll have to keep some of my SUSHI as xSushi?

I’ve now voted yes on this proposal. Though I freely admit I’m not well versed enough in tokenomics to fully comprehend all potential impacts.

Hoping others with greater depth of knowledge on this side of the business are asking the right questions. It seems necessary for moving forward.

I certainly can appreciate the need to eliminate token governance and realize Optimism was thoughtful in their efforts to avoid token governance.

Does this extend our emissions? It would seem we need to make a plan for a way to continue emissions indefinitely? Am I wrong in that analysis? Sorry for rudimentary questions here, but am just a beginner when it comes to tokenomics.

This proposal doesn’t extend emissions, and doesn’t require plans to extend emissions. I am not against it but I didn’t want to add more controversy to the proposal, and this way when oSushi is implemented we will have some months of data to inform any decision which would extend emissions before current emissions run out.

I’m thinking of a way that we can do a SUSHI buyback in order to continue emissions. Are there reasons we don’t want emissions to continue indefinitely?

I can’t think of a reason for emissions to continue indefinitely. Emissions would continue regardless though for the gauge in the sense that the xSushi fee they are recieving would be used to buy SUSHI, then the SUSH would be distributed by the gauges alongside any actual emissions.

So ideally, I’ll have some of my SUSHI locked up in gauges, but to continue participating in governance voting, I’ll have to keep some of my SUSHI as xSushi?

To continue participating in governance your SUSHI wouldn’t be xSushi, but rather it would be locked up the Meiji DAO. After this proposal xSushi essentially becomes a novelty SUSHI wrapper token.

Appreciate the feedback.

Yeah, this is definitely one of those sections where I’m going to have to rely on other members of the community to know better.

Probably just don’t fully understand all the mechanics here.

Are there any specific questions you can boil it down to? I am also available to chat anytime in the #meiji-dao section of the Sushi Discord should you have any questions there. Any issues you have in understanding the mechanics could provide insight into how to better explain this proposal to others as the vote comes up and discussion continues

1 Like

No, Control. I probably just need to keep reading on this stuff until I get a better understanding myself. Appreciate the willingness to discuss though. I mean, with what I do grasp, Meiji DAO feels like a great idea.

Probably the stuff I don’t understand is more rudimentary and I don’t want you to take the time to educate me.

2 Likes

Having read this proposal a few times, I have some suggestions and questions. I am currently a Head Chef candidate and am influenced heavily by the desire to optimize the current Sushi tokenomics. So please review my contributions below and provide your feedback. Thanks!

Shares:

Shares are also not granted immediately, and instead, Members must wait for double the voting period before they can vote on proposals. This is designed to prevent new voters from joining the DAO in an attempt to attack or vote through a specific proposal without prior service or participation.

Suggestion:
How about the following as a possible optimization vs. total double voting block? What about a weighted percentage of absolute voting power over n-time constraints with full vesting at double block maturity?

High Kitchen
Are there comprehensive High Kitchen standards conceptualized at this time? The High Kitchen section is somewhat vague and lacks clarity on topics such as election procedures for members, essential functions, and the qualifications of members considered.

Governance:

The operational goals for this DAO are to move development to a bounty-style system. So the ideal flow for the Meiji DAO becomes

  • Proposal for a new idea proposed by Member
  • Proposal passed by the DAO
  • DAO posts bounties to implement the idea
  • DAO votes to pass an implementation, paying the developer in the same proposal

Suggestion:
One item I’d like to see added to your proposal example is the addition of projected ROI for grants with some statistical or historical revenue generation model.

Voting Exhaustion:

Voting exhaustion is also another issue the Meiji DAO needs to solve (voting on everything pushes people away fast). The Meiji DAO will curb this through 2 configurable parameters, Maximum Weekly proposals, and Maximum Signaled Proposals. When a proposal is made by a Member, it then must be signaled by other members. At an interval to be determined during Parameter Finalization, the top signaled proposals are then brought to the voting block where voting on each one begins. This limits the number of proposals which can be spammed and provides on-chain proposal curation.

Suggestion:
Voter exhaustion is a real issue. However, most governance proposals do not require community voting for healthy protocol growth. I recommend reviewing Lido’s feature, Easy Track. Easy Track allows for non-controversial topics (those preordained in specific categories previously deemed acceptable by a governance vote) to get listed for a predetermined amount of time and automatically pass if they do not reach an objection threshold. Lido curbs abuse in its Easy Track solution with a post-voting cool-off period, where the community can pause proposals for review before codification, but only within a pre-allotted time.

Comments on oSushi:
IMO, instituting Gauges will be a net positive for Sushi tokenomics. As a side note: as the former CEO of an altcoin project that predates the advent of DeFi, I can vouch for the success of models that mirror oSushi, even without its corollary to Curve and its massive success. In our project, we instituted a similar approach called the Sharepool. Our token experienced a nearly 70% lock-up rate, with the majority choosing higher ROI at the 6-month term. The time locks allowed linear decay of early withdrawal from the committed lock-up time. We took it further and added a pro-rated withdrawal penalty with an additional fee. We instituted this to add a buffer margin and further prevent gamification of withdrawals due to adverse price action within highly volatile periods for the token. The flat withdrawal penalty is reasonable, but improvements are possible.

3 Likes

Hey Funk, I really like some of your amendments, specifically your gauges ideas. I seem to have reiterated some of your points based on my previous experience in my earlier pre-DeFi project. Did the team take up any of your amendments as consideration? I’d love to see your suggestions officially added and become part of the proposal that moves to a few statistical models to project outcomes.

1 Like

Thank @jaredgrey,

Yeah, I worked a little with @ControlCplusControlV who asked me to expand on the ideas and capture them with some diagrams. You can see some of the png files from that here and the thread of feedback/additional requests on the branch here
Feel free to hit me with any additional questions.

1 Like

Sounds great. I’m on the Git links you dropped right now. I am going to grab a new cafe and read!

1 Like

High Kitchen

I plan on fleshing out this section more, but the High Kitchen’s privileges right now are strictly defined to a council which can veto that can be abolished with a majority vote among the High Kitchen. It adds no other privileges at this time.

On grants I can’t give an ROI, but my idea is actually to allow core development efforts to be outsource via this method. So I guess cost could be compared of doing it in house, or rather extending in-house development to include the community.

As for Shares as I understand you are suggesting a gradual mechanism to give people their voting power up until a maturity point. While I do understand how this is better from a voter perpsective, I am hesitant to give any immediate voting power simply because of the risk flash-loans and mobs can pose. But I am open to discuss this in the Sushi discord if you feel differently.

I really like the suggestion of an easy track, and could be interesting to build something out like that for things such as “Pay the developers” and “Pay the bills,” so that there is reduced Ops messy-ness

As for oSushi I do like your throughts but right now I am almost completely reworking that section so all I can say there is stay tuned :slight_smile:

1 Like

Some thoughts…

  1. On Governance: the community should elect a Board (12 mo’s tenure), the Board oversee policy, hires/fires Senior management, and acts as the court of final appeal.

  2. On voting rights: all democracies work on the principle of 1 person 2 vote at a certain age (I prefer this to ‘weight’ of votes); and there is an argument to be made for requiring some loyalty (all countries require citizenship to vote; do we define Sushi-ness as holding xSushi for period n?)

  3. Quadratic voting should be trialed to improve engagement and enable the community to express their strength of feeling, rather than making a binary choice. Eg. Imagine that a vote generally costs $1 to put toward an issue, and you have $100 of voting credits. You want to cast your vote toward protecting endangered species. Casting one vote will cost you $1. However, casting two votes for the same issue will cost you $4, casting three votes for the same issue will cost you $9 and casting 10 votes for the same issue will cost you your entire $100 of credits. (Replace $ with xSushi…)

  4. Sushi MUST distinguish between Core Developers Building to the Roadmap, and non-core developments being grant-funded (if required to support the Roadmap) or arranged as partnerships (interesting, but non-core).

  5. Core Development is fully funded and tracked with KPIs. Grant funds are disbursed with targeted milestones, and ended if they are missed.

Thanks for your reply and additional insights. I’ll add my new thoughts in Discord.