13/Jul/2021
In our previous post, we took a brief look at The Graph Protocol and gave a couple of very basic examples for querying the ENS SubGraph. In this post, we will go over the components of ENS domains and use an example involving transferring an ENS domain to make clearer what is what. In future articles, we will look at more complicated ENS SubGraph queries.
Components of ENS
- The Registrant: Who owns the .eth domain (an ERC721 Token).
- The Controller: Who is able to set records (can be a smart contract).
- Address Record: Which wallet address is mapped to from your ENS.
- Reverse Record: Which ENS domain is mapped to your wallet address.
- Resolver: A smart contract responsible for storing and returning mappings.
Ok, so this may seem a bit confusing, but some examples will help here. unegma.eth was originally bought from a different wallet, and by transferring it to a new wallet and re-setting it up, it became more obvious how the ENS system works under the hood. Take a few minutes to get your head around the below sections and it will all make sense.
The Registrant and Address Records
Sending Ethereum based tokens to either unegma.eth or 0xEF9D542Cd93c6300b5BB755dff4033Eb0c8f8e01 will both mean that tokens appear in the same wallet (the former being easier to remember). This is only the case because some time was spent setting up records on ENS’s website (paying gas required); Feel free to send Ethereum based tokens to either of these addresses to support the writing of articles such as these!
When unegma.eth was first transferred to the new wallet, the Registrant immediately changed, as the new wallet was now the new owner. However, sending tokens here would not at this point have resulted in the new wallet receiving them; The Addresses under Records first needed to be changed to the new wallet, but this couldn’t yet be done until the Controller changed.
Controller and Address Records
Because the original wallet was still listed as the Controller, this meant that to change Address Records, they would need to be done from the previous address. This wouldn’t make sense for most use cases, but is easily solvable. The Controller was then also transferred from the original address, but this could also have be set by the new owner (the gas payer will be different).
Now that the new wallet was listed as both the Registrant and the Controller, Address Records could then be set by the new wallet to which the unegma.eth NFT had been sent. Setting the ETH Address record (to 0xEF9D542Cd93c6300b5BB755dff4033Eb0c8f8e01 was now possible, and would mean that sending tokens to unegma.eth would also land them in this wallet.
The Reverse Record
The Reverse Record may seem confusing and pointless at first (I mean, why should more gas be paid to set yet another record?) But ultimately, this record being set means that dApps can display to you your .eth name within their interfaces: would you rather, for example, UniSwap showed “Hello 0xEF.. .” or “Hello YourName.eth.” ENS is currently working to streamline this process.
Where to go from here…
There is much more that can be done with ENS, such as setting the “Content hash of a decentralised website”: this means that a user can host static html/css/images on a service such as IPFS, and then put the hash into their ENS name’s Content record. ENS aware browsers/extensions etc can then resolve these, continuing to bridge the gap between Web2.0 and Web3.0.
Thanks for reading, and please feel free to get in touch with any questions: https://unegma.com/contact
