CoinMarketCap Academy

Let’s dive into what a domain is from a more technical perspective and go through the design of the name service.

What is a domain?

Everything on Solana is an account and domains are no exception. This includes wallets, programs (smart contracts), and every other bit of user and program-generated data. What this means is that everything on Solana is uniquely identifiable by a public key, and conversely, this public key can point to some data. This data can hold anything, it’s just generic binary data, although the maximum amount data of an account can hold is 10Mb. Because of this, Solana can be seen as a big permissioned key-value database, with its history being a ledger/blockchain.

So what are the keys and data of a domain? Let’s start with the data.

The data inside a domain account represents an “object” called the Name Registry. The Name Registry is made up of two elements:

The header: A fixed-length data structure (96 bytes) that contains three public keys
The data/payload: A variable-length data array that can be used to attach arbitrary information to a domain

The name registry header

The name registry header is made up of 3 public keys:

Parent name: Domain names are hierarchical. The parent name field contains the account address of the parent name, or the default zero public key (i.e 11111111111111111111111111111111) if no parent exists
Owner: The owner of this name
Class: The class of data this account represents. If set to the default public key the data class is unspecified

While parent and owner are self-explanatory, the class field can be confusing. When a class public key is specified, the associated account will be the sole required signer for every transfer and update instruction. This means that the owner signature will not be enough to transfer and update the domain.

How can this be helpful? For certain use-cases, it might be interesting to associate data to a user-controlled domain which is verified by a third-party. One example of this could be a badge system : as an organization, we grant a badge to a user’s domain which they can claim. This badge is represented by a child domain the class of which we control. It contains details about the nature of the user’s achievements on our platform. This is great for discoverability since all we have to do to get a list of a user’s badges across different applications is to fetch the children of their domain.\

At first sight, we could’ve simply owned that child domain, which would’ve granted us complete control over it. However, the real value of a class-controlled subdomain is that the class has control over the subdomain’s entire lifetime : a user can create a child domain, add arbitrary data to it, and then transfer it to us. We would then need to monitor the blockchain, actively verify and, when necessary, correct this information. But this would create an actual moment in time when the on-chain information is false. in addition to requiring us to pay fees to protect our system.

The data

The data section of the domain account can hold arbitrary binary data. Its length is not fixed and is set at domain registration. The owner of the domain can decide to store anything in this section.

💡 The data of a Solana account and the data of a domain are two different things. The Name Registry object is the data of the Name Service domain account. This Name Registry then contains a user-controlled data field, which we call domain data.

How does it apply to .sol?

Let’s have a look at a real life example: .sol domain names.

The hierarchy of the Solana name service starts with the Root domain. This domain does not have a parent and does not have a class either. The Root domain is parent to the .sol TLD. The .sol TLD is a domain itself, and all .sol domain names (e.g bonfida.sol) are “children” (or subdomains) of the .sol TLD.

Similarly, dex.bonfida.sol is a “child” (or subdomain) of bonfida.sol. Strictly speaking, the entire URL for this domain would be: dex.bonfida.sol. (the root domain’s name is conventionally an empty string). However, by common convention, the last . in a URL is omitted.

How does it apply to Twitter handles

The Twitter TLD is also a domain held by the Root domain. And registered Twitter handles are children of the Twitter TLD. Therefore, @bonfida can be interpreted as the following domain bonfida.twitter.

What else can we do with this?

As previously said, domains are hierarchical and can be used to represent anything that has a parent/child relationship. Coincidentally, SNS Optics categories also have this parent/children design:

In order to push SNS Optics categories on-chain, we have decided to use the name service and use domain names to represent the belonging of a .sol domain to a particular category.

However, it is important to understand that these domains are not .sol domain names. Each .sol domain name that is part of an SNS Optics category will have an equivalent domain that represents its belonging to a specific category. If a .sol domain belongs to multiple categories, that’s not an issue and will not create any collision. Indeed, the .sol domain will simply have multiple category domains, for instance for 00.sol :

00.99-club.categories.
00.2-digit-palindromes.categories.

Everything is a domain

สารบัญ