xxSushi (Cross xSushi)

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.

Issues with the Current System

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.

xxSushi Design

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

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 idea of Sushi Auction Maker was initially given by BoringCrypto and Matthew Lilley.

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.


Love this proposal and I think it’s much needed!

As someone that helped on the current xSushi buyback process I can’t agree more than current model is not efficient.

Only thing that scares me a bit is to rely on a cross chain messaging protocol which I think could add an important potential risk in case it gets compromised.


Who triggers the harvest? Does this mean that we wont have to wait for someone to serve the bar but it will be more constant? If so does this have gas implications?

That’s a good point. The system is being built in a way which is message bridge agnostic to mitigate against these risks. There will be no depedence on a single message bridge.


That’s the point, anybody. We’re cut out of the equation entirely. This was the original idea for xSUSHI & SushiMaker, but it had flaws, which forced us to more to permissioned harvests, and didn’t scale well across chains.

1 Like

Isnt the current method gas inefficient? Does this new method solve for that? Or are we going to have people madly harvesting for rewards when gas is at 900

Yeah it has been one of my points to wonder during the design, as @ImSoftware said, the cross chain messaging protocol would be whitelisted, only very trusted would be used. To start with we will roll out in phases, the first phase would be xxSushi, without any bridge and then we whitelist one. The next phase would be deploying the Auction Maker on one of the chains, and see how it performs and then expand that to other chains.

1 Like

There are a lot of parts in the current system as well, which specific part are you referring to? It is more gas efficient than current system in some parts, as it introduces more features, it is a bit more gas intensive for others.

Harvesting rewards depends entirely upon the users. Once a harvest happens, there will be a harvest delay window, you can’t harvest during that. Once, that gets over anyone can harvest again.

The idea is to remove the dependence from the team and make the harvest permissionless. So, yeah people might harvest when gas is 900 or they may wait for gas to come down to 30. It all depends upon them, but the fact that anyone can harvest, probably the one in most need for the profits to be served will take some initiative and harvest :slight_smile:

Love the idea of the auctions. Not a fan of changing xSUSHI. xSUSHI is the principle and these represent large investments for some people. Any extra moving part in this area puts the principle at extra risk of hacks, etc.

I would recommend to auto-auction all revenue (LP positions) on each network for the native currency (not SUSHI because new network may not have SUSHI) and bridge all this to mainnet. Converting this to SUSHI should be reasonably low slippage, or you could also auction this again on mainnet to get the best price and avoid MEV.

This allows for a low risk solution. Any bugs would only put (part of the) revenue at risk, NOT the principle. And it means revenue can be brought to mainnet from ANY new chain Sushi is deployed on. No need to wait for support by layer zero, etc.

Keep in mind that most of the quick bridging solutions (as opposed to the native bridging of the chains) are bypassing security for speed. It’s just a matter of time before these get rekt because the delay is in place for a REASON: security.

But love the idea of the Sushi Auction Maker. Good step towards decentralization as this can run completely permissionless.


The above solution also solves the issue that are a bottle neck for xSushi as outlined in the issues, such as MEV. One of the main issue is most of the new chains have terrible bridge support, even for their own native tokens. I thought about re-auction of fees at the mainnet, that’s an idea we keep at secondary option. This is basically a cross chain messaging approach that involves no bridging at all.

The reason for this new approach is, it would allow xxSushi to travel to other networks without any bridge support, making it one of the early assets do that. It makes the entire system automatic. Also, we are not waiting for support from any bridge, since we don’t need one.

In future, what I see is that we won’t have bridges, just tokens which can teleport from one chain to another via cross chain messaging.

Also, we can provide very seamless migration from xSushi to xxSushi, that would help large holders to migrate funds with no risk :slight_smile:

