# Staying anonymous as a holder, from first contact to closing > Where a holder's identity can surface during a sale, and how a properly run file keeps it out of every exchange. Source: https://hush.partners/staying-anonymous-as-a-tld-holder Category: Selling Published by Hush Partners. --- Every negotiation has an information asymmetry. The party that knows more about the other side's circumstances can use that knowledge to adjust price, timing, and terms. For a holder selling an onchain TLD, the most consequential piece of information is identity itself. A buyer who knows your name, your organization, or your financial position is no longer negotiating against an asset with a market value. They are negotiating against you. This applies whether the TLD matches the name of an organization, carries a sector word, or is a single dictionary term. A motivated buyer with enough context about the seller can reframe almost any negotiation. The correct response is not to be cagey once talks have started. It is to structure the file so that identity never enters the conversation in the first place. This article follows a sale from the first signal of interest through to the public record that exists after closing. At each stage it asks what the other side can see, what they cannot see, and what keeps the line between those two things where it should be. ## Why knowing the seller changes the negotiation When a buyer learns who holds a TLD, several things change at once. If the holder is an individual, the buyer gains leverage over a person rather than a position. If the holder is an organization, the buyer can research its published accounts, its other holdings, and its strategic priorities. If the holder is known to want a sale, because their situation has been visible onchain or discussed in public, the buyer can time their approach accordingly. The effect runs in both directions. A buyer who is a large corporation may approach a holder with an offer that is calibrated to what they believe the holder would accept, not to what the asset is worth. A holder who appears well-resourced may face a buyer who simply waits, assuming time is on their side. Anonymity on the sell side breaks that dynamic. When the buyer is negotiating with a desk rather than a named person, price discovery happens on the asset. Questions about the seller's circumstances are unanswered by design. That is not an evasion. It is the structure of a professional file. The buyer evaluates the TLD, its string, its potential, and the asking price. Nothing else is available. This is also why the holder's anonymity is worth protecting consistently, not just at the opening. A holder who stays unnamed through several rounds of negotiation but whose identity surfaces when the terms are being written has lost the protection retroactively. The buyer can use what they now know to reopen settled points. ## What the blockchain record shows before a sale begins An onchain TLD on Freename is recorded as a token held in a wallet. The registry record is public, and anyone can check it on a block explorer, a public tool that reads the state of a blockchain. What they will see is a wallet address: a string of characters that identifies the holder's wallet, not the person behind it. The TLD string itself is visible. The wallet address is visible. Nothing else about the holder is written into the registry record. This differs from the registration data kept for traditional DNS domains, where a registrant's name and contact details are collected by the registrar and, depending on the registry and the country, may be published or released on request. The wallet address is therefore the first place where identity could in principle be exposed, not through the registry record itself but through the history associated with the address. If a wallet address has been used publicly in other contexts (attached to a public profile, used to receive payments from a known source, or connected to an exchange account that required identity verification), a sufficiently motivated counterparty might be able to associate it with a real person. The address is public before any sale begins, and no file structure changes that. What a [sell-side mandate](/sell-side-mandates) changes is everything around it: the holder communicates through the desk from the very first exchange, so nothing said during the sale adds a name, a reason, or a timeline to an address the buyer could already read. What a buyer legitimately knows before any approach is that the TLD exists, what string it carries, and which address holds it. That is the full scope of public information in a properly structured file. ## First contact: who speaks, and in what name The moment a holder signals that a TLD might be available, or the moment a buyer expresses interest, a line is crossed. Before that line, the holder is simply a wallet address associated with a token. After it, they are a participant in a negotiation. The question is whose name goes on that participation. In a file run through Hush Partners, one named partner manages all contact with the other side from the opening note through to closing. The holder does not communicate directly with the buyer or with the buyer's advisers at any stage. Every note, every response to a question, every counter-proposal passes through the desk. The buyer knows they are dealing with a desk. What they do not know is anything about the holder's identity, their reasons for selling, or their timeline. This structure requires discipline on the holder's side. An off-hand message sent from a personal address, a comment in a forum, or a reply to a direct approach that bypasses the desk can undo the structure immediately. A mandate only protects what passes through it: all contact flows through one channel, and that channel is the desk. The [rules of engagement](/rules-of-engagement) that govern each file also make clear what the desk will and will not disclose. The holder's name is not disclosed. The holder's reasons for selling are not disclosed. The existence of other interested parties, if any, is handled within the desk's own process and never revealed in a way that identifies the holder. ## Documents exchanged during talks: the NDA and the terms Most structured sales involve at least two sets of documents before closing: a mutual non-disclosure agreement at the start of substantive talks, and a term sheet or heads of agreement before the transfer mechanics are engaged. The mutual NDA covers both sides. It protects the buyer's identity and the holder's identity equally. Under the standard mutual NDA that covers every exchange, each side is bound to the desk, not to the other side, and the desk holds each party's information separately. The holder and the buyer never sign a document together. This means that even with the NDA in force, the buyer has no contractual right to know who the holder is. [The NDA](/nda) also defines what each party may do with information received during talks. This is relevant to the holder's anonymity in a specific way: it prevents the buyer from disclosing the existence of the negotiation to a third party who might then investigate further. A buyer who discusses their target with a competitor, a press contact, or a market tracker may inadvertently expose a negotiation that both parties intended to keep quiet. Term sheets present a more nuanced challenge, because a term sheet names the parties to the eventual agreement. Where the buyer contracts with the desk, the term sheet carries the desk as the sell-side party and the holder does not appear. If the holder is a legal entity that has to be named in a document for legal or accounting reasons of its own, the structure needs to be handled carefully: typically the entity is named as late in the process as possible, with its consent, and under the confidentiality terms already in place. Holders who have questions about how their entity structure interacts with this should take advice from their own counsel. The desk provides the framework, not legal advice. ### Supporting material is a quieter source of leaks The documents that carry signatures are not the only ones that travel. A buyer's team will often ask for supporting material: a record of names already issued under the TLD, a description of how the TLD has been used, or a history of the string. Each of these can carry traces of its author. A spreadsheet keeps the name of the person who created it. A screenshot shows an account name in a corner. A forwarded message keeps the chain beneath it. The rule that protects the holder here is simple. Nothing goes to the other side in the form in which the holder produced it. The desk restates the material in its own documents and sends only what the buyer needs to assess the asset. A holder preparing a file can help by keeping the supporting material factual and about the TLD, and by leaving out anything that describes themselves. ## The terms: who the buyer contracts with at transfer The transfer of an onchain TLD is, at its core, a transfer of a token from one wallet to another. That transfer is permanent and is recorded on the blockchain. The question for anonymity is not whether the transfer happens onchain. It does, and nothing about that will change. The question is what the surrounding contractual documents say about who the parties are. In a file closed through onchain escrow on an aftermarket, the mechanics of the transfer do not require the holder's personal identity to appear in any document that the buyer receives. The escrow, a smart contract that holds the token and the payment and releases them together, works on wallets, not on names. The TLD token moves from its current wallet to the buyer's wallet as part of the escrow release. What the buyer receives is the TLD. What they do not receive is a document that names the previous holder as a specific individual or organization. This is a structural difference from transfers of traditional domains, which pass between registrars and can require the consent of a named registrant. With an onchain TLD, the registry record simply updates to reflect the new wallet address. Buyers sometimes push for representations and warranties about ownership, title, and the absence of encumbrances. These are reasonable requests. They can be structured so that they are given by the party the buyer contracts with, without the holder's personal name appearing in a document the buyer holds. On ownership itself, the buyer does not have to rely on anyone's word: the registry record is public and can be checked on a block explorer at any point before the escrow is funded. The specific drafting is a matter for the legal teams involved. This article describes the framework, not the legal drafting. ## The stages of a file, and what the buyer sees at each The table below maps the main stages of a structured sale against what the other side has access to at each point. It assumes a file in which every exchange passes through the desk. | Stage | What the buyer can see | What remains private | |---|---|---| | Before any approach | TLD string, holding address on a block explorer | Holder's name and organization | | Opening contact | The desk and the partner who follows the file | Holder identity, reasons for selling | | NDA in force | The desk as its only counterpart | Holder identity, entity structure | | Negotiation | Asking price, TLD details, the desk's responses | Holder's floor, timeline, circumstances | | Term sheet | Agreed commercial terms, sell-side party as structured | Holder's personal name | | Escrow and transfer | The sending address, the TLD in its own wallet | Who stands behind the sending address | | After closing | Registry record showing its own wallet | Former holder's name and advisers | A deviation at any single point (a message sent directly, a forum post referencing the sale, an inadvertent disclosure by an adviser) can expose the identity the structure was designed to protect. This is why [the stages of a file](/how-it-works) are run as a single thread, followed by one partner from mandate to transfer. ## Closing: what the public record shows afterwards After a transfer completes, the blockchain record updates. Anyone checking a block explorer will see that the TLD token now sits in a different wallet. They will see the new wallet address, the transaction reference, and the point in the chain's history at which the transfer occurred. They will not see the name of the previous holder or the name of the new holder. This is the natural privacy property of an onchain transfer. The record is permanent and publicly verifiable, but it records wallet addresses, not natural persons. Whether those addresses can later be connected to real identities depends on how each party has used its wallet elsewhere, which is a matter for each party independently and is outside the scope of this article. The closing itself runs through [onchain escrow](/escrow-and-transfer) on an aftermarket. The escrow involves the two wallets and the platform that operates it, and nothing in that step asks the buyer to learn who the seller is. The platform, for its part, sees the wallets that interact with it and applies its own terms to them. Price deserves a separate word. Do not assume that the amount is invisible onchain: an escrow that settles on a public blockchain leaves a public trace of what moved. What the record does not do is explain itself. It does not say why the transfer happened, who negotiated it, or what else was agreed. The NDA covers that gap. It leaves anyone free to read the public record, and it restricts the parties from linking that record to a person, a price, or a negotiation that was disclosed in confidence. It also provides that neither side announces or comments on the transaction without the other's written consent. A new holder remains free to announce its own TLD, on its own timing, without naming the seller. ## After the sale: what the former holder carries Once the transfer is complete, the former holder's relationship with the TLD ends. They no longer hold the token. Their wallet address is visible in the transaction history as the sender of the transfer, but that address does not carry their name unless it has been publicly associated with them elsewhere. Two residual risks deserve attention. The first is advisers. If the holder used legal counsel, a financial adviser, or a tax adviser during the sale, those advisers have files that contain the holder's identity in connection with the transaction. Those files are protected by professional obligations, but they exist. A holder who wants maximum confidentiality should be explicit with their advisers about the sensitivity of the matter and ensure that file management reflects that. The second is enforcement. The confidentiality obligations do not end at closing, and they bind the buyer. If the buyer later discusses the sale with a journalist or a competitor, the recourse is contractual, and it runs through the desk, which is the party the buyer is bound to. A well-drafted NDA provides that recourse, including the possibility of asking a court to stop a disclosure. But a dispute pursued in court can itself draw attention to the transaction, and in some circumstances may require the holder to come forward. No drafting removes that trade-off entirely. The former holder's own conduct matters as much after closing as before it. A holder who mentions the sale in public, even without naming the buyer, gives anyone watching the string a reason to connect a known person to a known transfer. Silence after closing is part of the same discipline as silence during the talks. For holders with more than one TLD, this matters for a further reason: the next sale is easier to keep quiet if the previous one was. The [holders](/holders) page describes how a portfolio is sold in sequence without any buyer learning who is behind it. ## The limits: what cannot be hidden and should not be promised A professionally run file can keep a holder's identity out of every document the buyer receives and every message the buyer reads. That is a meaningful achievement and the right objective. It is not the same as a guarantee that the holder's identity can never be discovered by any means. Three limits are worth stating plainly. **Legal process.** A court order or a regulatory inquiry directed at the aftermarket platform or at the desk itself can require disclosure. Each of these parties has its own compliance obligations, and no file structure overrides them. The NDA says as much: a party may disclose information when the law or a competent authority requires it. The rules differ from one country to another, and your own counsel can tell you which apply to you. **Wallet attribution.** Blockchain transactions are permanent and publicly verifiable. If a holder's wallet address is associated with their identity through any other onchain activity (past transactions, known associations, public declarations), that association remains visible to anyone who looks. The file cannot undo it, and this article does not describe ways to obscure it. The useful question is a different one: what does the sale add to what was already visible? In a properly run file, the answer is nothing beyond the transfer itself. **The aftermarket platform.** Onchain escrow on an aftermarket requires the holder's wallet to interact with that platform's smart contracts. The platform will record the wallet address involved in the transaction. If the platform applies identity verification under its own policies or under the law that governs it, those requirements apply regardless of the structure of the broader file. Verification by a platform is not disclosure to the buyer, but it does mean that one more party holds the information. None of these limits should be concealed from a holder who is thinking carefully about what they want from a private sale. Keeping your name out of the commercial process is achievable. Unconditional invisibility is not, and a promise of it is a reason to ask harder questions of whoever makes it. ## Getting a file started without the market knowing who you are The desk is reached through the [contact](/contact) form on the site. The form asks who is writing, because the partner who reads it has to know whom they are answering. That information goes to the desk and stops there: the NDA applies from the first message, and nothing in it is shared with any counterparty. The first exchange is typically about the TLD itself: what string it carries, what the holder's broad objectives are, and whether the desk's structure fits the situation. A holder who wants to understand the value of what they hold before committing to a mandate can request a [private valuation](/private-valuation). That process is also conducted under confidentiality. The output is built on the asset: the characteristics of the string, its potential for name issuance, and the buyers it could plausibly serve. The holder's identity and circumstances are not inputs. The [valuation](/valuation) page explains how that analysis is constructed. For holders who are not certain whether they want to sell but want to understand their position, the TLD Readiness Score is a free tool that scores how prepared a TLD is to be sold. It asks nothing about who holds the TLD. It returns a score based on the asset's own characteristics. Before you write, it is worth doing one thing on your own: look at your holding address on a block explorer as a stranger would, and note what else it has touched. You do not need to act on what you find. Knowing it lets you tell the desk, at the start, what a determined buyer could already work out, and the file can be planned around that. ## Questions people ask ### Can I sell a TLD without my name ever appearing in a document the buyer holds? In most cases, yes, if the file is structured correctly from the start. The buyer's counterpart is the desk, under the NDA and through the terms. If the holder is an individual, their name does not need to appear in any document the buyer holds. If the holder is a legal entity that must be named for legal reasons, the entity can be named at the latest possible stage and under the confidentiality terms already in place. The specific structure depends on the country and the nature of the transaction, and the holder's own counsel makes that call. ### Does the buyer ever find out who held the TLD after closing? The buyer receives the TLD and can read the transaction record showing the wallet address from which it was transferred. If the buyer studies that address, what they find depends on the holder's broader onchain history. The desk cannot control what anyone reads on a public blockchain. What it can ensure is that the buyer does not receive the holder's name through any document or communication that forms part of the file, and that the NDA restricts the buyer from linking the public record to anything it learned in confidence. ### What if a buyer approaches me directly before I have a desk in place? A direct approach means the buyer has already connected you to the TLD, through your wallet's public history or through something you said in public. That part cannot be undone. What can still be protected is everything the buyer does not yet know: your reasons, your floor, your timing, and your other holdings. The way to protect it is to say nothing of substance in reply and to bring the offer into a mandate, so that the conversation continues through the desk. An inbound offer can be run as a single conversation or tested against other buyers, and the holder decides which. ### Does royalty income from a Freename TLD create a public record that could identify the holder? Freename runs a royalty program in which the holder of a TLD receives a share of each registration fee for names registered under it, advertised at up to half, subject to the registry's current terms and activation conditions. How that share is paid is set by those terms. Wherever a payment reaches a wallet onchain, the same analysis applies as for the registry record: the address is public, and the identity behind it is not, unless the holder has associated their name with that address elsewhere. ### Is an anonymous sale treated differently for tax purposes? Tax treatment depends entirely on the holder's country, the structure of the transaction, and the nature of the asset in local law. This article does not provide tax advice and cannot. A holder completing an onchain TLD sale should take advice from a qualified tax adviser before closing. The anonymity of the sale from the buyer's perspective has no bearing on the holder's own reporting obligations.