Sushi

Sushi Improvement or Modification to the Protocol SIMP Roadmap and Discussions #3

Sushi Vesting : Almost three months ago, we’ve agreed[1] 13 to vest ⅔ of newly minted Sushi for 6 months. There was no clear implementation of the vesting and its release, and it ended up being more of a workaround controlled by the multi-sig.

We’re slowly coming closer to the 6-month mark, which means that we start figuring out the distribution and its details.

Option #1: Airdrop the vested Sushi at the 6-month mark and get rid of the vesting. The transaction costs would be subtracted from the total airdrop amount, spreading the costs evenly between the receivers. The total number of vested Sushi at the 6-month mark should be ~47,040,732.

Option #1.1: Airdrop the vested Sushi monthly beginning at the 6-month mark (end of March) and get rid of the vesting. This would increase transaction costs a bit but at the same time would decrease the sudden inflation.

The Sushi would be airdropped beginning with the smallest balances, ending with the highest ones.

Option #2: Similar approach to Balancer’s claims - use a smart contract that would allow claiming every week. This would cost us almost nothing, but the receivers would have to bear much higher gas costs, possibly preventing smaller farmers from claiming their Sushi.

Option #1+2: Airdrop vested balances under 1000 Sushi, get rid of the vesting, use the smart contract approach for bigger balances.

All of these options are broken down in the forum post[2].

Team’s thoughts Option 1 is preferred, primarily because it’s the lowest risk. This is $300M+ worth of SUSHI, so a mistake could be very costly. The simpler the code for this, the better.

The goal of option 1.1 may be to spread out the inflation, but I’m not convinced we understand the impact of a single release (ripping off the band-aid) vs. a prolonged period of increased inflation. So I’d prefer the simpler solution.

If the whales are ok with us charging them the tx costs, that’s ok, but the dev fund paying these works for me too.

Overall I don’t feel very strongly about this, option 2 feels unfair towards smaller balances, but option 1+2 fixes that. As long as we get some serious audits done on the code, certainly with option 2 or 1.1.

(There was talk about ‘withholding’ some drops from farms, etc. I assume that idea has been abandoned (I hope so)? Not to be confused with helping farms drop directly to their users, which seems like a great idea.)

Option 1 would be preferred for simplicity. I believe the market will price this in quickly, and it’s less prone to human error.

Option 2 is a better solution and the Sushi not claimed can go back in the treasury after x amount of weeks. I think withholding Sushi to specific smart contracts is also important since their sole purpose is to sell. We should make sure community members are rewarded instead of mercenary liquidity. If MarketMakers are aware of this change in fundamentals well in advance there won’t be any impact on the price and everyone will be properly hedged out so the sudden release shouldn’t have much impact similar to what happened with the recent SOL unlock.

References https://snapshot.page/#/sushipowah/proposal/Qme8MYH2nWR3qcecxnVU5F824VJ2LjeKKr5mNaVdQ7ZfcF https://forum.sushiswapclassic.org/t/simp-3-vesting-and-the-future-of-sushiswap/1794

Proposed by LufyCZ