Proposes to deploy Exponential Price Oracle Contract to replace the current Linear Price Oracle Contract.
Abstract
In the past we deployed the Linear Premium Oracle as a way to create a distribution mechanism that did not involve gas auctions and bots. This was largely successful and those who wanted a recently expired name could participate in the dutch auction and not have to compete on gas or with bots. Recently with the popularity of ENS increasing, the demand and the price people are willing to pay for these premium names has increased. In response to this TNL quickly drafted a short-term solution to raise the premium to 100k, which we felt was the upper limit for what a linear price decay curve could handle.
There are a couple reasons for this:
On a linear curve, if the price is too high the price decreases too fast and the UX is bad for a user who wants an exact price (especially at the lower end of the curve)
If you extend the time period out, the premium lasts for too long. E.g. If we made it 1 million USD and we wanted a similar price decay speed as 100k, we would need to run it for 10 months, which seems unreasonable.
We can see from the data below, even with the new 100k premium, we have already had a 5-7 domains go for maximum, or close to maximum premium. If a domain sells for the actual premium, it means the dutch auction is not doing its job and so we need to deploy a long-term solution for dealing with premium pricing.
Row label event_timestamp premium
1 bbc 2022-01-30 17:46:03 UTC 100230.75321837279
2 mets 2022-02-04 17:16:22 UTC 100082.49847319399
3 fbi 2022-02-05 06:02:31 UTC 99894.00632472485
4 fly 2022-02-04 18:49:00 UTC 99747.22640247621
5 ups 2022-02-05 07:46:24 UTC 98822.14747808539
6 dog 2022-02-06 16:19:05 UTC 92950.09208752771
7 ubs 2022-02-01 15:31:35 UTC 89633.15081063367
8 ubi 2022-02-19 17:06:17 UTC 72161.56328771653
9 punks 2022-02-16 00:15:44 UTC 59153.166146336
10 omg 2022-02-24 16:05:57 UTC 33214.42499419019
The long-term solution would be to change the actual curve to something that could start at a very high price, would decrease rapidly at the beginning and slow down at the end so you have better UX for users. And therefore this proposal is to deploy an exponential price curve, that does exactly this. This would allow fairer bidding on both high and low priced names.
Contract Code
Specification
Call setPriceOracle on controller.ens.eth, passing in the address of the deployed ExponentialPremiumPriceOracle (TBD).
Fantastic work by everyone involved, and I’m glad this was done so quickly. I hope the Dutch auction will make more sense to people when they see the starting price up at such a seemingly ridiculous level.
I mistakenly deployed the wrong version of the price oracle - the one I deployed depends on some as-yet-undeployed changes to the ETH registrar controller.
I’m sorry I didn’t catch this before putting the vote up. Please vote against this onchain vote; I will post a new one with the corrected oracle, or with only EP8 and EP10, shortly.
Hey @nick.eth or @jefflau.eth, what’s the status of this one now after the pullback? I don’t see any notes in Git/governance-docs or Tally after the quorum retraction. This thread and the postmortem thread don’t give any clues either.
Is there somewhere else to track the status on this?
It’d be nice if that tool-tip was still visible in the chart itself for prices under $14,000,000 or so, though at least it still shows the premium/date down below, not a big deal.
Although, is there an error with the premium search? When I enter $10,000 the chart displays the date for $1,000,000 instead:
OoopsDAO?