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 you are saying that the auction / bar serving process will now be kicked off by whoever wants to bid?
- This is basically a basket trade what youre describing. Someone bids, at a discount, for the entire portfolio of fees and then once won, they sell off the individual positions and hopefully collect a spread to the discount they bid. I understand that this is likely ‘easier’ for the team but we should have a way to measure the performance of this over time to ensure we arent giving up too much spread to the market (ie auction completion price vs current spot).
1 Like
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…
1 Like
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.
1 Like
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.
1 Like
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.
2 Likes
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.
1 Like
I agree with the vast majority of this proposal, however, concerning the auction mechanism, I think our auction game theory is wrong.
Given that users are bidding in xxSUSHI to purchase the revenues generated by the protocol. thus incentivizing users to pay the most SUSHI for the rewards, with the locked bid mechanism making it upwards-sticky.
Instead, I would argue we want to incentivize users to pay the least amount of SUSHI for the revenues they are earning in return, thus driving the value of SUSHI upwards.
If we consider that we want to replicate the incentives of the current model xSUSHI, we are assuming protocol revenues to equal an equivalent amount of it in SUSHI (give or take some for slippage). Moreover, I believe we want to implicitly create buy pressure for SUSHI as the current model does.
Let us assume the following scenario using the proposed auction mechanism.
For simplicity, let’s assume 1 xxSUSHI = 1 SUSHI throughout this example.
-
The market price for SUSHI is 0.1 ETH. An auction of 100 ETH goes up. The maximum rational bid would be 1,000 SUSHI. Let us assume Alice bids this amount.
-
The market drops and the price of SUSHI drops to 0.05 SUSH/ETH. The maximum rational bid increases to 2,000 SUSHI. Beth now enters, bidding her sushi and removing Alice’s bid.
-
The market quickly rebounds to 0.15 SUSH/ETH. The implied price of the auction is now stuck at 0.05 SUSHI/ETH and since users can only bid a larger amount no rational bidder will attempt to bid a higher number.
Therefore, the xxSUSHI stakers will receive an outsized return in terms of APY%. This will drive sell pressure from users who will want to maximize their returns since the contract just bought SUSHI at a massive discount.
Since we have not created the buyback pressure of the current system from the market this would result in direct sell pressure.
We can argue that there might be perfect actors that will hold their excess SUSHI returns, or the bidders buy directly from the market but this will be outweighed by the rational actor looking to maximize returns.
I am still thinking about it but, IMO I would think a unique bid auction (lowest bid wins) system would be preferable since it maintains SUSHIs value.
2 Likes