# How to read the public record of an onchain TLD > Anyone can look up an onchain TLD. What the record shows, how to interpret each element, and what it leaves out. Source: https://hush.partners/reading-the-public-record-of-an-onchain-tld Category: Onchain today Published by Hush Partners. --- When a brand protection team discovers that a word matching its client's name exists as an onchain TLD, the first instinct is to look it up. A block explorer loads. The page fills with hexadecimal strings, timestamps and contract addresses. Most people close the tab. That is a missed opportunity. The public record of an onchain TLD is readable. You can approach it much as you would a land register extract: a timestamped, tamper-resistant account of what exists, which address holds it, when it moved, and what has been issued beneath it. The difference from a land register is that no official explains the page to you, and the data does not annotate itself. This guide takes the record apart element by element. By the end, you will know what each field means, what you can conclude from it, and where the record's limits begin. Nothing here requires technical background. You need only be able to paste a string into a search bar and read a table. ## What a block explorer is and what it is not A block explorer is a search tool for blockchain data. You paste in a transaction reference, an address or a token identifier, and the explorer shows you what the blockchain recorded. Think of it as a public index over a ledger that can only be added to. Every entry in that ledger was, at some point, a transaction validated by the network. The explorer makes those entries searchable and puts them on a page a person can read. Every transaction, contract and balance can be looked up by anyone, but the layout assumes you already know what you are looking at. That assumption is the source of most confusion. A block explorer is not a registry portal. It does not interpret ownership for you, does not tell you whether a holder has any particular right to the name under trademark law, and does not flag conflicts with the conventional DNS. It reports what happened on the chain. That report is reliable within its scope and silent outside it. It is also not a WHOIS database. WHOIS, the lookup service for conventional domain names, was designed to carry registrant contact details, even if they are often redacted. A block explorer shows only addresses. The [glossary](/glossary) defines the terms used here if one of them is unfamiliar. One more point of orientation. An explorer is a third-party website that reads the chain and displays it. Several may exist for the same chain, and they lay out the same data differently. The data is the record. The page is one rendering of it. ## The token and its identifier What a block explorer displays for a Freename TLD is a token, recorded onchain and held in a wallet. The TLD is therefore an object on a public ledger, not only an entry in a privately held database. That object is a non-fungible token, meaning a token that is unique and cannot be substituted for any other. Two identifiers together locate it precisely. **The contract address** is the address of the smart contract (a program deployed on the chain) that governs a collection of tokens. A registry typically uses one contract for a whole collection on a given network, so many tokens share the same contract address. The registry's own documentation is the place to confirm which contract is the right one. **The token ID** is the number within that contract that corresponds to one specific token. The combination of contract address and token ID is unique on that chain. If someone tells you they hold `.yourbrand`, the public record lets you check whether the address they refer to holds the token with the correct contract address and the correct token ID. A token under a different contract address, even if the displayed name looks identical, is a different object entirely. Compare the contract address character by character. A single mismatched character leads to entirely different data. This is the most common error when reading a record in a hurry. The name you see on the page, such as `.yourbrand`, usually comes from the token's metadata: descriptive information stored on the token or linked from it. It is a label for humans. The pair of contract address and token ID is the identifier the chain itself uses, and it is the one to write down. ## The current holder as an address The holder of the token is identified by a wallet address: a long string of letters and digits, which on many chains begins with `0x`. The explorer shows this address on the token's page under a field labeled "Owner" or "Holder". Some explorers display a short label next to an address that has been publicly tagged, but most addresses carry no label. An address is derived from a cryptographic key pair. Whoever controls the private key that corresponds to the address controls the token. That may be one person, or several people together in the case of a multisignature wallet, which requires more than one key to approve a transaction. The address itself discloses nothing about the natural person or legal entity behind it. What the address does give you is a stable anchor. If the token changes hands, the owner field shows a different address. If the address you noted at your last lookup still appears at the next one, the token has not moved. For monitoring purposes, the address is the most reliable signal available. Be careful with the reverse inference. A new address in the owner field shows that the token moved. It does not show that the person changed. The same holder can move a token between two wallets of their own, and the record looks exactly the same as a sale. ## The elements of a record, field by field The table below maps the fields you will typically find on the token page of a block explorer to what each one means for an onchain TLD. Field names vary between explorer interfaces, but the underlying data is the same. | Field | What it records | How to use it | |---|---|---| | Contract address | The smart contract governing the collection on this chain | Check it against the contract the registry itself publishes before reading anything else | | Token ID | The unique number identifying this token within the contract | With the contract address, it is the precise identifier of the asset | | Owner | The wallet address that holds the token | Shows which address holds the TLD at the time of the lookup | | Creation transaction | The transaction in which the token was created | Establishes when the TLD was first recorded onchain | | Transfer history | Every address that has held the token, in order | Shows whether the TLD has changed address and how many times | | Block and timestamp | The block number and time of each event | Gives a checkable date to each change | | Token metadata | The name and any attributes stored on or linked from the token | Confirms the human-readable label, such as `.yourbrand` | Work through the table from top to bottom before drawing any conclusion. Start with the contract address. Then confirm that the token ID corresponds to the name you are looking for. Only then look at the owner field. Read in the opposite order, and you risk studying the holder and history of the wrong token with great care. ## History: the creation date and every transfer since The transfer history is often the most informative section of the record. It reads as a chronological log: the creation of the token, then each subsequent transfer, each with a transaction reference (called a hash), a sending address, a receiving address, and a timestamp taken from the block in which the transaction was included. Some explorers show the newest event first, so check the order before you read. **The creation date** is the date on which the TLD was first created as a token. Creating a token is called minting. On many chains the mint appears as a transfer from an empty address, a string of zeros, to the first holder. The mint date is when the public record begins. A TLD that has existed onchain for a long time carries a different weight in a conversation about priority than one created shortly before your lookup, though what weight it carries in law is a question for your own counsel. **Transfers** show every subsequent change of holding address. Each appears as a standard token transfer from one address to another, with a hash you can open to see the full transaction. If a TLD has moved three times since it was minted, the record shows three transfer rows after the mint. If it has never moved, the only row is the mint itself. What the history does not record is the reason for any transfer. A transfer might be a sale, a gift, a reorganization of wallets by the same person, a move to a more secure wallet, or a transfer through escrow at closing. The chain records the fact of the move. The reason sits outside the chain and is invisible to the explorer. Nor should you read a price into the history. A transfer row may show an amount alongside it, or nothing at all. Neither is a dependable account of what, if anything, was paid, because payment can be arranged in many ways that the token's page does not display. A valuation built from transfer rows alone rests on guesswork. For due diligence, a history with one mint and no subsequent transfers is the simplest record to interpret. A history with several transfers is not a warning sign in itself, but each step should be explained by the party concerned before a transaction proceeds. When a TLD is acquired through [onchain escrow and transfer](/escrow-and-transfer), the closing appears in this history as a transfer like any other. ## What has been issued beneath the TLD A TLD is the top of a namespace. Beneath it, names can be issued, such as `pay.yourbrand`, `id.yourbrand` and `team.yourbrand` under `.yourbrand`. Every name you find beneath a Freename TLD was issued by that TLD's holder, the only party able to issue names under it. A name issued under a TLD is typically recorded as its own token, with its own token ID, its own holding address and its own history. This means the TLD's page and the pages of the names beneath it are separate records. The TLD's token page will not necessarily display the names issued under it. How an explorer presents the relationship, and whether it presents it at all, depends on how the registry's contracts are built and on the explorer. In practice, the registry's own search is often the quicker way to find which names exist under a TLD. The explorer is then the place to read the record of each one. For a brand protection team, this answers a direct question: has anything been built under this namespace? A TLD with dozens of names beneath it, some pointing to wallets, some to websites, some to payment addresses, is a more complex situation than an empty namespace. The page on [what is live](/whats-live) covers the range of uses a name under a TLD can have. Read each name as you read the TLD: contract address, token ID, holding address, history. Then compare. If every name under `.yourbrand` sits at the same address as the TLD, the namespace is probably being used by its holder. If the names sit at many different addresses, they have been issued to others. That matters, because a name that is a token in someone else's wallet does not automatically move when the TLD is transferred. Names that the seller itself holds under the TLD can pass to the buyer along with it, if the two parties agree on that, while names sold to third parties stay with those third parties. Anyone preparing to acquire a TLD should count the names that exist beneath it and note where they are held, then ask what terms govern them. The registry's terms, not the explorer, answer that last question. The record of names also has a commercial side that the explorer does not display. Under Freename's royalty program, a share of each registration fee for names registered under a TLD goes to the holder of that TLD. The advertised share is up to half, and the registry's current terms and activation conditions apply. The explorer shows you that names exist. It does not show whether the program is active for that TLD or what, if anything, the holder has received. ## What the record cannot show The record is complete within its scope and blind outside it. Being clear about the boundary prevents wrong conclusions. **Identity.** The record shows addresses, not people. Connecting an address to a natural person or legal entity requires information that is not on the chain. **Intent.** The record does not explain why a TLD was created, why it was transferred, or what the holder plans to do with it. A `.yourbrand` TLD might be held by the brand itself, by an admirer of the brand, by an investor who has never heard of the brand, or by a business with the same name in another country or sector. The record is silent on all of these. **Legal rights.** Holding a token does not, in itself, confer trademark rights or any rights in the conventional DNS. The page on [trademark TLDs](/trademark-tlds) covers the relationship between an onchain TLD and a trademark in more detail. Conversely, a trademark registration does not appear in the onchain record. The two systems do not refer to each other, and trademark rules vary by country. **Agreements made outside the chain.** If the holder of a TLD has entered into a contract covering the name, such as a license, a pledge or an earlier agreement to sell, that contract does not appear on the chain. The token might sit at an address that is subject to obligations the explorer cannot see. In an acquisition, these are matters for the seller's representations in the agreement, not for the lookup. **Resolution.** Whether names under a TLD open in a given wallet, browser or application depends on those applications, not on the token record. The chain confirms the token exists. Resolution is a separate layer, and coverage is partial and changes. The pages on [names that resolve in wallets](/onchain-tld-wallets) and [websites on an onchain TLD](/onchain-tld-websites) describe that layer. **Other chains and other registries.** A lookup shows one token on one chain. It says nothing about whether the same string exists elsewhere, a point taken up in the questions at the end. ## Reading without drawing conclusions about who someone is This point deserves its own section because the pull toward identifying the person behind an address is real, and the explorer creates a false sense of being close to that answer. You can see the address. The token is right there. It is tempting to think that one more step will tell you who it is. Resist that logic for two distinct reasons. The first is accuracy. An address is a pseudonym. Everything that connects it to a person lies outside the record, and any such connection is an inference. Inferences of this kind are often built from several steps, and each step can be wrong. Two addresses that interact are not thereby the same person. A label on an explorer page is not a statement by the holder. The honest reading of an address is that it is an address. The second is legal exposure. Naming a person or organization as the holder of a TLD on the basis of an address, without sufficient foundation, creates its own risks: in correspondence, in filings, in internal reports that later circulate. The sentence "this address holds `.yourbrand`" is a statement of fact taken directly from the chain. The sentence "Company X holds `.yourbrand`" is a conclusion that requires independent support. If it is wrong, the error is yours, not the record's. There is also a practical reason. You rarely need the identity to take the next step. A holder who wishes to be reached can be approached without being named, and a holder who answers will say who they are on their own terms. The record gives you enough to decide whether an approach is worth making: the name exists, it has existed since a given date, and it has or has not moved. When documenting a lookup, record what the chain shows. Note the address. Note the date and time of your reading. Note whether the address carries a public label in the explorer interface, and describe it as a label. Stop there. ## Keeping a dated copy of the record A blockchain is built so that a confirmed block is not altered afterward. The page you read is another matter. Explorer interfaces change. Labels attached to addresses are added and removed by third parties. Token metadata can be updated where the contract permits it. The state of the chain at a given block is lasting. Your access to a readable rendering of it is not. The discipline is simple: save a copy of the record when you read it, with the date and time of your reading attached. A dated PDF or screenshot, annotated with the block number shown on the page, is sufficient for most internal purposes. If you are building a file, also save the hashes of the mint and of each transfer, as text and not only as an image. A hash is a lasting pointer into the ledger that anyone can look up again. A screenshot is a picture of a webpage. A useful note of a lookup holds a short set of items: - the chain, the contract address and the token ID - the name shown in the metadata - the holding address and any label displayed next to it - the hash and date of the mint, and of each transfer - the address of the explorer page, the date and time of the reading, and who made it Whether such a note is enough to be relied on in a dispute depends on the rules of evidence where you are, and those vary by country. Your own counsel decides what form the record should take. The chain provides a tamper-resistant ledger. Preserving what it showed on a given day, in a form others can check, is your task. One copy is a snapshot. When a TLD is the subject of a negotiation or a dispute, the record at one moment may not reflect what was true a week earlier or what will be true a week later. Repeat the lookup at regular intervals and keep each dated copy, so that a change of address is noticed when it happens and not months afterward. For a brand that wants this done as a matter of routine, [Namespace Watch](/namespace-watch) is the service of the desk that monitors the names of a brand onchain. ## From a reading to a next step Once you can read the record, the question becomes what to do with what you find. The answer depends on which side of the record you are on. If you hold a TLD, read your own record as a counterparty would. Check that the contract address, token ID and holding address in your files match what the explorer shows, and that you can explain each transfer in the history. A buyer's adviser will make the same lookup before any conversation becomes serious, and it helps to know in advance what they will see. If your organization has [received a note from the desk](/received-a-note), the record is a sensible first check. It lets you confirm, on your own and without replying to anyone, that the TLD named in the note exists and how long it has existed. If you represent a brand and have found that a name matching your client's mark exists as an onchain TLD, the record tells you which address holds it and how long the token has existed. Those two facts shape the conversation with your client. A TLD created shortly before your lookup, under a mark that has been in use for many years, is a different starting point from a TLD created long before the mark was filed. What follows from either is a legal question for counsel. Either way, begin with one lookup done properly: identify the token, read the holder and the history, note what has been issued beneath it, save a dated copy, and write down only what the chain shows. Where the reading leads to an acquisition or a sale, Hush Partners is a private desk for onchain TLDs that acts under mandate, with one named partner following a file from first note to closing. ## Questions people ask ### Does the block explorer show whether a TLD has expired? An explorer shows what the token's contract records, and a token page generally has no expiry field of the kind you would look for in a WHOIS record. On Freename, there is no annual renewal fee on a TLD, so there is no renewal date to track there. Do not carry that over to every registry: the terms of each one govern, and they are found in its documentation, not on the explorer. ### Can the same TLD string exist in more than one place? Yes. Onchain registries are separate systems, and nothing in the technology prevents the same string from being created in more than one registry, or on more than one chain. Each is an independent token with its own holder and its own history. Reading the record on one chain tells you nothing about another. A thorough review states which registry and which chain it covered, and does not claim more. ### Is the mint date the same as the date the TLD was purchased? Not necessarily. The mint date is the date the token was created onchain. Depending on the registry and on how the purchase was made, a purchase may precede the creation of the token. The mint date is where the publicly checkable record begins. If an earlier date matters to your file, the evidence for it lies outside the chain, for example in the registry's or the holder's own records. ### What if the explorer shows a label next to the address instead of the raw string? Some explorers attach readable labels to addresses that have been publicly tagged. These labels are not part of the chain record and are not authoritative. They may be wrong or out of date. Never treat one as confirmation of identity. In any formal document, record the raw address, and mention the label only as a label. ### How does this record differ from a conventional WHOIS lookup? A WHOIS record for a conventional domain name is designed to carry registrant contact details, a registrar, and creation and expiry dates, although the contact details are often redacted or replaced by a privacy service. An onchain TLD record shows the holding address, the token identifier and the transaction history, and no contact information at all. The trade-off is that the onchain history cannot be placed behind a privacy service or edited after the fact. It is public and accurate as to the state of the chain, and silent as to the person behind it.