ENSIP On Chain Source Parameter

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

2 Likes

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.

4 Likes

No need to wait for v3 :slight_smile:

1 Like

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.
2 Likes

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

3 Likes

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.

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.

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.

Love how the ā€œFlock Watcherā€ site is coming along. :grin: (Gregā€™s link above - https://ens-registrations.vercel.app/ )

Great work all around on this. :pray:

Anyone knows who 02224567 is?

Maybe itā€™s someone that wants to highlight a flaw in the standard not having an on chain registry :man_shrugging:

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.

1 Like

Thanks for sharing, Iā€™ll take a look at this tomorrow!

1 Like

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?

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:

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.

1 Like

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:

To open a can of wormsā€¦ would other text records be distinguishable too?

It is due to the different contract / internal transactions, and hard to decode the transactions because itā€™s an unverified contract.

I think we might have to switch to indexing by contract events rather than transactions, since internal transactions do emit events on the official ENS registrar. But these events donā€™t include the secret, so weā€™ll ultimately still have to get it from the transaction itself. I can think of a hacky way to do this just for ens.vision, but ideally we donā€™t have to handle each contract individually.

Iā€™m talking to the sort.xyz team to see if they have ideas, or I can probably build a custom indexer and include it in the same open source repo.

4 Likes

No, the same approach would not work for setting text records (including avatar) because thereā€™s no secret parameter, which is what weā€™re using to track registrations. The only reason the secret exists in registrations is to prevent front-running, which isnā€™t a problem with text records.

2 Likes

Hey everyone. We will release another bulkreg in the near future (will consider verifying it) so now is the time we can add some kind of ā€œstandardizedā€ event if you guys think that is the way.

But that seems also like a lot of overhead to manage / know all contracts which act as registers on your end?

I can also share the existing ABI for you to decode our transaction if that helps. Iā€™ve already added the ABI to dune long ago for example and the Secrets can be viewed with this data:

ā€œensbulkreg_v5_ethereum.ENSVisionBulkv4_call_visionRegisterā€

edit 2- of course i just re-read the thread and saw sort.xyz is using Dune in the back end ā€¦ :smiley:

2 Likes

was thinking a little more and the Event might not even work for my next version ā€¦ as im not passing individual params to my function in the new version per register callā€¦ but instead its acting like a traditional multicaller working with a bytes[] ā€¦ could just emit the whole bytes string and you decode that to get Register paramsā€¦ but :neutral_face:

hmmm Iā€™ll reach out in twitter dms to brainstorm this more