Referral function. On every sale, a percentage (set by the DAO) of every sale is redirected to an address set by the frontend. Meaning that if you build an app that registers and renews names, you have a business model. Yes, this means you can override it to set referral as yourself get a 10% discount on purchases. We don’t see that as an issue.
One-transaction purchase. Currently registering a name requires 2/3 steps, a commit, wait, reveal. Both these phases still happen, but we’ve added an option that allows the reveal to be executed by anyone - and get an optional tip. Smoother experience for the user.
Batch Reveals: you can now commit and reveal multiple names. This translates into massive gas savings: registering 2 names is 20% cheaper (per name) than the current method, registering 20 names is 42% cheaper!
Don’t get too excited. Name Wrapper has been developing for over a year, this is just the first step on a long process. We need to have audits, code reviews, and in the end we’ll start a governance process for approval of all features and finally to add the new controller as one of the permitted controllers.
If you want to get involved, you can help now by doing code reviews or just participating in any way you want!
I still see this as an issue, tbh. This has been discussed before, but in essence implementing referral fees in this way reduces the cost for registration by X% for bulk ENS buyers, which is the group that the fees are designed to keep in check in the first place. In that way, referral fees work a little different in ENS than something like Zora, for example, since in ENS, the sole purpose of the fee is resisting domain parking.
Previous discussion for context:
An additional point I’d add is that while I think finding ways to incentivize the spread of ENS names is important, I’m not sure it would be healthy for the ecosystem to incentivize selling .eth names so directly at this point. Reason being, I think subdomain adoption is much more important to the long term success of ENS, and adding a direct profit motive into the protocol for .eth names could work against that effort and distract from the new world Name Wrapper could usher in.
Curious to hear if @nick.eth has changed his views on this since that discussion earlier this year.
The other improvements are great though! Good work!
I still feel this way. I think allowing open referrals will effectively equate to a discount to anyone doing bulk-registration. Combined with gas savings on bulk registration it effectively acts as a large discount for squatters.
One solution to the first problem would be to have an allowlist of referrer addresses that the DAO administers, so integrations that advance the ecosystem can be rewarded, without acting as a subsidy for mass registration.
One other potential mitigation for the gas cost issue would be to deduct some portion of the gas cost (basefee * gas used) from the registration fee, meaning we effectively subsidize gas costs for individual users.
The one criticism I have to offer is that the the proposed modification to the registrar controller increases the cost of single registrations by around 12%. On the other hand, it is attractive for entrepreneurs who wish to build front-end apps to prospect ENS services in their own domain.
Subsidizing gas costs for single registrations is an option, but I wonder about the second and third order effects of implementing gas fee subsidizations in this way.
I think having an allowlist is a good idea… and what if the allowlist were limited to 1 & 2 character names? Integrations that meaningfully advance the ecosystem, like a registrar for instance, can lease out subdomains specific to their industry niche.
An on-chain registry for music rights, for example, would benefit from this schema. You can build an app that tracks a musical work’s performance (streams, radio play, etc) using any of the traditional identifiers music rights agencies currently use (IPI, ISWC, ISRC, etc) and store the identifier as a text record on the subdomain of the 1 or 2 character TLD.
One suggested feature that we discussed internally but didn’t add was to add a minimum withdrawal amount. This way the feature would only make sense for an app that is registering hundreds of names. I think this would be more open than having an allowlist, since it allows real permission less referral programs.
The old registrar would still be allowed so if you just want to register one domain you could.
I disagree. Even if subdomains become be bigger than main domains, incentivizing sales of names and making them cheaper is good, as it incentives more domains to be on chain, and maybe using a gasless registrar. We should follow users where they lead, and I don’t think it’s a good idea to purposefully stop making improvements for our core product because we want adoption on another level.
I support this idea. In the new code, the full registration costs roughly 300k plus 136k for each name. So if we used about 436k*basefee for an extension in the length, we would be in practice subsidizing the first name for free, and at the same time not benefitting so much the people doing multiple domain registrations.
That doesn’t make a lot of sense to me? Individual name buyers aren’t the problem, it’s explicitly bulk buyers that are the concern, and that benefit most from the cost reduction of setting the referral fee back to themselves, reducing ENS resistance to parking.
@AvsA try-catch (and refund mechanism) might be needed in this portion to prevent reverts during bulk registration - allow users to proceed with their registration for other names on the list instead of paying high gas cost on a reverted tx due to one name not being available or short on rent price.
That’s basically just making referral fees an additive cost. I really don’t think this is something that should be hand-waived away. We should be pretty careful with what is added to the core protocol at this point, and this particular feature doesn’t come close to meeting the bar, in my opinion.
Especially since this issue with referrals has been discussed a bunch before, including for this particular set of changes in a WG meeting. Yet, nothing has been introduced since then to try to address it. Instead, it keeps getting waived off as “not a big issue.” It’s very clearly an issue that has ramifications for one of the most important mechanisms in the protocol.
This is the only solution that anyone’s really thought of so far, and it’s the only one I can think of too. However, if something like this were to be implemented, I’d prefer it be implemented outside of the core protocol as a rebate system run by the DAO, rather than baked in, so it doesn’t affect the perception of credible neutrality of the protocol itself.
It’s not handwaving. I simply believe that the upside of creating a self sustaining business model for app integrations, independent registrars and wallets is vastly superior than the small downsides of giving some power users a 5%-10% discount.
I understand your thought here, but I think I disagree. It’s not self-sustaining because it’s funded by the DAO. Maybe that’s semantics though.
My biggest reservation is that I don’t think these proposed changes benefit individual ENS users or add functionality to ENS. The changes benefit high volume, 3rd party registrars and resellers, while adding complexity.
If the resellers and registrars independently provide value to the users, then they can charge a bit more for the registration and get their profit directly from the users they provide value to. It’s the open market principle. ENS shouldn’t be subsidizing those services or picking a whitelist of resellers to subsidize.
If there are app integrators or independent registrars or wallets that need to be bootstrapped, we should fund them with generous grants instead.
This would still provide a significant benefit to individual users who register hundreds of names, though. And it’d be trivial to write a referer contract that combines multiple peoples’ registrations and splits their referral fees to them when it meets the min withdrawal requirement.
That is a good point against a min withdrawal. Still I’d like to find a solution better than a DAO controlled allow list, as this defeats the purpose of allowing anyone to build an app without needing to go through a political approval process.
Maybe we could add some requirement that is open but non-trivial to achieve with a blocklist. Like “only available for owners of 3-5 letter names” or “you must have a PoH/Poap/NFT” of some kind.
Pull Request
