Proposal: gas efficient xSushi v2

Summary

To mitigate the flaws of the initial SushiBar contract, as described by the Nansen Report, we propose an improved xSushi Contract implementation.
xSushi v2 locks Sushi for a predefined time period, issuing xSushi v2.
We, Keno, and Johann ask for funding to deliver the implementation.

Who are we?

Johann

  • 2020 founder of Strudel.finance
  • 2019 launch of Plasma Chain @ LeapDao.org
  • smart contract developer in the Ethereum ecosystem since 2015

Keno

  • founder of Strudel.finance
  • smart contract and frontend developer

Abstract

xSushi v2 is created by locking Sushi for a period of time (configurable, e.g. 1 month to 2 years). Locks that have a longer duration mint proportionally more xSushi per locked Sushi, approaching a relationship of e.g. 24-to-1 at max locking duration.

The curve to describe this relationship in detail can be chosen freely at development time, we have depicted in the figure below three possible options.
Decisions on the parameters need to be found.

For the figure we used the following formulas:

Once the lock duration has expired, Sushi can be reclaimed by burning xSushi.

Motivation

The idea behind implementing an improved version of the SushiBar is to mitigate the initial flaws and create incentives to remove Sushi from circulation for a prolonged period of time.
The locked token may be used for Governance or vesting purposes.

Specification

Sushibar:

  • single lock per user (gas-efficient storage), additional locks lead to an averaged lock time and rewards equal to it
  • minimum lock duration of 1 month up to maximum lock duration of 24 months
  • claim function to receive rewards without exiting
  • accumulator for each user to allow exact rewards for each time frame
  • locks can be created from other contracts (for example farms paying out rewards in both Sushi and xSushi locked for a certain amount of time) or to allow vesting for team members

We will commit to delivering well tested (but not yet audited) solidity contracts closely matching the specs above. Slight changes may occur due to technical feasibility, but will be clearly communicated when encountered.

Upon acception of the proposal, the proposed contracts and appropriate unit tests will be delivered within two weeks.

We propose a success fee of 20k SUSHI upon release, with 5% reduction per day of delay.

For

The implementation of the improved xSushi will be provided by the Strudel team, letting the Sushi team focus on their existing tasks.

Against

Funds paid for the implementation of this proposals could be saved by Core developers developing it themselves.

Poll

xSushi v2 implemented with time locks
  • Yes, with preferential short time locks
  • Yes, with linear time locks
  • Yes, with preferential long time locks
  • No, please let the core team take over.

0 voters

3 Likes

I’m still very much in favor of a solution where your SUSHI starts working better the longer you leave it BUT it’s not locked. So you can withdraw it, but you lose the multiplier you’ve built up.

This may also allow rewarding of harvesting LP rewards directly into the SushiBar.

10 Likes

I agree Boring, the more i think about, the more i dislike locking. I don’t think sushi need lockups. We have a good working product that generate cashflow, with new revenue streams in the pipeline, combined with reduced emissions sushi should be able to be sustainable without forced lockups.
I also like your proposal of increased multiplier the longer you stake, as long as it is a small multiplier, for instance max 1,5-2x. I also think a 24 hour or similar grace period, where you do not gain xsushi rewards would be nice if easy to implement.
That would make the issue the Nansen report confirmed go away, and migate further flashloan “arbitrages”.

2 Likes

Fixed lockup periods aren’t gas friendly. The weighted lockup as suggested here will confuse people I think. You lock up 100 SUSHI for 1 month and 100 SUSHI for 1 year… but instead you’ll end up locking 200 SUSHI for 6.5 months…

I would actually propose that SUSHI starts at a multiplier of 0… when you put it in it doesn’t do anything… as you leave it, the multiplier grows (and works retrospective too)… so if you leave it 1 year (for example) and get the full power (1x) and you withdraw (or harvest), you’ll get 1 year worth of rewards at the full 1x multiplier.

So your full (1x) rewards are always being reserved for you. If you withdraw early, everyone else sees their SUSHI holdings increase a little.

This is technically very very simple (low gas) to implement I think.

This really rewards loyal holders… if sentiment goes negative for a while and many people withdraw early, those who continue to hodl get the benefits. As it should be.

2 Likes

Fixed lockup periods aren’t gas friendly.

can you elaborate on this? i think the lock can be done with 1 storage slot per address.

This is technically very very simple (low gas) to implement I think.

true, an open accumulator would work as well. this is mostly a political questions. probably less people would go into a hard lock, while it would benefit the token price more in a bear market than the open accumulator.

1 Like

If you lock up 100 SUSHI for one year and a day later you want to lock up 300 SUSHI for one month… where/how do you store that?

If you lock up 100 SUSHI for one year and a day later you want to lock up 300 SUSHI for one month… where/how do you store that?

as you described, average it out. if you don’t like the average, use a different account to do the second lock.

That’s what they propose above… but that would allow you to lock for 2 years, reap benefits, then borrow a large amount and lock for a short time, to get a short average and escape early. Also, it would require so much explaining as it will be confusing. Also, many don’t like hard locks, so I think participation may be low.

agree, i’m open to change this proposal to use an open accumulator, or writing a new one.

