ERC-4834: Hierarchical Domains Standard

GitHub Issue

Would you mind removing the EIP text from this discussion thread? It’s unnecessary pain for you to have to keep it in sync with the PR.


Would it make sense to split the resolver interface from the management interface? I can imagine some use cases that would use a completely different management system but could still benefit from the resolver interface. For example, 4553.some-nft could always resolve to the owner of Some NFT #4553.


In canPointSubdomain, is the point to prevent yourself being added as a subdomain to a parent you don’t want? If so, what’s to stop a malicious parent just skipping this check?

  1. The EIP text is removed.
  2. I guess that’s certainly an option. I might do that.
  3. That’s a good question. I once thought of a use-case, but I can’t remember what it is. You’re absolutely right that a malicious parent can circumvent that – maybe I should replace it with an isValidSubdomain that when returns false reverts the name resolution.

Could maybe have the querier pass in the parent address to getDomain?

If I were to go that route, I would much prefer it to be in hasDomain. However, I don’t really see any point in canPointSubdomain anymore – I might just remove it. I don’t see any issues with people pointing other peoples’ domains to their own. After all, would the owner of a token care if I set myfavoritetoken.pandapip1.sometld to their token? Even if it was theworldsworsttoken.pandapip1.sometld, I’m not sure the extra complexity in the spec is worth it.

I’m just going to remove it, and maybe add it as an optional extension.

@Pandapip1 This ERC is going to be greatly useful, kudos!

Two pieces of feedback for its last call

  1. Shall we move the “Here is a solidity function that resolves a name:” to the reference implementation instead of spec section?
  2. Shall we change all the “must”, “shall” to their upper-case counter part (MUST, SHALL) so to follow RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words which suggest using uppercase to reduce ambiguity

Definitely #2. I also mostly support #1.