Generic Custom NFT Subdomain Controller

🌱 ENS Ecosystem ResourceRequests/Grants
1

Hi I’m hodl.pcc.eth (Sam). I’m a web3 dev, experienced with solidity and completed a number of ENS related integrations over the past 12 months. Below is a proposal of a ENS custom dapp that me and a friend will be starting working on soon.

Proposal

My proposal is to write a custom ENS controller / resolver that NFT projects can use to link NFTs in their collection to subdomains. Included in this proposal is a generic UI to enable configuration and claiming of the subdomains.

I have previously written a custom resolver for the .pcc.eth ENS domain. Which allows holders of Purrnelope’s Country Club NFTs to claim a subdomain to link to an NFT. We currently have over 800 .pcc.eth subdomains registered.

You can read more about the .pcc.eth ENS contract here

The new contract that I’m proposing would have the same functionality however it would be generic and allow any ENS domain / ERC-721 NFT contract combination to be used.

There are a lot of NFT contracts that contacted me and asked about linking subdomains in the same way that .pcc.eth have done. Despite the code being open source under a MIT licence, communities utilising this would require custom UI and a contract deployment so there is a large barrier to entry.

Benefits

  • There are lots of NFT communities that are looking for this functionality, it will massively increase subdomain usage.
  • Remove any gas costs to set avatar.
  • These subdomains will be “plug and play”. No requirement to change address after ownership transfer of NFT. This logic is dealt with in the contract.
  • More exposure on social media of NFT holders also displaying their subdomains.

Example:

  • Owner of bayc.eth configures controller to our custom controller address through ENS.app
  • Owner of bayc.eth adds the contracts allowed to register subdomains.
    • 0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D (BAYC)
    • 0x60E4d786628Fea6478F785A6d7e704777c86a7c6 (MAYC)
    • 0xba30E5F9Bb24caa003E9f2f0497Ad287FDF95623 (BAKC)
  • Holder of an eligible NFT can link a subdomain with custom label to their NFT

Notes:

  • This contract would be generic and work for any ENS top level domain and ERC-721 collection.
  • The claiming process would be free, just require an eligible NFT.
  • Holder of the NFT can remove any linked subdomain
  • The owner of the TLD can originally configure settings:
    • Allowed contracts (generally would only be a single contract)
    • Allow subdomain to be reused (if it is removed)
    • Allow numeric only (only compatible if there is a single contract)
  • The owner of the TLD can transfer to a burn address after setting up the controller / contract if the subdomains are required to be trustless.
  • The avatar record of the subdomain would automatically be set to the NFT that it’s linked to.
  • The ETH address record will directly resolve to the address that is holding the NFT, so if it is transferred then the subdomain will move with it.

Funding Request:

I will be starting work on this concept in August 2022, and anticipate that it will take around 8-10 weeks to complete the contracts and 8-10 weeks to complete the UI. This estimate includes testing and documentation. Me and a UI developer will work together and aim to complete this in October 2022.

Based on the time and effort I would request a payment of $30,000. I also believe this is a very big value add prospect for ENS subdomains.

Development of this project is not dependent on any funding, but I was advised by multiple people to apply as this will bring good value and exposure to the ENS ecosystem.

Please let me know if you have any questions or if you have any comments around the proposal.

15 Likes
2

Moving this to the Ecosystem WG.

I love the idea of having a generic system for this, what you’ve done with pcc.eth is great. Can you join an upcoming Ecosystem WG meeting to discuss it with the stewards?

5 Likes
3

Yes, I’d be happy to come on a call to discuss. Just let me know when.

2 Likes
4

Pinging @Ecosystem_Stewards to make sure they’re aware!

1 Like
5

A question:

Will the subdomain bind to the NFT it linked to? And the subdomain will be automatically transferred to the same receiver when we transferred the NFT?

A suggestion:

Maybe your partner (the UI developer guy) could adopt this project: https://thorin.ens.domains/

6

We have been in touch.

@hodl.esf.eth will be joining us on our next ecosystem call next Monday!

2 Likes
7

Yes, that’s correct. The subdomain will resolve using the ownerOf function of the erc-721 it’s attached to.

8

