The Takeaway:
- The SushiSwap community has voted on policy changes to the protocol to reduce the token reward schedule, introduce a lock-up period for newly minted Sushi, and introduce fee staking. But these changes canât be made without first migrating to new smart contracts, a research firm told CoinDesk.
- The current MasterChef contract doesnât permit changes to the SushiToken contract, which in turn dictates other protocol functions for minting SUSHI tokens and for paying fee-staking rewards to SushiSwap holders.
- Each smart contract would have to be manually migrated to make the changes, the research firm claims, though the SushiSwap team is looking for workarounds that donât require as much heavy lifting.
The SushiSwap smart contract migration is complete but thereâs a problem: Another migration may be needed if the team wants to implement changes to the protocol the SushiSwap community voted for.
Limitations in SushiSwapâs code make the proposed changes impossible without serious alterations to SushiSwapâs code, namely another migration, blockchain research firm IntoTheBlock told CoinDesk.Â
Related: Market Wrap: Bitcoin Stuck at $10.3K; Uniswap Value Locked Gyrates
The SushiSwap community just voted to decrease the Sushi token reward â a so-called liquidity provider (LP) token which is rewarded to sushi users who stake tokens in SushiSwapâs liquidity pools â from 100 SUSHI per block to 50, with successive halvings every two years. In addition, this change would include a âvestingâ mechanism whereby two thirds of all newly minted SUSHI are locked for one year.
These vested tokens would earn transaction fees but could not be moved or used in voting until the year-long timelock expires. The vesting proposal is particularly germane to this project after its progenitor, Chef Nomi, sold off $13 million worth SUSHI tokens for ether last weekend. Chef Nomi recently forfeited this fortune, though, announcing on Twitter that he sent the 37,400 ether he garnered from trading in his SUSHI tokens to the SushiSwap treasury.
Read more: âI F**ked Upâ: SushiSwap Creator Chef Nomi Returns $14M Dev Fund
Sushi unrolled
These proposals won a landslide majority vote among the community, but IntoTheBlock told CoinDesk SushiSwapâs current smart contracts arenât flexible enough to bend the rules of the protocol.
Related: âNo Other Option but More Collateralâ: The Short- (and Long-) Term Fixes for Daiâs Broken Peg
The MasterChef contract, for instance, doesnât allow for the reward schedule to be altered because the emission rate is âhard coded.â
ââ¦[T]he current version of the MasterChef smart contract has hard coded the number of SUSHI tokens per block that can be awarded. This has been done via the sushiPerBlock variable which is initialized at a value of 100 at the contract creation time and canât be modified after that. You can see the reference in line 96 of the MasterChef smart contract. In simpler terms, changing the value of the sushiPerBlock variable would require deploying a new smart contract,â reads an IntoTheBlock research document shared with CoinDesk.
Read more: SushiSwap Will Withdraw Up to $830M From Uniswap Today: Why It Matters for DeFi
Fortunately, there is actually a fix for this limitation that doesnât require another migration: Even if the reward is hard-capped, itâs possible to send extra rewards to a dead-end address that no one has access to (thus, to decrease rewards from 100 SUSHI to 50 SUSHI, every block reward would send 50 of the 100 SUSHI minted to this dead-end address).
âAlthough clever, this option is far from elegant and falls outside the original design of the SushiSwap protocol,â the report reads.
The great migration: What this would mean
More than inelegant, fixing the other limitations would require an overhaul of SushiSwapâs smart contracts entirely. The problem stems from a design choice wherein the MasterChef contract (which has control over the protocol) is not upgradeable and actually owns the SushiToken contract, so migrating to a new MasterChef contract (e.g., MasterChefV2) would also require deploying a new SushiToken contract (SushiTokenV2), according to IntoTheBlock developer Pablo Bianciotto.
âThe limitation arises from the fact that MasterChef is not upgradeable,â he told CoinDesk. âTo be upgradeable, the actual contract logic should be stored in another contract which is referenced by MasterChef. That would give you the flexibility to change minting/rewards distribution logic by replacing this secondary contract for a new one and updating MasterChef reference.
âIn addition to that, SushiToken is owned by MasterChef, so creating a new MasterChef V2 contract with a new reward distribution logic and upgradeable features would require migrating the SushiToken contract, too.âÂ
To implement vesting, for example, would require a MasterChefV2 and a SushiTokenV2 Bianciotto said.
Read more:Â Fishy Business: What Happened to $1.2B DeFi Protocol SushiSwap Over the Weekend
The codeâs limitation would also interfere with implementing the fee payout proposal because thereâs no way to transfer the vested tokens from the MasterChef contract into another contract for fee staking.
âThis part is even harder to do,â Bianciotto said. âTo earn fee payments you have to stake SUSHI into the SushiBar contract, but if your SUSHI rewarded for staking is vested and sitting in MasterChef, you wouldnât be able to transfer it from MasterChef to SushiBar to earn fee payments.â He added that a SushiBarV2 would need to be spun up to accommodate this change, as well as a new SUSHI token minting contract (SushiMakerV2).
A cascade effect
In effect, the MasterChef contractâs non-upgradeable nature creates a cascading effect wherein every smart contract under its control also requires an upgrade to make the proposed changes to the protocol. The only solution, then, involves migrating each smart contract to a completely new version.
Seeing as each contract would need to be redeployed, this migration process would be more labor intensive than the previous one. Fully migrating each smart contract would involved taking a snapshot of all userâs balances and airdropping new tokens after the new contracts are deployed, as well as migrating individual user data from all of SushiSwapâs liquidity pools; users would also have to unstake all SUSHI tokens in the SushiBar and in SUSHI/ETH staking pools prior to the snapshot.
Biaciotto said that while the snapshot and airdrop may seem simple for user addresses, âsmart contracts that rely on SushiToken could stop working unless they are upgraded to use the new SushiTokenV2.â
He also noted there âare no time constraintsâ for these changes. He recommended a transparent and methodical migration that also âclears the way to seamlessly adding/changing protocol features in the futureâ to avoid having to implement further changes through another migration.
Community response
CoinDesk reached out to SushiSwapâs newly elected leadership (those members who hold one of nine multisignature keys to dictate protocol development) to ask if they are planning another migration.
âNo migration in the short term,â responded 0xMaki, the lead developer of SushiSwap, who has been with the project from the start. 0xMaki continued that they wish to implement the vesting and fee-staking proposals but that âit will require more thinkingâ to pull off.Â
Bianciotto, though, insisted the âthe only way forward [to implement these proposals] seems to be doing a migration.â
Read more:Â SushiSwap Migration Ushers in Era of âProtocol Politiciansâ
Another team member insisted that such a migration would be âsignificantly less complicatedâ and that there is âno concern whatsoever of any problems on the horizon.â Bianciotto reaffirmed that since âSUSHI is owned by MasterChef,â that âany kind of migration is non-trivial.â
To corroborate IntoTheBlockâs research, CoinDesk reached out to Zokyo Labs, a blockchain security and development company with a DeFi studio. A Zokyo representative confirmed IntoTheBlockâs findings.  Â
Related Stories