Getting a TLD acquisition through procurement

You have the agreement in principle. The brand director, the product lead or the general counsel has accepted that the organization should hold the onchain TLD that matches its name. Then the request enters the purchasing system, and the system asks for a supplier number, a tax form, an insurance certificate, a security questionnaire and three competing quotes. None of these can be supplied, because the seller is a private holder of a single asset and not a company that wants to become your supplier.

This is where an internal sponsor can lose weeks. The purchase is not refused. It is simply routed into a process built for something else, and every function answers the question it was asked instead of the question the purchase raises. Procurement sees a vendor with no record. Finance sees a payment with no invoice terms. Security sees a wallet nobody has approved. Legal sees a contract with a counterparty it cannot name yet.

This article is for the person who carries the file through those four functions. It sets out what each one will ask, which document answers it, and the order in which to collect approvals so that nothing has to be reopened. It contains no prices, because the route is the same whatever the amount.

What the purchase is, in the terms your functions use

An onchain TLD is a top-level name, such as .yourbrand, recorded on a blockchain instead of in the ICANN root. On Freename, the registry this article uses as its reference, the TLD exists as a token held in a wallet. Whoever controls that wallet is the holder, and the holder alone can issue names under the TLD, such as pay.yourbrand. That record is public, so a colleague in any function can look it up on a block explorer. These names resolve outside the DNS, so support in wallets and browsers is partial and changes over time.

For your internal file, three properties matter more than the technology.

First, it is one asset bought once. There is no subscription, no service level and no delivery schedule. On Freename there is no annual renewal fee on the TLD itself, so the purchase does not create a recurring supplier relationship with the seller.

Second, it is unique. There is one .yourbrand in a given registry. Nobody else can quote for it.

Third, it closes in a single event. Closing runs through onchain escrow on an aftermarket, so the purchase is not a delivery followed by payment on terms. How the venue you use handles that event is in its published terms.

Put those three points at the top of every document you send.

Why the vendor-onboarding form does not fit a one-off asset purchase

Vendor onboarding exists to manage an ongoing relationship. It asks whether a supplier is financially stable, insured, compliant and secure, because the organization will depend on that supplier for months or years and will send it data, access or repeat payments.

A one-off asset purchase carries none of those risks after closing. The seller will not process your data, will not connect to your systems and will not be paid again. Asking a private holder for a business continuity plan produces either silence or a refusal, and neither tells you anything about the asset.

The risks that do exist sit elsewhere. They concern the asset, not the seller’s organization: whether the seller controls the TLD, whether anything has been promised over it, whether names have already been issued under it, and whether the wallet that receives it is properly controlled on your side. The onboarding form has no field for any of them.

The answer is not to ask for an exemption from control. It is to ask for the right control. Most organizations already have a route for purchases that are not supply relationships: buying a domain name on the aftermarket, acquiring a trademark or a patent from a third party, buying a piece of real property. A TLD acquisition belongs with those. Your first task as sponsor is to get it classified that way, in writing, before anyone fills in a form.

Three counterparties, three treatments

Part of the confusion comes from treating everyone involved as one “vendor”. A TLD acquisition usually involves three kinds of party, and each deserves a different internal treatment. Separating them early removes most objections.

The intermediary is the easy one: it provides a service, sends an invoice and can complete a supplier form like any other adviser. Letting procurement run its normal process there shows that you are not avoiding the system where the system fits.

The registry and the escrow venue are the ones sponsors forget. Your organization will not negotiate a contract with them, but by holding a TLD and closing through escrow it accepts their published terms. Legal will want to read those terms, and security will want to know which accounts and which wallet touch them. Raise both at the start, not on the day of closing.

The approval file: seven documents that answer the questions

Each function approves a document, not a conversation. If you assemble the file below before the first meeting, the functions can work in parallel instead of waiting for each other.

The classification note is one page. It carries the three properties from the first section, the name of the TLD, the business purpose in two sentences, and a list of the checks that replace supplier onboarding. Everything else in the file hangs from it.

The price support memo deserves care. A unique asset has no price list, and no market gives you a row of comparable sales to cite. What you can do is set out the reasoning behind a ceiling: what the name is for, what it would cost to do without it, and how a TLD valuation is built from the properties of the string and its record. Finance does not need the memo to prove a price. It needs evidence that somebody reasoned about one before the negotiation started.

What procurement asks about a TLD seller

Procurement’s questions follow its policy, so expect them in roughly this form.

Who is the supplier?

The honest answer at the start may be that you do not know yet, and that the seller will be identified to named people under confidentiality before any agreement is signed. Offer a commitment instead of a name: no agreement and no payment until legal has the seller’s identity and has completed its screening. Procurement can approve a condition. It cannot approve a blank.

Where are the competing quotes?

There are none, and there cannot be. This is what a sole-source or single-source justification is for, and most purchasing policies provide one. State that the asset is unique in its registry, that only its holder can transfer it, and that the control against overpaying is the price support memo and an approved ceiling.

