ENSIP On Chain Source Parameter

[AvsA]

This discussion happened in October and I’ve updated the doc with some feedback that happened to it.

I’ve formally proposed the EIP on this PR:

ENSIP (unnumbered): Platform Source Parameter

What does this allows, in a short version:

• Provides an on-chain data of which apps and websites are bing used for the new names being registered
• Also allows that app data to be even further figure which of these new users came from specific social media campaigns, online influencers, newsletters, marketing programs etc, so we can measure who and what is being responsible for these new names
• Sets the initial paths for a future revenue sharing/referral program which rewards those apps or influencers for their work.

What’s next?

This will not result in a vote. The next step is simply:

• Lobbying apps to adopt the standard by adding their own source parameter
• Lobbying them into also adding a referral to memory to add the extra data parameter
• Help build apps to visualize these and in the future fund referral programs to reward these contributions

[matoken.eth]

Before lobbying to other apps, we should start off adding it into ENS manager site and that will give us the ratio of the third party name registration. I spoke to the front end team, and they will add a ticket after their v3 release. We probably better starting off with some sort of id repo like slips/slip-0044.md at master · satoshilabs/slips · GitHub then shift to on chain contract when we implement some sort of rev share

[AvsA]

By lobbying other apps I meant basically convincing ENS manager and ENS Fairy to adopt it

[slobo.eth]

ENS Fairy adopted the initial version of this proposal @gregskril can provide more context.

[AvsA]

Love to hear this!
Can we start working on a dashboard to visualize it them?

[gregskril]

Nice seeing this resurface! As Slobo mentioned, I’ve implemented a similar idea into a few apps but with a different (worse ) hashing method, so I’ll get those updated shortly. I’ll also start thinking about the best way to track this in a dashboard.

[gregskril]

I just got a v1 of the dashboard working → https://ens-registrations.vercel.app

It uses sort.xyz (an API-first version of Dune) to query the first 10 characters of the secret in register and registerWithConfig transactions from the official Registrar contract. Here’s the query.

Sort usually only keeps 7 days of transaction history, but the founder was nice enough to whitelist the Registrar contract so that it will keep all future transactions (starting an hour ago). This is why you’ll see all rows having a count of 1 right now on the website.

[gregskril]

No need to wait for v3

Track registration source on-chain via ENSIP 14

[liubenben]

Only a platform code is not enough IMO. I think it is better if it combined with a platform code derived from its DNS and a web3 identity code derived from ENS, like:

    const referrerDns = namehash('referrer-dns-demo.xyz').slice(2,10)
    const referrerEns = namehash('referrer-ens-demo.eth').slice(2,10)
    const secret = '0x' + referrerDns + referrerEns + crypto.randomBytes(24).toString('hex')

advantages:

1. DNS is standardized and easy to verify.
2. ENS is web3 native and it could easily receive referral fee in tokens. Also, in the future, maybe we could let the owner of the ENS claim their referral fees rather than distributing these fees through a web2-method.

[wolfram]

I’ve added the parameter to Predomain. It’ll come into effect on the next update.

[gregskril]

My initial instinct is that not all registrations are coming/will come from DNS frontends (take @wolfram’s example above of predomain.eth.limo which we know can also be accessed from other IPFS gateways), so IMO that wouldn’t be the best primary referral code.

[liubenben]

yes, it does make sense. But I think there would a possibility that we hardly distinguish the real referrer if someone used someone else’s referral code to scam.

[AvsA]

@wolfram

I’ve added the parameter to Predomain. It’ll come into effect on the next update.

Thanks for that. Can you tell me which code are you using? I just saw a huge uptick of a new unknown code and wanted to know if it was you.

[5pence.eth]

Love how the “Flock Watcher” site is coming along. (Greg’s link above - https://ens-registrations.vercel.app/ )

Great work all around on this.

[AvsA]

Anyone knows who 02224567 is?

Maybe it’s someone that wants to highlight a flaw in the standard not having an on chain registry

[Octexor]

Hey
I implemented the platform source for ENS Vision on Nov 3rd, using the draft specification.
We have been using the first 6 bytes of the namehash of “ens.vision” (799faa801b1e) since then.
I can update it to match the current spec.
I’m just wondering why it’s not showing up on the Flock Watcher.
Note that we are sending internal transactions from our Bulk Registration Contract to the Registrar Controller.

[gregskril]

Thanks for sharing, I’ll take a look at this tomorrow!

[AvsA]

@Octexor

I implemented the platform source for ENS Vision on Nov 3rd, using the draft specification.
We have been using the first 6 bytes of the namehash of “ens.vision” (799faa801b1e) since then.
I can update it to match the current spec.
I’m just wondering why it’s not showing up on the Flock Watcher.
Note that we are sending internal transactions from our Bulk Registration Contract to the Registrar Controller.

I’m looking into this now. It’s probably due to the Bulk Registration contract. So in a typical transaction you’d register multiple names buy calling the registrar contract multiple times. But we are using Sort.xyz to extract all the calls and it does not take in consideration internal calls to the ens registrar. In fact neither does etherscan: I can see that your transaction does contains the string 799faa801b1e but because it’s not verified I can’t even understand what it does.

@gregskril would you know how to extract data from internal calls to the ENS registrar so we can add direct contract to contract calls to the watcher?

[AvsA]

@AvsA

Anyone knows who 02224567 is?

Answering my own question: turns out that wasn’t any registrar but a user that was registering a batch of “gpt-emoji.eth” domains which reused the secret. I also cleaned up some other usages of secret reuse (not showing any count < 10) and updated the site to reflect that:

ENS Registrations

So right now the only registrar it shows is ens-fairy. ENS Vision uses it but I can’t query the internal transactions yet, so we might have uncovered an issue with the standard if we can’t measure calls made from other contracts.

[184.eth]

Is it technically possible for a similar approach which tracks the setting of avatar records?

A couple apps already supporting setting avatar. I suspect more to come.

Examples:

• https://mintyourpfp.xyz’s Set Your ENS Avatar
• https://setavatar.eth.limo/

To open a can of worms… would other text records be distinguishable too?