Hey @hodl.esf.eth thanks for your proposal! Would you be able to share a bit more about your plans for the UI side of things? Do you have any designs? Thanks.

9

Hi Leon,

I haven’t really considered detailed UI designs currently. At a high level it’s likely it’ll be 2 pages for the admin of the TLD and 2 pages for the admin of the subdomains. Probably will also include a stats page of some sort and a search page.

The UI is superficial though to the entire proposition.

1 Like
10

Hi.

An interesting proposal. Have you looked into ENSIP-10: Wildcard Resolution - ENS Documentation ? The contract will be similar to what you are doing (text and addr are dynamically fetched from the linked nft) but this eliminates the need for each subdomain owner to claim (hence gas free). The downside is that this is relatively new protocol so not all wallets support yet, but Metamask support is already merged and soon to be available.

Makoto

1 Like
11

Hi,

Yes I’ve seen this before, also I’ve seen an implementation in the wild.

I think that using wildcard resolution would add extra complexity into the contract, especially if we wanted to allow users to have free-text labels, so I’d be unlikely to be going down this path.

Also, it’s probably incompatible with primary account display on Etherscan, and people would want this to display their subdomain.

1 Like
12

Yeah, One thing I missed is that you have hashToIdMap to let the token owner to pick the subdomain name rather than using NFT’s token ID as the subdomain which is more user-friendly.

2 Likes
13

Hi, @hodl.esf.eth would it be possible to draft ENSIP (you can raise PR on https://github.com/ensdomains/docs ) so that we can have a better understanding about the architecture? We are especially keen to figure out if these contracts are compatible with Name Wrapper that has a feature to burn permission of parents so that you don’t have to transfer the parent ownership to burn address

14

At its simplest, you can use wildcard resolution simply by not setting a record for each subdomain, and implementing the resolve function to call the underlying function provided in the call data. This adds just a few lines of code, and saves users the gas required to set an owner and resolver on every subdomain.

1 Like
15

Interesting times !

Will look forward to the outcome here .

Best of luck with the project.

:+1:t2:

1 Like
16

Hi

I’m a bit confused by this request. I had a look through the git hub link you provided, I cannot see any reference to NameWrapper in the EIPs or documentation. Also, this looks like internal ENS documentation / codebase stuff.

Development on this project was started around a week ago, and I’m currently still working on high level unit tests before starting the main codebase. I’m happy to take direction regarding NameWrapper compatibility and include that instead of the ERC721 ENS token that the pcc.eth resolver uses. This is dependant on Name Wrapper being released before I’ve finished my generic controller though.

1 Like
17

Thanks Nick, that seems very useful.

Do external dapps currently support this method for resolution in both directions. Etherscan reverse resolution is very important.

1 Like
18

Hi, we don’t have ENSIP for NameWrapper yet, but you can get the general idea from the README ens-contracts/contracts/wrapper at master · ensdomains/ens-contracts · GitHub
(we should have ENSIP about NameWrapper which is a different discussion topic)

I was asking you to create a specification about the wrapper resolver contract you are going to make so that others can evaluate the compatibility with the name wrapper. We would like to avoid the situation where your contract breaks once we release the name wrapper or you end up re-implementing the feature that already exists on the name wrapper.

Hope it clarified my point.

20

The contract will not be a wrapper, and only require that the controller (owner) is set in the ENS registry for that domain. This is the same pattern as the pcc.eth contracts that I’ve linked in the original proposal.

https://etherscan.io/address/0x9b6d20f524367d7e98ed849d37fc662402dca7fb#code

I can develop the contracts to either use the name wrapper (ERC-1155) token, or the current ERC-721 ENS token. It’s not really much difference to me, would just be some small changes. Is Name Wrapper release date been confirmed now then?

And I can write an EIP if that’s what’s required, it just looks to me that they are for more ENS protocol level proposals, and this is not pitched at that level.

1 Like
21

Can you build it to work on both? Even after the release of NameWrapper, some of the names remain unwrapped staying under ERC721 contract collection (technically speaking, all .eth names remain under the ERC721 contract but the “wrapped” names will be owned by the wrapper contract).

Unfortunately not, but the whole contract is on github. We are making some minor changes after Code4rena security audit contest but that shouldn’t change how you interact with the contract much.