Which purchase order and which payment terms?

A purchase order with standard payment terms assumes delivery first and payment later. A closing through escrow is not a delivery followed by an invoice, so the standard terms have nothing to attach to. Ask procurement how it records other simultaneous exchanges, such as a completion payment on an asset purchase, and use the same mechanism. In many organizations the answer is a one-time record with a manual payment authorization instead of a standard order.

Is there a conflict of interest?

Expect to confirm that neither you nor anyone on the project has a personal interest in the TLD or a relationship with the seller. Give that confirmation in writing before you are asked. It costs a paragraph and removes a question that otherwise arrives late.

What legal asks before it lets the purchase proceed

Legal usually carries the longest list, and it is the function best placed to become your ally, because the checks that replace onboarding are mostly legal checks.

Confidentiality. Nothing about the project should reach a holder or an intermediary before a confidentiality agreement is in place. If your legal team insists on its own template, find out early, because a holder may have a view too. A standard mutual NDA that both sides can read in a few minutes shortens this step considerably.

The trademark position. Counsel will ask whether the organization has rights in the string, and whether buying the TLD says anything about those rights. Buying a name is a commercial choice and is not an admission that the holder had a better claim, but how that should be recorded in the agreement is for your own counsel, and trademark rules vary by country.

The seller’s identity and screening. Before signature, legal will want to know who the seller is and to run the checks its policy requires on any counterparty that receives a payment. What those checks are depends on your jurisdiction and your sector. The sponsor’s job is only to make sure the question is scheduled, with enough time, before the agreement is due.

What the seller states. The agreement records that the seller controls the TLD, has not promised it to anyone else, and discloses the names issued under it. Names the seller itself holds under the TLD can move with it if the parties agree, while names already sold to third parties stay with those third parties. Legal will want the list attached.

The registry’s terms. As the new holder, the organization accepts the registry’s terms. If the TLD takes part in the registry’s royalty program, there is a further point: some TLDs were registered under earlier terms that include the program for life, and only the registry can say whether a buyer inherits them. Ask it before closing. Put that confirmation in the file as a condition, not as an assumption.

Authority. Somebody must sign for the organization, and the delegation of authority decides who. For an unusual asset, legal may ask for a higher signatory than the amount alone would require. Ask now.

What finance asks about paying for a token

Finance has four questions, and all four can be answered without a figure in this article.

The first is the full cost. Give it as a short list of lines: the price of the TLD, the fee of any intermediary your organization mandates, the cost of legal review, and the network costs of the transfer. Then state what is absent. A Freename TLD carries no annual renewal fee, so there is no recurring line for the asset itself. If the organization later chooses to take part in the royalty program, that participation has an annual cost set by the registry, and it belongs in the operating budget of whoever runs the TLD, not in the acquisition request.

The second is the budget line and the treatment. Whether the purchase is recorded as an intangible asset or as an expense is an accounting judgment that depends on the standards your organization applies and on the facts of the purchase. Do not propose an answer in the request. Ask the question, and let your accountants and auditors decide.

The third is how the money moves. Closing runs through onchain escrow, so expect that someone in the organization, or a provider acting for it, must be able to send funds from a wallet, and confirm the accepted means of payment with the venue. If your treasury has never done that, this is the item with the longest lead time in the whole file. Open it on the first day. The detail of the paying wallet and its approvals is a treasury procedure of its own, and what matters for your file is that the route is agreed in principle before a price is.

The fourth is evidence. Auditors will ask what proves that the organization received what it paid for. The answer is strong here, and it is worth stating plainly: the transfer is recorded on a public ledger, and the registry record showing the new holding wallet can be checked on a block explorer by anyone, including the auditor. The closing and evidence plan lists what is kept: the signed agreement, the escrow terms, the transaction references for payment and transfer, and a dated copy of the registry record before and after.

One request helps finance more than any other. Ask for approval of a ceiling and a set of conditions, not of a price. A negotiation cannot return to the approval committee after each exchange, and a sponsor who has to say “I will check” at every step weakens the organization’s position. A ceiling, approved once, lets the negotiation run inside limits finance has already accepted.

What security asks about the wallet that receives the TLD

Security is the function most likely to meet the subject for the first time, and the one whose questions matter most after closing.

Which wallet receives the TLD, and who controls it? A wallet is controlled by whoever holds its keys. If the TLD is received into a wallet held by one employee, that employee is, in practice, the holder. Security will ask for a wallet controlled by the organization, typically a multisignature wallet, which needs several approvals from different people before anything moves. The custody and receiving plan names the wallet type, the approvers, their deputies and where recovery material is kept.

Can management be delegated? Not on the registry side. Management of a TLD belongs to its holder alone, and the registry offers no delegated management. Any person or tool that operates the TLD does so as the holder. That includes an AI assistant connected through Freename’s MCP server, MCP being the Model Context Protocol, a standard way to connect an assistant to an outside service: it acts as the holder. Security should treat any such connection as access to the asset and approve it, or decline it, on that basis.

