- 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.
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.
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.
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 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 variable would require deploying a new smart contract,” reads an IntoTheBlock research document shared with CoinDesk.
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 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 a SushiTokenV2 Bianciotto said.
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.”
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.
0 Comments