Proposal to replace ENS14

🧑‍💻 ENS Development
21

I’d like to add few more options in the list for discussion… :pray:

A) <bytes12 random>+<bytes20 address> :

  1. referral format : https://app.ens.domains?ensref=domain.eth
    referrer address : ETH address record of domain.eth
    referrer hash : bytes12(random)+address
    msg.sender : EOA

  2. referral format : https://register.myapp.eth.limo?ensref=domain.eth
    referrer address : ETH address record of domain.eth
    referrer hash : bytes12(random)+address
    msg.sender : Contract

Offchain referral counter(indexer) service:
a) if reverse record for address(abi.decode(bytes(hash), (address))) resolves to *.eth
b) if registration tx was from contract address && check if reverse record of that contract resolves to “*.eth”

I ?think bytes12(random) will be enough for security? Possible attackers also have to brute-force/guess address of referrer/app and ?domain label with that bytes12 random to frontrun. Registration app/services could also rotate their referral contract addresses to prevent such scenarios.

B) Same as current <bytes4 APP>+<bytes4 REF>+<bytes24 random>

referral format : https://register.namesys.eth.limo?ensref=<domain.eth || bytes4(ref)>
referrer hash : bytes4(APP)+bytes4(REF)+bytes24(random) for APP+REF, || bytes4(APP)+bytes24(random) for App only mode || bytes4(0)+bytes4(REF)+bytes24(random) for official app.

  • ENS D/app Store (allow list):
    ENS DAO have to deploy an official d/app registry (?offchain? Soulbound:NON Transferrable NFT with uint32(bytes4) max supply) to list all apps managed by DAO and partners, allow d/apps to register after simple app verification by DAO/community as basic sybil protection from apes. Apps could also manage their own referral list to prevent bytes4 collision attacks.

C) wait & buidl better

Explore possible AA based ENS registration and referral systems for future.

1 Like