ENSIP14 Proposal: Multiply ENS Integration Incentives

đŸŒ± ENS Ecosystem
1

Background

The existing ENSIP-14 draft proposes a method for attributing the source of .eth name registrations. Apps that help people register their .eth names, such as ens.domains, ensfairy.xyz and others achieve this attribution by placing a special fingerprint on the first 64 bits of a parameter called ‘secret’ that is passed during each registration. A dune dashboard has been created showing this approach is able to provide attribution for registrations. All good so far.

Need & Opportunity

But what about attribution for .eth renewals? Renewal attribution is very important, but is missing !

For example, in all 4 of the last 4 months the revenue for .eth renewals was greater than the revenue for .eth registrations. Have a look in this revenue dashboard.

renewals
renewals1420×796 53.6 KB

We can hope that renewal revenue will continue surpassing registrations. If we don’t maintain strong renewal rates, there’s a very negative impact. It’s like trying to fill a bucket with water that has a large hole at the bottom. The smaller we make that leak, the faster we fill the bucket and grow the ENS ecosystem :rocket: !

ENSIP-14 can enable the creation of strong incentive programs for web3 app developers to integrate ENS-related functionality directly into their apps. Rainbow Wallet is a good example. Rainbow integrated a .eth registration feature directly into their wallet app. Wouldn’t it be awesome if we could give more web3 apps and wallets stronger financial incentives to provide similar features?

IMG_7355.PNG
IMG_7355.PNG424×917 29.7 KB

If we don’t give a mechanism for attributing renewals then more than 50% of .eth revenue might not be possible to attribute. This means a lot less potential rewards and incentives for web3 apps to be more like Rainbow.

Technical Background

At a technical level, ENS name durations are specified in seconds, not years. You don’t register / renew a name for 1 year. You actually register / renew a name for 31,536,000 seconds.

Generally all user interfaces for register / renewal ask the user to set the duration in years. There are also a few special cases, such as ens.vision, that allow for duration to be set in months. Each month represents 2,628,000 seconds.

We’re familiar with the idea that a 5+ character .eth name is $5.00 USD / year. But another way to think about this is that a 5+ character .eth name is actually $0.0000002 per second.

Technical Proposal

The ‘secret’ parameter passed during registrations doesn’t exist when making a renewal. But we can use a very similar technique to achieve our goal using the ‘duration’ parameter.

Instead of adding a 64 bit attribution fingerprint in the ‘secret’ parameter, we can add a 16 bit attribution fingerprint in the ‘duration’ parameter that is passed on both register AND renew.

A 16 bit fingerprint is still large. That gives a space of 65,536 distinct potential attributions. ENS will be unbelievably fortunate if we ever have the “problem” that there are more than 65,536 web3 apps integrating registration and renewal functionality for .eth names !

Similar to the existing ENSIP-14 draft, a web3 app could generate their attribution fingerprint by taking the first 2 bytes (rather than the first 4 bytes) of the namehash of their domain name.

If we say that MONTHS_REQUESTED represents the number of months a user wants to register / renew a name for then the attribution fingerprint could be applied to a ‘duration’ parameter using the following pseudocode:

SECONDS_PER_MONTH = 2,628,000
ATTRIBUTION_FINGERPRINT = getFirst2Bytes(namehash(“examplewebsite.com”))

actualDuration = (MONTHS_REQUESTED * SECONDS_PER_MONTH) + ATTRIBUTION_FINGERPRINT

In other words, a period ranging between 0 seconds and 65,535 seconds of duration would be automatically added to the user’s request as an attribution fingerprint. The exact number of seconds added would depend on the exact fingerprint.

In the highest case of adding 65,535 seconds of duration, this would add only $0.01 to the price of the registration or renewal. In the average case it would be $0.005, or about half of 1 cent. And absolutely none of these prices would go to waste. Every single second of that period would be time the domain was registered or renewed for.

The attribution fingerprint of each registration or renewal transaction on the blockchain could also be simply checked. Given actualDuration as the duration recorded on the blockchain for the registration or renewal:

attributionFingerprint = actualDuration % SECONDS_PER_MONTH

Benefits

  1. Multiply the potential incentives for web3 apps to integrate ENS functionality (2x or more!)
  2. Acquire better data about which apps are driving all ENS revenue types. This visibility also helps spread knowledge and inspiration across the community on the approaches that are working best.
  3. Eliminate the problem with attribution tracking needing to inspect internal transactions. Of course there are workarounds to this, such as using the Dune Dashboard. However, that’s inconvenient as not many tools support inspection of internal transactions like Dune. Dune also updates infrequently. On the other hand, the ‘duration’ approach being proposed here could be tracked through some minor updates to the official ENS Subgraph in real time and exposed for easy access to the whole community through GraphQL APIs.
  4. Standardize attribution tracking logic for all .eth revenue generating transactions.

