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.
We can experiment with time, we canât give to cancel bid. The issue is we canât get the price on chain, hence the auction.
No, that completely depends upon the bidders, we have no way to predict how they will bid, if the put it too low, they can easily be out-bidden. So, this entirely depends upon the market forces. Itâs very similar to arbitrage.
There is no starting price, the bidder decides it, and bids on it. There is no concept of discount in the contract at all. It all depends upon the bidder itself
Sample Implementation: GitHub - sushiswap/auction-maker at whitelist_token
The above implementation is just a sample to play around, actual implementation will differ. The above code also have bugs. DONâT USE IN PROD.
There is already a cost. Your capital will be locked. AND it will be locked in at a fixed price. As the market may move, when it goes in your favor, someone will make a better offer and you miss out. If it goes against you, youâre locked in. Adding a bid fee creates more issues than it solves in my mind.
@BoringCrypto I donât see a bid fee as an inhibitor to placing an arb as bid window approaches expiration.
Using the example above assuming there is demand for the SLP pot, the bid fee itself will not harm demand (even if I factor the fee into my bid). Itâs the simple cost to win the asset pool.
Maybe it evolves where the model is only bidders can re-bid, in the min-maxTTL window what gets exciting is the game theory to follow where bidders may compete to minimize their âlossâ in order to win the underlying assets.
In order for this to function well there should also be instances where people successfully pull off nice arbs.