What software has to be installed? Receiving and holding the TLD requires wallet software or a custody service. Testing how names resolve may require a browser extension or a supporting wallet on a test device. Ask security which devices may be used and whether an isolated machine is preferred. This is a small request that becomes a large delay if it is first raised by a helpdesk ticket.

What happens when people leave? The plan must say how an approver is replaced without moving the TLD, and who checks that the list of approvers is still right.

The order of approvals that avoids reopening the file

The common mistake is to seek approvals in the order of the organization chart: procurement first because it owns purchasing, then legal, then finance, then security. That order fails because procurement cannot classify the purchase without legal’s view, and finance cannot release funds without security’s wallet. The order below follows dependencies instead.

1. Circulate the classification noteSend the one-page note to a named person in each of the four functions on the same day. Ask each for the list of what it will need, not for approval.
2. Legal clears confidentiality and the trademark viewThe NDA template and counsel's view of the organization's rights come first, because no approach to a holder should happen without them.
3. Security approves the receiving planThe wallet, its approvers and the devices used are agreed before any negotiation. Setting up controlled custody takes longer than sponsors expect.
4. Finance approves a ceiling and a funding routeThe approval states a maximum, the budget line, the conditions for release and how funds will reach escrow. It does not state a price.
5. Procurement records the exceptionWith legal's classification and finance's ceiling in hand, procurement approves the sole-source justification and the one-off route, and onboards any intermediary as an ordinary supplier.
6. Approach and negotiation inside the ceilingOnly now does anyone speak to the holder. The seller is identified under the NDA and legal runs its counterparty checks.
7. Legal finalizes the agreementThe agreement, the list of issued names and any confirmation needed from the registry are completed. The authorized signatory signs.
8. Closing and evidenceFunds and token move through escrow. The sponsor collects the transaction references and the registry record and files them with finance.

Two features of this order are deliberate. Every internal approval that can be given without knowing the seller is given before the approach, so the organization never asks a holder to wait while a committee meets. And the final approvals are confirmations that conditions were met, not fresh decisions, which is why they can be quick.

Where a TLD file stalls, and what unblocks it

Files rarely stall on a refusal. They stall on a question nobody feels entitled to answer. The table gives the stalls a sponsor is likely to meet and the move that releases each.

The third stall is worth a paragraph. Many organizations have a treasury or risk policy that says the organization does not hold digital assets. Such policies are usually written with financial exposure in mind: tokens bought for their value. A TLD is held to be used as a name, in the way a domain name or a trademark registration is. Whether your policy covers it is a question of interpretation that only its owner can settle, and the answer may be that an exception or an amendment is needed. Ask the owner of the policy directly and early.

Some things a sponsor should never do to get past a stall. Do not split the purchase into smaller payments to stay under an approval threshold. Do not receive the TLD in a personal wallet “for now” and plan to move it later. Do not pay personally and claim it back. Do not tell the seller that approval is certain when it is not. Each of these solves a week and creates a finding that an auditor will write up, and the second one puts a corporate asset under one person’s control.

Open the internal file before you approach anyone

The most useful thing you can do after reading this is to write the classification note and send it to four named people, one in each function, with one question: what will you need from me to approve a purchase of this kind? Do it before any holder has been approached. The answers will tell you how long the route really is, and they cost nothing if the purchase never happens.

Then book the two items with the longest lead times, the receiving wallet and the funding route, and draft the sole-source justification while you wait. If your colleagues in legal want background on the subject before they answer, the page written for general counsel and brand protection teams is a short place to send them.

Where Hush Partners fits is narrow. When an organization mandates the desk to find and approach a holder, that mandate is a buy-side acquisition: a professional service for a fixed fee, charged to the organization that mandates us, and so the second row of the counterparties table above, not the first. Exchanges are covered by a mutual NDA, the stages of a file are set out in advance, and closing runs through onchain escrow. None of that replaces your internal approvals. The desk is reached through the contact form.

Questions people ask

Does the seller have to be registered as a supplier in the finance system?

That depends on how your finance system records one-off payments. Some organizations create a one-time record with a reduced set of fields, others record the payment against the asset purchase without a supplier record at all. What matters is that the method is agreed with finance and procurement before the agreement is signed.

What if the organization already has a policy for buying domain names on the aftermarket?

Use it as the starting point. It will already cover a unique asset, a private seller, escrow and the absence of competing quotes. The parts it will not cover are custody, because a DNS domain sits in a registrar account and an onchain TLD sits in a wallet, and the funding route to an onchain escrow. Add those two and most of the route exists.

Who owns the TLD internally after closing?

Decide before closing and write it in the receiving plan. Typically one function owns the business use, security or treasury controls the wallet, and legal keeps the agreement and the evidence. Putting the name to work is a separate project, covered by its own plan for post-transfer activation.