The security implications of relying on something like Stargate for nearly all of Sushi’s core value to me is worrying, especially as Cross Chain Protocols have been consistently the top protocols to be hacked. Sushi is also deployed to so many chains that the security risks of relying on the weakest of 20 chains for security (as I understand it with cross chain messaging). Perhaps first starting with Optimism and Arbitrum and using the shared DA between those an Mainnet for trustless bridging could be a solution for some chains to avoid potential dangers.

I do agree an ERC4626 wrapper for would be useful for xSushi to increase composability and like the idea of the Sushi auction Maker.


Yes absolutely, as I outlined in the post, it was just an example, the ERC20Teleport, will have option to support multiple. xxSushi doesn’t need to support cross chain messaging from start, it will be activated later. It will also be in phases, just as you described, I was earlier planning polygon, but your suggestion sounds much better to me.

Thank you!

1 Like

Hey Arth here from Socket.
Love the proposal. I’ll chime in about isolating cross chain risk for xxsushi.

Since only mainnet is where distribution of reward takes place, the mainnet xxSushi could maintain an account of total xxSushi that could be minted using cross chain messages and cap burn/mint to that amount. This way an attacker would not be able to mint unlimited amounts. The approach can further be expanded to cap L2/sidechain specific mint amounts but this would add some overhead to all cross chain transfers since main chain will have to be updated for every such transfer.


Yes, absolutely, that’s a great idea, we can definitely limit the scope to start with.

The current design actually supports this, as we won’t whitelist the adapters on L2s and side chains, the cross chain transfers would not be possible.

Only the ethereum mainnet adapter would be whitelisted, hence you can bridge to and from only via ethereum mainnet, and it would work as you suggested. I think this overhead is worth it, since it makes the Auction Maker completely automated and makes xxSushi, a token that can be bridged without liquidity, promoting more utility on other chains.

Once, people have enough trust, we can enable those on the L2s and Sidechain. We have total control on where it is bridged to and from.

1 Like

I dont love the idea that random people can harvest rewards when gas is super high. Can we add something that prevents unnecessary harvesting at high gas times?

It’s actually good for everyone if they do that, since the user harvesting pays the cost (gas) of it. So, if someone is harvesting at high gas, they are doing community service :slight_smile:

Can you describe why should we not allow harvesting when gas is high? @pocketsquare

Ok got it didnt realize the user was paying … thought maybe it was coming out of the rewards balance.

So when it comes time to harvest, and lets say I want my rewards, am I initiating a harvest for all xxSUSHI holders/rewards or just my share?

If you call harvest, you would be initiating disbursement of reward for all the xxSushi holders :slight_smile:

I really like this evolution.
Staking on all chains, introduction of auction, & a permissionless decentralized harvest mechanism.

A few things to be considered:

  1. I think there’s a bit of fatigue with Sushi naming. Why not evolve xSushi into this and continue to call it xSushi?

  2. There’s an opportunity to create a new revenue stream for sushi by introducing a small bid fee in the auction process (say .05% of bid, or .25% of bid). I don’t see a mechanism in which a small bid fee discourages anyone placing a bidding below current market value of the rewards as we approach min/max TTL. It ends up being a simple tax on an arb. Create a way to interact via API’s or bid programmatically and we now have another revenue stream for Sushi.

Yes absolutely, we can name whatever we want, though I believe we should choose a new name, or atleast add a 2.0, as it would avoid the confusion. If we name both versions xSushi, massive confusion.

Yes, we will have APIs and people can bid programmatically.

The reason I’m not much inclined towards the idea of having a fee per bid is that, a bidder might have to bid multiple times and might not still win the bid, it would cause normal bidders to incur a loss on their upfront capital. This might discourage some bidders to participate. For this system to succeed, we want multiple people to keep raising the bid, to come as close as the actual price of that asset at that time. I don’t have data to back it up, but I think having a fee per bid, might discourage normal users to bid as well, as they might not win but keep loosing some money, and hence not interact with the system at all. The loss depends upon how many times they bid and what is the fee.

Do you have any fee amount in mind that we should take per bid?