Proposal: gas efficient xSushi v2

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:

As you proved yesterday you can’t use the arithmetic mean to calculate the new time.
The relationship from Sushi to xSushi is linear if you take the bonus into account, so the time adds the second dimension :slight_smile:
In your implementation, each harvest also resets the time, so it would not be possible to harvest while staking which seems a bit problematic.

  1. If you added 100 SUSHI 3 months ago and now you add 200 SUSHI, what do we have after another month:

TWA: 300 SUSHI for 1 month + 1 month = rewards for 300 SUSHI * 2 months = 600 SUSHImonths

2 accounts: rewards for 100 SUSHI * 4 months + 200 SUSHI * 1 month = 600 SUSHImonths

Works like a charm, right?

  1. Ah, I see what you mean… I’ll fix the harvest function

Just edited the solution to add a handy pending function

1 Like

If you want it to work with a different token, it’s a small change, but keep in mind that while SUSHI is ERC20 compliant, other token may not be, so you may have to use safe transfer and transferFrom functions. I really hope we just stick with SUSHI, because after all, we are SushiSwap, not DAISwap :stuck_out_tongue: If we go with DAI, we are basically saying that DAI is more valuable than SUSHI… :confused:

2 Likes

We believe that adding an Accumulator is beneficial to calculate rewards appropriately. Instead of giving the user a share of rewards at the time of a claim we use a similar approach to the cumulative token price used for UNI and Sushi LP pairs. Thereby every influx and eflux of reward tokens is recorded so that we can give the user a precise share of the rewards.

Transfer of xSushi tokens

A transfer will imply the transfer of the locktime to a new user. The locktime of the recipient will be an averaged locktime of the sender and the recipient. It applies to both EOAs and Smart Contracts.
This will prove to be a UX challenge, as the locktime depends on the locktime of the sender. This challenge persists in both approaches.

Implications of the usage of the two xSUSHI proposals for secondary products such as vaults or trading.

The existing bonus period of a token comes invisible to secondary products and would therefore be difficult to factor in.

open approach

From an economic incentive this should mean that most xSushi traded or locked is relatively freshly minted as the one to one relationship between Sushi and xSushi means that a higher bonus lock time will be unable to be factored in through standard trading contracts.
Once the maturity of xSushi tokens inside a Vault or LP pool rise high enough there will be an arbitrage opportunity for others to swap freshly minted xSushi against the matured one, thus the reward of vaults would be minimal if non existant. We are unsure whether such an effect is desirable for the protocol. The average age of xSushi inside Vaults or LP pools should be approximating 0.

locked approach

With the locked xSushi the bonuses given to a higher lock time will implicate that the average age of xSushi inside LP pools or Vaults should be close to the maximum lock time. With the locked approach there is not a 1 to 1 relationship from Sushi to xSushi but instead a 1 to x relationship at maximum locktime, with x depending on the maximum lock time.

1 Like

what is the point of having another token (xSUSHI) if you go the open route? could implement a synthetix style staking contract which would also effectively remove sushi from the circulating supply (where as xSUSHI would not).

1 Like

mhmh could you explain that?
Isn’t SNX tied to sUSD?

just talking about the staking contract. a lot of projects have forked this for their own protocol (yam, cover, yfi, etc). you don’t get a token back, you just deposit in the contract and start accruing rewards. sushi could do something similar plus a boost for the longer it is staked. this ends up not requiring another token + everything staked in the contract is out of circulating supply.

When you stake SUSHI for xSUSHI you’re reducing (until you unstake) the circulating supply with the benefit that your xSUSHI position can be traded

Whenever you don’t get a token back, you are reducing the level of composability we all love and cherish about DeFi.
Regardless of going the open or locked approach, there should be an incentive to keep Sushi from circulation.
The hard question to answer is what approach keeps more Sushi out of circulation, whether that is the open approach where the barrier of entry is very low but the barrier of exit continually increases or the locked approach.

If going the open route, I don’t know if composability of xSUSHI really works. If xSUSHI is tradeable then it doesn’t have an effect on circulating supply. Also, the transfer of xSUSHI and timelock transfer adds another UX hurdle and complexity. I’m just trying to think of what added benefit having an xSUSHI token would have if you go the open route. xSUSHI made sense when it was accumulating sushi and increasing xSUSHI price, but in a case where rewards are distributed in DAI, then having the xSUSHI token may not be necessary.

Easiest imo would be

  1. stake sushi, receive nothing back. sushi is out of circ supply
  2. receive dai, with rewards multiplier growing the longer it is locked
  3. withdraw sushi, resets clock

Also, if you allow the transfer of xSUSHI to transfer the timelock then it’s not a huge opportunity cost for someone to dispose of xSUSHI because they could get a higher price for it vs SUSHI. However, if these are locked in the staking contract with no xSUSHI token then you cannot sell this timelock premium when you withdraw. You get some composability benefits of xSUSHI but with other tradeoffs.

1 Like