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?
- 2020 founder of Strudel.finance
- 2019 launch of Plasma Chain @ LeapDao.org
- smart contract developer in the Ethereum ecosystem since 2015
- founder of Strudel.finance
- smart contract and frontend developer
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.
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.
- 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.
The implementation of the improved xSushi will be provided by the Strudel team, letting the Sushi team focus on their existing tasks.
Funds paid for the implementation of this proposals could be saved by Core developers developing it themselves.
- 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.