Fair point, forgot about the gas implications here.
It’s not clear to me why this would be an improvement. Can you elaborate?
If you look at these numbers basically the price movement from day 20 to day 28 serves almost no purpose, with a drop of only around $100. The majority of domains sold during the auction will probably sell in the $100 - $2000 range. I think the goal should be to give potential buyers enough time to find their price point. @jefflau.eth numbers would descend from $2K - $100 in around 5 days. My example shows that this period is expanded to around 15 days.
I see a different logic for each of the price ranges, which can blend into each other, but are actually quite different from each other. The first phase is the basically infinite price to the highest expected price, which I think could happen in the first 24 hours. From the highest expected price to around $2K, I think should take around half the remaining time, and then the final decent from $2K to the end of the auction should take the rest of the days.
I am imagining basically making a price decent curve that does this basically by design, i.e. by hand, then finding a line of best fit using automated tools. Then we can simply use the equation that is derived. If the equation adds complexity i.e. gas to the transaction, then maybe it’s not worth it, but maybe it’s fine. I am basically advocating for human design over basic math.
I disagree that it “serves no purpose”. I think having a whole week for the average (not rich) user to be able to register their name for relatively cheap, is the purpose here.
4 Likes
I see your point on the number of days dedicate to the $100-$0 range, particularly given the current gas cost of registering a domain. However, I don’t think this is something we should tweak to a fair-thee-well; an exponential curve has the easy to understand property that it diminishes by the same percentage each period, and I think this is very close to how people perceive cost. Baking in hardcoded assumptions around what a “highest expected price” etc seems more likely to require frequent changes, too.
One possible tweak would be to subtract ~$50 from all values and terminate the premium at day 21. That would give the following figures:
0, 99999952.32
1, 49999952.32
2, 24999952.32
3, 12499952.32
4, 6249952.32
5, 3124952.32
6, 1562452.32
7, 781202.32
8, 390577.32
9, 195264.82
10, 97608.57
11, 48780.44
12, 24366.38
13, 12159.35
14, 6055.84
15, 3004.08
16, 1478.20
17, 715.26
18, 333.79
19, 143.05
20, 47.69
21, 0.00
3 Likes
= human design.
"Humans are underrated,” - Elon Musk
I agree with subtracting ~$50 though for the current model.
1 Like
Is there any consideration for a piecewise solution?
I think on the previous thread, my thought was exponential decay followed by a slower linear auction, and I’m again met with the same thought here.
This would seem to produce a more agreeable price curve across a broader range of price/time-based objectives. But it would increase implementation complexity.
Ultimately, we can try to tune the exponential to capture all these objectives at once, but the market behaves differently on the two ends of this auction curve. So I think we should talk through why we do or do not like piecewise strategies.
I just don’t see the advantage of a piecewise solution. It seems to me that an exponential curve - shifted a little on the Y axis for convenience - solves our problems elegantly and with little extra complexity.
Just wanted to thank you for the well-written elaboration on your post 
I love to see technical posts, let alone ones that solve problems elegantly, thanks again to you and to @nick.eth for the great work.
4 Likes
Is there any advantage of pricing this in dollars? Since it’s a Dutch auction anyway, feels that the currency is irrelevant and we could drop the need for an oracle by using ETH (or even ENS?) directly.
Only disadvantage I see is if the price movement of the underlying token is stronger than the dutch auction: ie, if ether doubles in price in a day, the effective dutch auction price would be the same. But since that’s unpredictable, then the user should not account for that and simply buy when it reaches their target eth price (seems most ens names are price in eth anyway)
A 21 day premium termination seems like a good tweak. I can’t think of any drawbacks to it actually.
My only suggestion might be for the UI to easily convey the price decay/dutch auction mechanics. Maybe mouse-over pricing of the decay line. Maybe Day 1 - 21 numbering on x axis.
But I guess UI tweaks can be worked out later. Just wanted to put that out there because the concept of dutch auction, premium starts, decay rates is foreign to many users. I would like to see the tools they use to interact with ENS App as easy as possible, including buying/planning to buy expired names. I think this is same spirit behind new UI design coming out.
The current page already shows in both USD and ETH regardless of being premium period and I think it’s better to keep showing USD premium amount (as well as ETH) so that it’s easier to see how much premium it currently has relatively to the base price (which is $5~ denominated in USD)
Showing in $ENS only makes sense to me if you are proposing to charge in $ENS which is a whole separate discussion topic discussed at ENS Registration Fees.
Interesting thought - but I think that given that we’re charging for duration in USD, it’s less confusing to use it for the premium too.
1 Like
I think this solution is probably the best for UX.
Someone suggested trying out https://github.com/paulrberg/prb-math for the fixed point maths. The library works great, but adds around 2k gas. After discussing with Nick, I think we won’t use it as it adds complexity for more gas. However it’s a possibility to use if we decide to change the curve at all.
In terms of piecewise, I also think it doesn’t make sense unless the benefits are much better to avoid any unnecessary complexity. I think Nick’s idea of chopping off $50 actually makes the auction UX much better on the tail end.
Well we can still display it in the frontend in dollar terms. The main advantage would be to simplify the contract, make it more gas efficient and remove the oracle dependency. Would need to calculate how much gas it would save…
1 Like
The reduction in oracle dependency does seem like a decent trade-off.
I’m mulling over the idea of taking the premium in $ENS - it would take another approval (making it less gas efficient), but probably isn’t such a big deal for people paying premiums for names.
We’re already taking ETH, just in USD terms, so to adjust the curve to ether we would need to make the curve end closer to 0.001 given the amount ETH is worth, rather than end the curve at $0.50 to $1. Same thing with taking $ENS token, the price curve would need to stop around 0.1-0.2 tokens at current price, and if the price went up or down, it may need to be readjusted. USD oracle version has the benefit of ‘auto-adjusting’ for us (unless our pricing curve is just completely off)
The other consideration is, we will still be using an oracle for renewals/registrations anyway, so we are still dependent on the oracle for basic registrations, since we want to keep those at a reasonable USD price. I can’t see a way around not having an oracle for registration/renewal fees
1 Like
strongly in favor of keeping everything denominated in USD but paid in ETH. USD to keep it effective, predictable, and sustainable, and in ETH for simplicity
2 Likes
I don’t think it necessarily makes the code simple (nor gas cheap) given we are using the same Oracle for both with and without premium.
We would still be dependent on the oracle for the actual renewal pricing, though.
1 Like
This is a very interesting read. There are some strong arguments made in this study that both support and oppose the use of a descending auction.