# Privacy on a public record: what others see about your TLD > An onchain record is open to everyone. What a holder or an organization reveals by holding and using a TLD, and the habits that limit it. Source: https://hush.partners/privacy-on-a-public-record Category: Onchain today Published by Hush Partners. --- Holding an onchain TLD means holding a token on a public blockchain. The registry record is open: anyone with access to a block explorer can read it. That is not a defect in the system. It is how the system works. The useful question is not whether the record is public, but what the record actually says, what a patient observer can infer from it, and which habits make a material difference to your exposure. This article separates what is recorded from what can be inferred. It then covers what an organization may want to publish deliberately, what it is more likely to want to keep quiet, and what the people who hold names under your TLD reveal by holding them. It also sets out the habits that limit exposure and the things no habit can undo. None of this is legal advice. Your own counsel decides how these considerations apply to your situation. ## What the registry record actually contains On Freename, a TLD exists onchain as a token, and that token sits in a wallet. A block explorer, a public website that reads the blockchain, shows anyone who looks the following: - the wallet address that holds the token - the token that corresponds to the TLD string - the date and time of the transaction that created the token - every later transfer of the token from one wallet to another, each with its own date and time - the records the holder has attached to the TLD where those are written onchain, for example an address that receives payments or a content reference pointing to a website What the onchain record does not contain is the holder's name, legal entity, country or contact details. It has no field for them. The record is narrow by design: it records custody of a token, not the identity of the custodian. One distinction keeps this honest. The onchain record is not the only record. A registry, a marketplace or a wallet provider may hold account information about its users away from the chain, under its own terms and privacy policy. That information is not public in the way the chain is, but it exists, and it is governed by a contract and by the law of the relevant country rather than by the design of the blockchain. The table below separates the three categories this article works with. | Category | Examples | | --- | --- | | Recorded and visible to all | Holding address, TLD string, creation time, transfers, records set onchain | | Can be inferred | Links between addresses, rhythm of activity, payment flows, likely affiliation | | Not on the onchain record | Legal name, entity type, country, contact details, commercial intent | ## An address is not a name, and why that is only partly reassuring A wallet address is a string of characters derived from a pair of cryptographic keys. It identifies a position on the blockchain, not a person or an organization. This is what is usually called pseudonymity: the address stands in for a real-world identity, and nothing in the protocol links the two. That protection is real as far as it goes. A competitor reading the registry record sees a long string of letters and digits beside the TLD they are curious about. The record does not say who controls that string. For many purposes, that gap is sufficient. But pseudonymity is not anonymity, and the gap narrows under three conditions. First, an address may already have been used in a setting where its owner's identity was given, or may have been named in a public statement by the organization itself. From that point, everything the address has done onchain is read as the act of that owner. Second, a holder may attach identifying information to the address voluntarily: a human-readable name, a public profile, a record pointing the TLD to a website that carries the organization's name. That association is durable. Third, an address does not act alone. Its dealings with other addresses are public as well, so what becomes known about one address colors how the others are read. The practical implication is that an address connected to a known identity brings its whole history into view, past and future. The question worth asking before each onchain action is not "is this address known?" but "could this address become known, and what would follow if it did?" There is a second, quieter implication. The connection does not have to be made by you. A counterparty who knows which address is yours, because you transacted with them, knows it for good. Whether they may repeat it is a matter of contract and professional duty, not of technology. That is why the offchain side of discretion, covered further down, matters as much as the onchain side. ## What activity and timing reveal A blockchain is a timestamped record to which entries are only ever added. That structure allows a kind of inference that goes beyond reading a single entry: reading the pattern of entries over time. No single entry needs to be revealing for the pattern to say something. Three patterns matter most for TLD holders. They are described here in general terms, so that you can recognize what your own activity conveys. **Activity and timing.** The date and time of every transaction are permanent. A regular rhythm of activity is observable. So is activity that falls close to a public event such as an announcement or a product launch, which invites an observer to connect the two. **Links between addresses.** When value or tokens move between two addresses, the movement is public, and the two addresses are associated from then on. An organization that uses the same wallet to hold its TLD and to do unrelated things onchain has tied those activities together for anyone reading. This is true even if neither address has ever been publicly named. **Token transfers.** Every time a TLD changes hands, the transfer is recorded. The record shows the sending address, the receiving address and the time. It does not show the identities of the parties or the terms they agreed between themselves. Where a payment moves onchain alongside the transfer, the amount of that payment may be readable as well. None of this is unique to TLDs. It applies to any token on any public blockchain. The point is that the TLD record is not an island. It sits inside a much larger body of onchain activity, and inference travels across it. It is also worth keeping a sense of proportion. Inference produces likelihoods, not proof. An observer may guess wrongly, and a wrong guess about who holds a TLD can cause its own problems for the person guessed at. Discretion is therefore not only about hiding something true. It is about not leaving a trail that invites confident conclusions, right or wrong, about you or about the people you deal with. ## What using names for payments reveals One of the capabilities that is live is using a name under a TLD as a payment address. Rather than sharing a long wallet address, the payer enters `pay.yourbrand` and the name resolves to the address behind it. The page on [payments to a name](/onchain-tld-payments) covers this in detail. A capability of this kind depends on support in the wallet or the service the payer uses, and that support is partial. When a name is used in a real payment, the blockchain records the payment in the ordinary way: the sending address, the receiving address, the asset, the amount and the time. In general, the name is a convenience for finding the receiving address, and the ledger entry for the payment is made between addresses. A reader of the ledger sees the address the name pointed to. This has two implications. First, a name used for payments points to an address, and that address has a history that is fully public. Anyone who is given the name can see which address it resolves to. If the organization prints the name on its commercial correspondence, for example "pay us at `invoice.yourbrand`", it has publicly connected that name, and therefore that address, to itself. Everything the address has received or sent is then read as the organization's own. Second, the asset and the amount of each payment are visible. That includes payments from your customers, who may not have considered that paying a published name places their own address next to yours on a public record. Where the privacy of financial flows matters, a named payment address calls for thought about which address is put behind the name and what its history already contains. An address that has done nothing else, and is kept for that one named function, limits what the history can say. A payment name is, in short, a published account reference. Treat it as you would treat bank details printed on an invoice, with one difference: the statement for that account is open to every reader. ## What an organization may want public, and what it does not An onchain TLD can serve a range of purposes, and not all of them call for the same level of discretion. It helps to be explicit about which uses are deliberate disclosures and which are not. **What an organization typically wants to be findable.** A TLD used for customer-facing payments, for a recognizable identity in wallets, or for a publicly announced website is meant to be seen. The resolution records (the payment address, the content reference for the site) are published precisely because they need to be read. An organization choosing these uses has decided that the associated address and activity are part of its public presence. That is a reasonable decision, taken deliberately. For a brand, there is even a benefit: a record that anyone can check is harder to imitate than a claim nobody can verify. **What an organization typically does not want to be visible.** Strategic activity is different. A TLD acquired ahead of a product launch, a namespace held in reserve, a set of names issued to internal counterparties before a public announcement: these are cases where the onchain record exists before the organization is ready for the connection to be made. The holding wallet, the issuance times and the name strings are on the record from the moment they are created. An organization that issues `launch.yourbrand` well before an announcement has created a timestamp, and a telling string, that a competitor could read. **The ground in between.** Many facts are neither secret nor meant for publication: which team runs the TLD, which supplier built the site, which partners received names first. On a public record these are disclosed by default unless someone decides otherwise. The useful exercise is to list them and decide, one by one, which you are content to have read. The page on [what is live](/whats-live) documents which TLD capabilities work, with sources. The point here is not to avoid using those capabilities, but to sequence the onchain record deliberately. Issue a name when you are ready for the name to exist. Set resolution records when you are ready for them to resolve. The record is permanent. The timing of what you put on it is within your control. ## Habits that limit exposure Limiting exposure is not primarily a technical problem. It is a matter of ordinary operational habits applied consistently. None of the habits below hides anything. Each one simply avoids publishing more than the task requires. **Use dedicated addresses.** The wallet that holds your TLD should not be the wallet used for unrelated onchain activity. A dedicated custody address keeps the TLD's record from being read together with everything else you do. The same principle applies to payment addresses: a separate address for each named payment function limits how much one says about the others. **Decide when a record should start to exist.** A transaction that creates a token is permanent and timestamped. If a name string would reveal intent before you are ready, the right moment to issue it is when its existence is no longer sensitive. Once the record exists, its time is fixed. **Be deliberate about resolution records.** Setting a resolution record, such as a payment address or a content reference, publishes information. Setting records one at a time, as each capability goes live, limits what the TLD reveals at any given moment. **Apply the same discipline to everyone who approves transactions.** An organization may manage its TLD through several team members, or through a multisignature wallet (a wallet that requires more than one key to authorize a transaction). In either case, the addresses of the people who approve are involved in what happens. Consistent habits across the group matter as much as the habits of any one person. **Cover offchain exchanges with appropriate agreements.** The onchain record is one layer of information. Offchain communications are another: instructions, negotiations, the terms of a transfer. Covering those exchanges with a confidentiality agreement limits what can be disclosed from the offchain side. Exchanges with Hush Partners all fall under one [standard mutual NDA](/nda). **Review what names under your TLD say about your plans.** The names you issue, and when you issue them, are part of the public record of your TLD. An [operator running a sector TLD](/operators) as a namespace should consider whether the pattern of early names says more about commercial relationships than is appropriate. **Write the decisions down.** A habit that lives in one person's head leaves with that person. A short internal note recording which address does what, who may approve, and what must be checked before a record is set is enough to keep the discipline when the team changes. ## What cannot be undone Transactions confirmed on a public blockchain are not altered or deleted afterward. This is the property that lets anyone check the registry record on a block explorer and rely on what they read. It is the same property that makes early mistakes durable. Specifically, the time at which a token was created cannot be changed. A transfer that was made cannot be unmade, only followed by a new transfer. A resolution record that was set onchain stays in the history after it is updated or removed, because the earlier state was written at the time it was set. A name issued under your TLD and later transferred or given up still appears in the history of the namespace. It helps to separate the current state from the history. The current state can change: a TLD can move to another wallet, a record can be pointed elsewhere, a name can stop resolving. Someone who looks only at the present sees the new state. The history cannot change, and anyone who chooses to read it sees the earlier states as well. Corrections therefore work for the casual reader and not for the determined one. This sits uneasily with data protection law. Many countries give individuals rights over information that relates to them, which may include having it corrected or erased. A ledger that cannot be edited does not accommodate those rights easily, and whether an address or a name string counts as personal information depends on the country and on the circumstances. This article states the tension and does not resolve it. If you issue names to individuals, raise the question with your own counsel before the first name is issued, not after. The practical consequence is that the moment of an onchain action deserves deliberate attention. Creating a token, issuing a name, setting a resolution record and transferring a TLD are all permanent in the sense that the history of each action stays. For most organizations, this argues for doing fewer things onchain until they are ready to be seen, rather than counting on the ability to tidy the record later. ## Privacy of people who hold names under your TLD A TLD holder is not only responsible for their own onchain footprint. Every name issued under the TLD creates a record too, and on Freename the power to issue those names belongs to the holder of the TLD and to nobody else. The decision to create each record is therefore yours. When a name is issued, the public record shows the name string, the address that holds the name and the time of issuance. The person behind that address has acquired a public entry they may not fully understand. This matters for several reasons. First, the name strings themselves can carry information about the person who holds them. Someone who takes `firstname.yoursector` has disclosed something by the choice of string. Second, if the TLD matches a brand and the names go to employees, customers or partners, the set of names issued under it becomes a partial map of those relationships, readable by anyone. Third, if a name is used for payments, the history of the address behind it is public in exactly the same way as the holder's own payment activity. Organizations that issue names for internal or customer use should think through what the namespace reveals in aggregate, not only what each individual name reveals. A pattern of names issued to recognizable categories of people, whether by format or by timing, can disclose organizational structure or customer categories even when no single name is obviously identifying. ### What to settle before the first name is issued This is not an argument against issuing names. It is an argument for designing the namespace with the care that applies to any public-facing system. Three questions do most of the work: - Which name strings will you permit, and will any of them carry a person's real name, role or employer? - What will the people who receive names be told about what is public, in plain language, before they accept one? - What does the order and timing of issuance communicate about your organization? The second question is the one most often skipped. A person who is given a name under your TLD takes on a public entry and, if they use the name for payments, a public payment history. Telling them so beforehand is a matter of fairness, and in some countries it may also be a matter of legal duty. These are questions for the holder and their advisers to work through before the namespace opens. They belong in the planning that follows an acquisition, alongside the practical work of [putting a TLD to work after the transfer](/post-transfer-activation). ## Structuring your onchain presence with this in mind The distinction that runs through this article is between what you record and what you broadcast. The record is public and permanent from the moment it is created. Broadcasting is a sequence of decisions you make over time: connecting the record to your identity, pointing a name at an address, opening a namespace. An organization that treats each onchain action as a publishing decision, rather than a technical step, is in a materially better position than one that acts first and considers the implications later. A concrete next step is a one-page review with four entries: which wallet holds the TLD and what else that wallet does, which records are set and which are planned, which names exist and who holds them, and who inside the organization may approve a change. Most gaps show up as soon as those four entries are written side by side. Where a TLD is being acquired or sold, the transfer is itself an onchain event, and it becomes part of the permanent record. Discretion in that phase rests on the offchain side: who knows that a conversation is taking place, and under what obligations. When a file goes through Hush Partners, the desk never names the seller of a given TLD, every exchange is covered by the mutual NDA, and closing runs through [onchain escrow](/escrow-and-transfer) on an aftermarket. The [rules of engagement](/rules-of-engagement) set out how the desk works. For an organization at an earlier stage, the free [Namespace Exposure Score](/namespace-exposure-score) scores how exposed a brand is onchain. It is a starting point for the review above, not a substitute for it. If you have a question about a specific file, the [contact form](/contact) is the way to reach the desk. ## Questions people ask ### Does the TLD holder's legal name appear anywhere in the registry record? Not on the onchain record. That record shows a wallet address, not a legal identity, and has no place for a name, an entity type or contact details. The connection between the address and the legal entity behind it exists offchain, in the documentation the holder and their advisers keep and in whatever account information a service provider holds under its own terms. ### If I transfer a TLD to a new wallet, does the old wallet's history disappear from the record? No. The transfer adds an entry: the old address sent the token and the new address received it, at a recorded time. Both addresses stay visible in the token's transfer history. The old wallet's earlier activity is not erased. It simply stops being the current holder. ### Can I remove a name I issued under my TLD if it reveals something I would prefer not to have on the record? What is possible for a name already issued depends on the registry's rules and on who holds the name. Whatever is done next is recorded as a new action. The original transaction stays in the permanent history, with the name string, the time and the address the name went to. Changing a name's current state does not remove the evidence that it existed. ### Does attaching resolution records to my TLD change what the record reveals? Yes, materially. A TLD with no payment address and no content reference set reveals only that a wallet holds a token with a particular string. The moment you attach records, you publish the addresses or values they contain, and those stay associated with the TLD's history. Setting a record is a disclosure decision. ### Does the royalty program on Freename create additional visibility? Freename runs a royalty program under which the holder of a TLD receives a share of the registration fee for each name registered under that TLD, on the registry's current terms and activation conditions. How that share reaches the holder is set by those terms. Any part of it that arrives in a wallet as an onchain payment joins that wallet's public history, amounts included. This is not a reason to avoid the program. It is a reason to choose a receiving wallet whose history you are content to have read.