Feedback appreciated ! :grinning:

3 Likes
2

Great ideas being shared here!

Not a relevant cost for the user and no code changes on existing ENS contracts.

2 Likes
3

@taytems Hey, I see you’re often doing work on the official ENS subgraph. It would be great if there’s any thoughts you could share on the technical feasibility of updating the ENS subgraph to include a dedicated field on each registration or renewal for the attributionFingerprint as I’ve described it above?

Not suggesting to actually make any changes right now. Let’s get more input from the community first! Just thought it would be nice to get your advice on potential feasibility of the overall ideas here :grinning:

I also see there’s discussion in a draft pull request where you and @nick.eth have discussed updating the ENS subgraph to include fields that index the cost of each registration or renewal in ETH.

Perhaps all of these ideas could be combined in a really nice way. We could achieve real time attribution and cost tracking for all .eth registrations and all renewals.

Thanks for your advice !

4

hey,

i definitely think that the core issue here is worth pursuing, but i think the implementation you’ve proposed doesn’t work that well.

if using the same namehash id method as ensip14, it would be far too easy to hit a collision. 65,535 different ids is sufficient only if each id is assigned (which is not what your current proposal shows).
there would need to be some kind of id registry where each id is ordered via manual assignment.

additionally, adding the fingerprint to the duration means that this proposal would not be backwards compatible with some existing UIs. while adding to the duration is fine if the duration is always going to be in months, features like extending a name to a date instead of by a duration, and syncing expiry dates between many names, would need to be modified.

here’s a dune query of extension transactions that would be compatible/incompatible with this proposal, broken down by day: https://dune.com/queries/2843809/4751909

from that data you can see that incompatible transactions hover between 40-50% each day.

i think it would be reasonable to implement the same 8 byte fingerprint system (or potentially 4 byte) as outlined in ensip14, but at the contract level for the renew function.

4 Likes
5

Great feedback @taytems ! And nice work on the Dune analysis :clap: this helped to inspire an idea I hadn’t considered yet.

Agreed that changes are needed from the earlier post. Been inviting collaboration from all who are interested in building an improved ENS Ambassador Program proposal. Still a work in progress and haven’t posted updates to the forum yet. Here’s a quick reply for the very good points you raised:

For the hash collision challenge, I shared an updated idea for this in the ENS Ecosystem WG call last week. Idea was to move to allocating attribution fingerprint ids using subnames. For example, let’s imagine the creation of a specialised subname registrar for ambassador.ens.eth. To claim ambassador id 123 you simply register 123.ambassador.ens.eth. This approach also helps to resolve any ambiguity in asking: If a reward is earned at time T by ambassador id 123 to what address should any rewards for ambassador id 123 be attributed? In summary: it can be attributed to the owner of 123.ambassador.ens.eth at time T. This contract could also enforce that only valid ambassador ids could be claimed.

Some time based rentalFee could also be configured for these subnames. This keeps the set of available ids from being exhausted across time as claims expire. It also helps as a defence against self-refunds that Nick and others have spoken about before. The defence mechanisms here are a larger set of ideas that need more planning.

The specialised subname registrar could be configured to emit various events that an updated ENS Subgraph (or other tools) could use to calculate balances with perfect accuracy.

For example, events such as:

  1. Claim subname (claim ambassador id)
  2. Renew subname
  3. Transfer subname
  4. Set reward rates (controlled by DAO)
  5. Distribute reward (performed by DAO)
  6. Etc



 could be emitted. This would enable the offchain summation of the total rewards earned by an address and the total rewards distributed to an address. Here I’m assuming a process where maybe once per month someone would execute scripts on behalf of the DAO that would automatically distribute awards by sending them through this subname registrar for the purpose of all the desired accounting (through the “Distribute reward” event).

The “Set reward rates” event could also be useful. Maybe at the initial launch of such a program the initial reward rates are all set to 0 if any special testing period is desired. A DAO vote could then modify those rates across time, including setting them back to 0 if at some point a different approach is desired. I think it’s good to ensure future DAO flexibility on incentivising and rewarding ENS Ambassadors. Awards earned at time T could always be according to the reward rates set at time T.

Really like your feedback about the use of seconds per month in calculating an attribution fingerprint! It got me thinking about using seconds per day instead. This remains more than enough to fit all possible 2-byte ambassador ids. It also provides an easier path for more advanced renewal UIs to apply their attribution fingerprint across a wide range of scenarios.

Flight about to take off so better stop there for now. Please continue to attack the ideas here ! :smiley: It’s very helpful. Will be back from holiday in about a week. Also happy to chat more in Twitter or Telegram if you’re interested ! Details in my ENS name :+1:

1 Like