xSushi is the single sided staking, reward bearing token, issued by the Sushi Bar when a user stakes their Sushi Token(s). Users earn reward in Sushi Tokens, so a user leaves with more Sushi Tokens than they entered with. Most Sushi products earn fees for the xSushi holders. These fees are not immediately converted into the Sushi Token. Sushi Maker is responsible for converting these different tokens into the Sushi Tokens and send it to the Sushi Bar.
The above system works excellently in theory, but the older and the current implementation have some flaws, that can be improved with a new version.
Permissioned Harvest - The fees sent to the Sushi Maker gets converted to the Sushi Token, but selling it on Sushiswap and buying Sushi Tokens in return, which is then sent to the Sushi Bar. This process is called ‘harvesting’ and can only be done by whitelisted addresses. This process was earlier permissionless but suffered from a possible attack vector; where anyone can take away a huge quantity of rewards from the xSushi Holders. The current process solves that issue but brings in a huge overhead to the team for having to manually harvest it, causing delays for the xSushi holders to receive their rewards.
Prone to MEV - Even while we have permissioned harvest, the system is still prone to MEV attacks. Bots monitoring the mem pool can sandwich harvest and ‘steal’ a lot of Sushi rewards from the xSushi holders. There are solutions such as Flashbots, however, these can’t be enforced as this method depends on the executor of the harvest. Additionally, this solution can still get relayed to the public mem pool.
Instant Share / Amount Ratio Update - As the rewards get credited to the users instantly + amount and share ratios are automatically updated, it can create issues at the composability level of the token. A popular example is Cream; where yV tokens’ share was changed by gifting additional tokens - changing the ratio instantly, which led to a hack of $130 mln. Aave also had the same issue with xSushi, hence, Aave turned off xSushi as a collateral.
No Bridge or Insufficient Liquidity - All fees have to be bridged to Ethereum Mainnet for serving the fees to the Sushi Bar. Most bridges don’t have enough liquidity for Sushi to be briged. Additionally, Sushiswap doesn’t have enough liquidity to sell other tokens for the best price. For that we have to convert it to another token such as ETH and bridge it to Ethereum Mainnet, after briding we’ll sell it for the Sushi Token and then serve the Sushi to the Sushi Bar.
No Kanpai Support - The current implementation has no support for the Kanpai Proposal which got passed.
xxSushi in addition to Sushi Auction Maker solve the above problems, while also providing new features to the current model.
The xxSushi model introduces the usage of ERC4626 based modified vault. The xxSushi contract on Ethereum Mainnet and other networks would be different. The Ethereum Mainnet xxSushi would allow you to stake Sushi Tokens and it’ll give xxSushi in return. The xxSushi token will support minting and burning through cross chain messaging protocols like Layer Zero, Anyswap (Anycall), Socket.tech, e.t.c which allows the user to Teleport it to any chain without relying on bridge liquidity and paying fees (though we can choose to introduce fees). The xxSushi on other networks would not have this vault functionality, it will have the regular ERC20 functions along with the cross chain functionality. The cross chain messaging protocols will be whitelisted by the Sushi DAO, users are free to use any other cross chain messaging solution from the whitelisted list. This will also be a token standard (ERC20Teleport), that will be used in future sushi products and in other sushi products such as Miso. Ideally, it would be done via the Factory pattern, like GemFab
The xxSushi Vault (on Ethereum Mainnet) will have streaming harvest - meaning, that the harvested sushi would not be instantly updating the amount / share ratio - but instead, it would grow over time up to a certain time period. The harvest would be public and permissionless, and you can’t harvest if there’s already a harvest delay running. You have to wait until the harvest delay is done, only then can you harvest again. During this harvest delay the reward would be streamed or added to the balance every second. So, the higher the reward, the higher the reward rate will be. This would prevent any MEV attacks and would force users to stay till the harvest delay window ends to earn the rewards completely.
The vault would have a fee which would be the Kanpai percentage, the fees will only be charged on harvest.
The teleport feature would also enable usage of xxSushi Token across multiple chains. This is an important update for the Sushi Auction Maker which will be explained in the next section.
Sushi Auction Maker auctions the fees earned by Sushi products instead of swapping these on Sushiswap. Users can start an auction for a token, the auction would run for a minimum and maximum time. The token used to bid in this auction would be xxSushi. Other users can outbid each other within the min / max timeline. The bid gets locked in the contract, it automatically gets unlocked if there is a higher bid than the current. There can be only one auction at a time per token. After the time ends, the user can finalize the auction and receive the asset in return for xxSushi.
An example - Alice starts an auction for 10 ETH (~12.000 USD) by bidding 1000 xxSushi (~10.000 USD). The auction has a minTTL for 12 hours. So, if no one bids within 12 hours, the auction finalizes and Alice would receive 10 ETH and the contract would send xxSushi to a harvester contract. However, let’s say, Bob bids 1100 xxSushi (~11.000 USD), the xxSushi from Alice will be credited back to her and Bob’s xxSushi will now be locked. If no one bids for another 12 hours, the auction can be finalized, this process can repeat upto max 3 days, which is the maxTTL, and after 3 days, the last bidder wins the auction.
The minTTL allows the auction to finish quicker if there are no bids, the maxTTL prevents the DOS attack on the system.
This system allows Sushi to buy xxSushi in a decentralized manner without relying on manual intervention or oracles.
The system may, at times, give out less or even more amount of fees, so these would be averaged out in the long run - and game theoritically, it’s sound to push for the highest amount to win the bid.
The harvester contract would teleport the xxSushi back to mainnet and call the withdraw / redeem, which would convert xxSushi into Sushi Token and then donate it to the xxSushi Vault and call harvest - this would serve the fee to the xxSushi holders.
The aformentioned system for xxSushi and Sushi Auction Maker together solves the issue of serving Sushi Token to the Sushi Bar in a permissionless and efficient fashion. It also brings necessary updates that would make xxSushi token much more composable and enhance its usage in the ecosystem.