-
Notifications
You must be signed in to change notification settings - Fork 2
Terminology
New terminology (beyond the official ENS glossary) has been needed in the course of building the ENS Multichain Indexer. The following should be understood as a draft that is open to community feedback. Each definition below aims to maximize alignment with the official ENS glossary where possible.
Any data structure outside of the Registry that manages supplemental state for a set of subnames. Each name is associated with at least 1 subregistry (through the Name Wrapper) and may optionally be associated with multiple subregistries. When a name is associated with multiple subregistries, this means that the full state of a name must be combined across the Registry and each associated subregistry. For example, the state of all direct subnames of .eth is distributed across the Registry and two subregistries: the BaseRegistrar and the Name Wrapper. The ENS protocol does not currently define standards for subregistries. Subregistries currently exist outside the scope of the ENS protocol. For example, subregistries could live on L1, on L2s, or offchain (in a database or even in a Google Sheet). The ENS protocol currently provides no standardized mechanism to discover subregistries or to interact with subregistries.
Some specific implementations of subregistries include:
- The BaseRegistrar that holds supplemental state for direct subnames of .eth. This includes state for ERC721 NFTs and expiry times.
- The NameWrapper, which serves as a subregistry for the entire ENS root (all ENS names). This includes state for ERC1155 NFTs, expiry times, and fuses.
- Note how direct subnames of .eth are an example of multiple subregistries potentially holding supplemental state for a name outside the Registry.
- The contracts on Base that manage supplemental state for direct subnames of base.eth.
- The contracts on Linea that manage supplemental state for direct subnames of linea.eth.
- The contracts on Base / Optimism that manage supplemental state for DNS names managed by 3DNS.
- The offchain databases that manage supplemental state for direct subnames of uni.eth.
- The offchain databases that manage supplemental state for direct subnames of cb.id.
- DNS nameservers for (essentially) all DNS names. Since ENS is a superset of DNS, (essentially) any DNS name is an ENS name. Therefore, whenever supplemental state associated with a DNS name is updated in a DNS nameserver, a subregistry is being updated.
Any system that is a Registrar or that writes to a subregistry.
This definition expands the definition of Registrar to include cases such as:
- The ETHRegistrarController that writes to BaseRegistrar (the owner of the "eth" TLD). Note how the definition of "Registrar" in the official ENS glossary only includes contracts that are pointed to by the owner field of the Registry. Therefore, the BaseRegistrar is a Registrar (and a Subregistry), while the ETHRegistrarController is a Subregistrar.
- The contracts on Base that write to the Subregistry for direct subnames of base.eth. These contracts live on Base, therefore they cannot meet the definition of Registrar because they can't be set as the owner in the Registry on Ethereum mainnet.
- The offchain systems that write to the offchain databases associated with direct subnames of uni.eth and cb.id.
- Any NFT marketplace that supports the exchange of an NFT representing ownership of an ENS name. Each time a NFT is exchanged, state about that NFT must be updated within a related subregistry. Therefore the marketplace enabling that trade is a Subregistrar.
- Any DNS registrar, as ENS is a superset of DNS.
A Subregistry meeting ALL of the following constraints:
- Not the Registry;
- Implemented as a smart contract exposing the same interface as the Registry;
- Used as part of the source of truth for a CCIP-Read Gateway Server for ENSIP-10 (wildcard resolution) powered subnames.
A specific implementation of a Shadow Registry can be found in this contract storing a subset of the state of base.eth subnames on Base.