SIMP #1 : Sushibar v2

I’m not a big fan of changing the Sushibar rewards to Dai at the protocol layer and would much prefer it too be a ‘opt in’ option built into the sushi bar.

  1. I think it makes the process more complex while also now relying on another protocol to function which adds more risk to the equation.
  2. I don’t think it would look good to long term Sushi investors/stakers as their thesis would be changed which then adds uncertainty to the future.

Definitely like the theory but think it should be built ‘ontop’ not ‘in’.


Since the actual implementation is practically ‘impossible’ in Solidity, would be good to get an idea of who is going to actually write this. As I keep saying, any protocol change ideas should get a technical feasibility check first because now it might get some people excited only to find that it’s not possible. Or worse (like with the vesting) it actually gets voted in leading to gas heavy bloated protocol that’s only useful for whales.


There’s a major problem on Curve, where you locked your CRV, the multiplier will drop once you claim your rewards as multiplier effect diluted by other stakers. It’s very annoying for stakers need to restake more CRV each time interacting with the contract.
If we implement no lock-up, and time based multiplier, it’s much more attractive. If you stake 6 months later, you got 1.25x boost LP tokens. You quit. Your rewards multiplier will reset to 1. It helps keep people stay. And since no vest, there’s less likely for whales to manipulate the market. Better protection for Sushi :sushi: stakers.
As rewarded LP tokens is fee generating, and half in stablecoin, it alleviates the incentive to cash out $Sushi :sushi:. And it at least cut half selling pressure, compare to pure stablecoin reward.

7 day lock up period for solving the flashloan and keep3r issues is no conflict to the no lock-up or no vest period I proposed.


I agree :+1: :+1: :+1: :+1: :+1:

1 Like

How about every deposit gets it’s own id - handle it similarly to liquidations in Bento?

Would be nice to have some sort of a token in exchange for vesting xSushi. This way we could have a bond market as a way of increasing capital efficiency.

Creating a yvault that targets APR in sushi could serve as a bidder for such bonds. E.g. it will buy 1y vested xSushi with a 20% discount (the rates and maturities could be configurable). Due to significant time constraints, we will alleviate short term arbitrage, make locking capital less risky, possibly create a new market that would generate more fees for the pool.

I do like BoringCrypto’s time weighted proposal more, though. If it is possible to have a separate time for each deposit on the same address - it’s a more egalitarian solution.

The biggest question is, who will lose if the new distribution system is passed, and if such losses become detrimental to the project?

I totally agree with you that storing every single deposit would be pretty gas inefficient and expensive.
While implementing a vested token for our project, we ran into the same difficulties.
We decided on using a curve to relate our network token to the vested token, taking the lockup duration into account. Vested tokens are minted at the time of the lockup, taking into account the full bonus.
We just deployed this relatively gas efficient token.
We are able to store the information in a single mapping of addresses to uint256, by encoding the endBlock of the lock, the total amount of locked tokens, and the total amount of tokens minted.
Lock times are averaged out if further tokens are locked. For our contract, we decided on providing a minimum and maximum lock duration and the user can decide completely individually for how long they want to lock.

Lock transfers are not implemented in our first version yet but would entail the lock duration to be affected similarly to locking more tokens in that the lock durations are averaged out.
In such a case, an exit would not be possible until the end of the lock duration, thereby achieving a removal of liquidity from the market.

Rewards will then be distributed among all holders of the vested token. If such a token concept or a similar one would make sense for xSushi, we would be thrilled to provide an implementation.


Yah, so each user can only have ONE lock end time, right? If I lock 1000 SUSHI for 1 month and 1000 SUSHI for 6 months, I’ll get my 2000 SUSHI back after 3.5 months?

So with a large enough amount of SUSHI I could quickly unlock my SUSHI very quickly?

Now that SUSHI is going up in value, it’s GREAT to get auto-compounding SUSHI as rewards… if it was DAI, I’d have to use gas each time to swap it to SUSHI and add to the SushiBar to get it to compound.


Created an account just to signal support for this proposal.

a) Sushi gauge weighting is an elegant evolution from current emission determination process.
b) Distributing rewards to xSushi holders is the natural sticky incentive for locking (beyond governance and gauge weighting).

The time-lock is imperative for filtering for commitment. 3, 6, 12, 24 mo seems appropriate.

All for it.


@BoringCrypto raised these important points but we’re ignoring him

  • gas costs could eat your profits, especially if you hold a small bag
  • sushinomics: if we switch to DAI small holders won’t be able to auto-compound
  • technical feasibility: can we do it?if yes, who’s going to do it?

Also, when people are selling their SUSHI they’re probably doing it on sushiswap.
That sell pressure is mitigated by fees paid to the protocol.
In my opinion, switching to DAI is not a good solution to our problem


As a protocol, we want LP set and forget. We want long term and stable liquidity. From my experience, there are 2 protocols that let me set and forget. They are previous Curve and Serum farming.
Now, on Curve, you can’t set and forget. You need to harvest, stake more to boost to maximum.
Serum is very special. Reward token, $SRM, is injected into the pool randomly directly. The LP token value increases eventually. No claims needed. No hassles. Gas fee is minimal. IL could be covered easily. All these factors encourage me set and forget.
That’s why I propose LP tokens as rewards.

1 Like

This will be resolved with my LP vaults!


In our implementation, we provided a minimum and maximum lock time, in our case 1 to 52 weeks. You are right that a user only has one lock time but the averaged bonus therefore would also be reflecting it. With a sufficiently large additional lockup, the average lock duration could be reduced considerably up to that minimum lock time, while the rewards would also be very close to that of the minimal lock time.
The question on how to handle compounds really depends on what user group is predominant, those that want to have their rewards auto compound or those that need to use the profits to cover expenses.

Just wanted to say that SIMP #1 will be the topic of discussion for this upcoming Sushi Forum podcast. It’ll be an open discord call for the community hosted by me and @overly_ambitious in the sushiswap discord voice channel. Set for 11:59 PM(EST, do your conversions) this Monday(today). We’ll be debating and discussing this proposal in detail, hopefully we’ll have @0xMaki on as well!


on an unrelated note i propose we abolish traditional time-zones and create a universal SushiSwap timezone to better coordinate. I’ll sync my watch


I don’t really get the ‘pay for expenses’ argument… if you can afford a large enough principle that your rewards are big enough to pay for expenses, you probably don’t need it. And if you actually do, just draw down a bit of SUSHI when you need it and sell it (no, this isn’t sell pressure, because it was previously bought by the SushiMaker). But more importantly, soon you’ll be able to use your xSUSHI as collateral to borrow against, so this whole issue goes away completely. I’m super happy with the auto-compounding xSUSHI system… we just need to add the growing power over time thing to encourage longer lock-ups.

Why build a messy high gas solution if we can have an elegant low gas solution.


I am neutral to both options, either leaving the rewards in SUSHI or changing them to DAI.
I am currently writing a proposal, detailing the specification, to provide the implementation. I checked the current SushiBar contract, at the moment rewards are not auto compounding, just paid out in Sushi.

Depends how you look at it… if you assume some will withdraw their proceeds, then it compounds. If it pays out in DAI and EVERYONE reinvests, then it doesn’t compound for anyone :wink:

Also consider this: if you prefer DAI because it’s somehow ‘better’ or more ‘real’ than SUSHI, you should probably not stake any SUSHI.