i’m still having trouble understanding this. wouldn’t the reward for the 2 year lock only vest a fraction of it’s total reward? specifically i imagine the implementation like UNI’s cumulative sum of prices, but instead accumulating duration * amount for each block.

If you lock 1000 SUSHI for 12 months… for 2 months you harvest at full rate.
Then you lock 1000000 SUSHI for 1 day. This will lock 10001000 SUSHI for 356 * 1000 + 1 * 1000000 / 10001000 = approx 1.35 days.
After 1.35 days you withdraw all funds… yay!

ok, let me try to understand:

assumption

  • linear xSushi/Sushi lock relationship (red line above)
  • arithmetic mean to calculate remaining duration
  • reward APY 100%

early resolver case (the case you describe):

1,000 Sushi locked for 1 year = 1,000 xSushi
lock reward after 1 year: 1000 Sushi
after 2 months 166 Sushi received

1,000,000 Sushi locked for 1.35 day = 3698 xSushi
after 1.35 day ~7 Sushi rewards received

=> ~173 Sushi rewards total

honest case:

1,000 Sushi locked for 60 days = 226 xSushi
after 60 days ~38 Sushi rewards received

1,001,000 Sushi locked for 1.35 days = 3702 xSushi
after 1.35 days ~7 Sushi rewards received

=> ~45 Sushi rewards total

@BoringCrypto are you saying that the 128 extra Sushis earned in the early resolver case exceed the cost of borrowing by far, and hence make the contract vulnerable to exploitation?

isn’t the crux in this assumption the arithmetic mean?

I’m saying that the math doesn’t work… there will be ways to get more for less… you could of course make it impossible to shorten the lockup time, only make it longer or keep it the same.

The correct calculation of the locktime for this example would be:

1 Like

the open accumulator is using backtracking, the lock is using look-ahead. both become complex when trying to track multiple deposits in one storage slot. The quadratic formula by @Clearwood would solve both.

1 Like

Where does the 2739.72 come from?

1 Like

It is the amount of xSushi to be received for locking 1000000 Sushi for one day (1000000/365). Thank you for the question, I missed clarifying it. The 1000 stems from the 1 to 1 relationship of locking 1000 Sushi for a year.
I expanded the calculation above.

1 Like

I 100% agree with Boring here! Having a multiplier that increases as you hold, would act imo as a far better psychological lock.

1 Like

xSushi v2 with Open Accumulator

thanks to @BoringCrypto for throwing out this idea and his time to answer questions about it.

Summary

nansen.ai’s research has revealed vulnerabilities in the xSushi implementation. This proposal describes an implementation addressing SIMP #1. It is a more open alternative to the proposal above, which forces users to lock SUSHI for a pre-commited period of time.

Abstract

The open accumulator is a system where deposited SUSHI slowly grows in earning power (every block) up to full potential in x month or years. This is not just your earning power, but also your voting power. So those who keep their SUSHI locked up get the most rewards and the most voting power. But everyone has the freedom to withdraw anytime.

Motivation

an improved version of the SushiBar serves to:

  • mitigate the initial flaws described in nansen.ai’s research.
  • incentives to continue staking Sushi instead of dumping during price downturns.
  • encourages SPs to lock their SUSHI into the SushiBar, receiving a boost.

Specification

For e.g. a maximum lock time of 24 months the reward and voting power would build up as shown in the figure below. For all users, rewards are distributed as if everything had full voting power and differences are redistributed if users leave earlier. Every block the voting power increases and further rewards may be accessed by the user.

Let’s look at two cases, user A that leaves after 12 months, and user B that leaves after 24 months.

In the case of user A, they get 50% of the rewards distributed over those 12 months. They can either withdraw those rewards in between or at the end of the period.

User B receives 100% of the rewards distributed over the period of 24 months after leaving the SushiBar.

Sushibar:

  • single lock per user (gas-efficient storage), additional locks lead to an averaged lock time as described here and rewards equal to it
  • minimum lock duration of 1 month up to maximum lock duration of 24 months
  • claim function to receive rewards without exiting
  • locks can be created from by contracts (non-EoA)
  • can NOT be used for vesting, as withdrawal possible any time
    • ToDo: make separate feature (will need an additional week)

harvesting LPs into xSushi

As xSUSHI creation is not limited to EOAs, an option can be added in the Sushi-Chef contract to directly stake harvested rewards into xSUSHI.

We will commit to delivering well tested (but not yet audited) solidity contracts closely matching the specs above. Slight changes may occur due to technical feasibility, but will be clearly communicated when encountered.

Upon acception of the proposal, the proposed contracts and appropriate unit tests will be delivered within three weeks.

We propose the success fee of (1,250 DAI + 6,250 Sushi) per Person per week, equaling a 1/48 of an example rate.

For

The implementation of the improved xSushi will be provided by @Keno & @johba, letting the Sushi team focus on their existing tasks.

Against

Funds paid for the implementation of these proposals could be saved by Core developers developing it themselves.

Poll

i want
  • :doughnut: xSushi v2 with Open Accumulator
  • :takeout_box: xSushi v2 with Pre-commitment Lock
  • :coconut: none of the above, more research needed

0 voters

1 Like

I agree with BoringCrypto too

This pretty much covers it I think: https://github.com/sushiswap/sushiswap/blob/master/contracts/SushiBarV2.sol :stuck_out_tongue: