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!
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.
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 
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
I really like this evolution.
Staking on all chains, introduction of auction, & a permissionless decentralized harvest mechanism.
A few things to be considered:
I think there’s a bit of fatigue with Sushi naming. Why not evolve xSushi into this and continue to call it xSushi?
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?
Agree on the naming, perhaps we can call the new version xSushi and give the old xSushi token some deprecated tag?
On the fee, it reads as a tax on the return of capital. Would generate revenue but at the expense of tokenholders? Or is it that the bidders pay the fee?
Bidders would be willing to pay a small fee to bid on the reward pot.
Is the expectation that the team will still be serving the bar and that this will allow for supplemental serving or is the team going to stop serving and it will be up to the community
It’s up to whomever is trying to buy the tokens that are being auctioned for sushi to serve the bar.
I think there’s some confusion with the auction, it’s basically auctioning off all the tokens that come in from fees (all fees broken down into individual tokens) to the highest bidder in sushi. Sushi then served to bar, and individual that bought all the fees, likely is a bot, then sells off each individual token.
so 2 things:
So, the bar serving and the auctions are different. Bar is served with additional Sushi or xxSushi. Yes, anyone can call harvest and serve the bar.
There is slight change from what Ser @JiroOno has described. The change is that instead of the LP tokens, the underlying tokens are auctioned. The LP tokens are unwrapped before the auction, into the tokens which can be kick off the auctions for each token individually.
The auction mechanism was mainly introduced as a way of having price discovery for the asset without relying on on chain oracles or manual intervention. The bidders are expected to put their best bid out or they will likely to be outbid by someone else. So, the spread of discount depends on where you will be selling the reward assets. For instance, a cex might provide better liquidity for some assets than dex, or OTC might have a better trade than the cex. So, it all depends upon where you can sell the asset. The other point is when you sell the asset. Currently, when we convert the asset we sell it at the price that time. However, as auctions are time bound, the price of asset would change and can have two effects in the system.
Price of the asset increases - In this, if the auction is not finished someone is likely to outbid the recent bid. So we get a better pricing than immediately selling it. If no one bids, and the auction finalises, we still get almost similar rate minus the additional discount for the bidder. The discount for the asset depends upon the risk tolerance of the bidder, some can go up to 0.5% or some may not go over 5%.
Price of the asset decreases - In this, if the auction is not finished, no one will bid, as the asset is now less worth than the highest bid itself. Once you have submitted a bid, if it’s the highest, it gets locked till there is a bid higher than this. So, for the highest bidder there is always an obligation if the auction finalizes with his bid. In this case, we get more upside, as we are getting more than the asset is worth this time.
Once the auction is finished, the xxSushi which was used for bidding will be moved to mainnet to serve it to the xxSushi holders. Anyone, can do this process, completely permission-less.
So, there is actually no best way to judge on how the system is performing as compared to the older version. Also, the spread depends upon the bidder and their risk tolerance, plus their abilities to trade and decide on future trends.
@sarang , regarding this - won’t the 12 hours period (needed for an auction to be finalised, if there are no more bids) seem a bit risky to the potential bidders? I mean price can change a lot for 12 hours and result in quite a loss, this may stop users from bidding…
Yes, so the bidders have to be smart when it comes to bidding, hence we will see various people bidding with different strategies. Also, we haven’t finalized on the exact time periods yet
We can definitely reduce or increase the time periods, before we finish the implementation and roll it out. Do you have any suggestions in mind as well, what could be ideal? It would be good to have more eye and research on this part.
As most likely bidders will use bots, which will monitor the auction all the time, probably we can reduce the period to 6 hours? Or we can give the option to the winning bidder to cancel the swap if the auction price is x% (like 10 for example) higher than the market price on Sushiswap pools against 5% fee? Could be a combination of both… and other values
Just means theyll likely build an even bigger discount into their bid. I dont know, maybe I’m not fully understanding this mechanism but I’m skeptical about how useful it will be in its current form.
Yes, this is another detail which needs to be cleared - what % of the market price will be the starting auction price. As this will define what is the maximum discount a bidder can get.