Replies: 6 comments 19 replies
-
Good thinking, as you said there's no way the auction is the right design for a fixed price asset. The lottery sounds okay, where should the information entropy / randomness of the lottery comes from in your opinion ? I'm afraid the result of the lottery may be manipulated. |
Beta Was this translation helpful? Give feedback.
-
Nice job spotting some of the flaws in the auction system! Going to throw in another alternative solution which can add to the discussion: Implement a buyback contract:
The different incomming tokens to the buyback contract could be handled with tokenfallback method or a similar approach. This system would create constant buying pressure on icx and result in a price increase. Value would be equally spread to all icx holders through this price increase. Q: Not sure how hard this would be to implement using cross chain assets? |
Beta Was this translation helpful? Give feedback.
-
Suggestion from @Yeol-yeol
|
Beta Was this translation helpful? Give feedback.
-
Great to see this discussion. I originally designed the auction system in order to avoid using an oracle price-feed for such a crucial piece of our infrastructure, but as oracles have become more widely used and are currently securing billions of dollars of assets, I'd actually like to suggest using a simple oracle price feed. My proposed solution would be:
Pros:
Cons:
I actually think it would be worth considering to change this prior to launch. @jorisvial let's think about it and discuss next week. Although we already spent time writing the SCORE with the auction logic, I believe it will be even more difficult to change this post launch as people will already be using the product and there will need to be significant changes to a live frontend. From my experience, it's always harder to make big changes like this to a live product. |
Beta Was this translation helpful? Give feedback.
-
"If the asset price is always 10% cheaper vs ICX, no one would waste this arbitrage oportunity, so won't this make it so the pool is always empty and the assets are sold as soon as they arrive? Making it a first come first served system anyway? The faster bot to get it wins?" Indeed that is the case, but I think perhaps we are trying to solve two different problems. I do not mind if bots run the show. That's not a bad thing to me personally, it means it will be a smooth and efficient market, with bots/traders buying ICX from exchange to be prepared to purchase assets at a discount from our chain. I was more-so trying to remove the unnecessary complexity I introduced with the auction system as a way to avoid using oracles. Now that oracles are more widely accepted, I'd gladly simplify the process/development. |
Beta Was this translation helpful? Give feedback.
-
I have been thinking about a way to achieve: 1.) Effective arbitrage opportunities The current auction system does not achieve either one of the aforementioned goals. It is serviceable, but far from ideal, and I'd like to change to something like this prior to launch if reasonable. I believe the below solution will achieve these goals @jorisvial. It is very similar to a syndicate book from my previous role in banking, so I'll call it the BTP Syndicate for now. I'll walk through an example then explain. Imagine there is 100 ETH from fees in the FA SCORE. And imagine the current market price of ICX/ETH is 10 ICX per ETH. The first step is collecting "indications of interest" over a set period of time, let's say, 24 hours.
The total indications of interest at the end of the 24 hour period are 100,000 ICX.
At the end of the 24-hour period, the price of ICX/ETH is still 10 ICX per ETH. This means the BTP Syndicate is ~10x oversubscribed. From here, the BTP Syndicate will allocate the 100 ETH to Bob, Alice and Charlie, pro-rata, based on their IOIs.
The price that is paid will be a simple calculation. At the end of the 24-hour period, we will pull an oracle price from a BAND oracle and discount it by 10%.
This may sound complicated, but from a UX perspective it will be quite easy. You will visit the BTP Dashboard, select an asset, then submit how much ICX you'd like to spend on this asset, where your purchase price will be guaranteed to be 10% off market price at time of purchase. If the BTP Syndicate is oversubscribed for an asset, all those that submitted IOIs get their pro-rata portion based on their IOI. If it is not oversubscribed, you just pay exactly what you indicated with the 10% discount off market price. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I think the Fee Aggregator auction system is broken by design and I want to share my reasoning, so I can get a chance to understand what I'm missing.
Why do we use auctions
In real life, auctions are a great way to value things that have no market value. For example in art, there is no market value for a specific piece. Therefore the most optimal way to value this object is to run an auction and let participants to decide of it.
BTP Fee Aggregator auction
In BTP Fee Aggregator, the auction item in question is the accumulated value of the tokens (generated BTP fees). Those tokens represent actual coins on other chains. Which mean that they do have a very well know market value for everyone.
When an auction can be started, the first bidder should in theory directly bid with the optimal bid, in order to cancel any interest from other potential participant. Most especially in current implementation, there is a minimal bid increase for each new bid. It's currently set to 10% but the value actually does not matter.
Example showing why it's not working
Let's use an example. There are XXX IRC31_PRA token in the FA, worth 100 ICX in total.
100 / 1.1 = ~91 ICX
91 ICX * 1.1 = 100.1 ICX
in order to be the new highest bidderPRA market price movement scenarios
Based on this example, we can see that the FA auction is actually a "first come first serve" system. Now some of you may say that PRA price will move, so maybe it will be interesting for a new bidder to bid again. Let's see the possible scenarios here:
So from those 3 scenarios, 2 of them breaks the auction as soon as it starts. I do think this is broken and I would like to offer an alternative, which will generate most likely more ICX for the CPS as well.
Lotterly, an alternative to auction
Using a lottery to sell all aggregated fees allows anyone to participate easily, with any amount they want. If we reuse the previous example, you may bet between 1 ICX to 100 ICX. The more you bet, the better your chances at winning. However, since there is no limitation on the amount, it should attract many people to try their luck. This should therefore collect more ICX overall which will benefit the ICON ecosystem (more ICX going into the CPS or being burned). It's a very straightforward system that everyone can understand and already used at least once in real life (auction rules needs to be explained). It's not difficult to implement too.
If you read all of this, thanks, and I hope to hear your feedback.
Beta Was this translation helpful? Give feedback.
All reactions