Escrow for digital assets: how a clean transfer works

Every sale of a high-value asset runs into the same problem: the seller wants payment before releasing the asset, and the buyer wants the asset before releasing payment. Neither position is unreasonable. In the sale of a traditional domain name, a neutral escrow agent holds both sides until the transfer clears. Onchain, the mechanism is different, and in several respects cleaner, but the underlying logic is identical.

This article explains how escrow works for an onchain TLD: what risk it removes, where it runs, and what a well-run closing looks like from both sides of the table. By the time you finish reading, you will know what to prepare before closing day, how to read the result on the public record, and where the limits of escrow lie so that your other documents can cover what it does not.

The article is written for the parties to a specific deal (buyer, seller and their lawyers) approaching a first closing. Nothing here is legal or tax advice; those questions belong to your own counsel.

The problem escrow solves

In any exchange of an asset for payment, one party must move first. If the seller moves first and delivers the asset before payment arrives, the seller carries the risk that payment never comes. If the buyer moves first and sends funds before the asset is delivered, the buyer carries the risk of non-delivery or misdirection. In practice, neither side will accept that exposure on a transaction of material value.

Traditional domain name sales resolved this by inserting a neutral escrow agent. The buyer wires funds to the agent; the agent confirms receipt; the seller then releases the transfer authorization code; the registrars execute the transfer; the agent releases the funds. The sequence is safe but slow. A transfer between registrars in the DNS can take days to clear, during which both sides are in a state of partial performance.

For an onchain TLD, which exists as a token in a wallet, governed by a smart contract on a public blockchain, a faster mechanism is available. A marketplace smart contract can settle the token and the payment together in a single atomic transaction: either both sides settle in the same block, or neither does. The “who moves first” problem collapses to a single moment rather than a sequence of several days. That is the core property that onchain escrow provides.

“Atomic” has a precise meaning here. An atomic transaction is one that the network treats as indivisible: all of its effects apply, or none do. There is no state of the chain in which the buyer has paid but has not received the token, or in which the token has moved but payment has not been made. The smart contract enforces the conditions; no person needs to stand in the middle.

This changes what the parties have to worry about, not whether they have to worry. In the traditional sequence, most of the attention goes to the days between the first step and the last. Onchain, that interval disappears, and the attention moves to the minutes before execution: is this the right token, the right price, the right wallet. The rest of this article follows that shift.

What onchain escrow is and how it removes the risk

An onchain escrow for a TLD sale works as follows. The marketplace uses a smart contract, a self-executing program on the blockchain, that deals with the TLD token on one side and the buyer’s payment on the other. The contract executes the swap only when the agreed conditions are met. Because the logic is encoded in the contract and stored on the chain, neither party can alter the terms alone once they are set.

For the seller, this means the token does not leave for the buyer’s wallet unless the payment moves in the same transaction. For the buyer, it means the funds do not reach the seller unless the token transfer executes. Neither side is exposed to the window of risk that traditional escrow was built to manage.

The result is visible to anyone. The contract address, the token identifier, the payment amount and the parties’ wallet addresses are all recorded on the public ledger. After closing, either party, and any adviser, can check on a block explorer (a public website that displays the history of a blockchain address) that the transfer happened, when it happened, and to which wallet the token moved. There is no need to take anyone’s word for it.

This is the essential difference from a traditional escrow arrangement. There, the escrow agent is a trusted third party, and that trust is a legal and reputational matter. In an atomic onchain transaction, settlement does not depend on trust in an individual: the contract’s code does the work, subject to the soundness of that contract and the security of the underlying chain. The trust has not vanished. It has moved from a person to a program and a network, both of which can be examined before the day.

If any of these terms needs a closer read, the glossary on this site defines the vocabulary used here in plain language.

Where the escrow runs: choosing the aftermarket

Onchain escrow for a TLD does not happen in a vacuum. It runs on an aftermarket: a marketplace that provides a trading layer, built on smart contracts, for tokens that already exist. The aftermarket the parties choose determines which smart contract governs the swap, which currencies are accepted for payment, and how the transaction is structured technically.

For a closing run through this desk, the default is Freename’s own aftermarket. If the client prefers another marketplace, such as OpenSea, that can be used instead, provided both parties have compatible wallets and the venue supports the token. The desk’s side of this is set out on the escrow and transfer page.

The choice of aftermarket is practical, not cosmetic. Confirm the following before the parties commit to a venue:

• The venue supports the token standard and the chain on which the TLD is recorded.
• Both parties’ wallets are compatible with the venue’s interface.
• The payment currency, whether a stablecoin or another onchain asset, is supported by the venue.
• Both parties have reviewed whatever security record is available for the venue’s smart contract, including any published audit.

None of these points is a reason to avoid onchain escrow. They are confirmation steps. A closing that skips them can meet a technical failure at the worst possible moment.

The venue should also be named in the purchase agreement, together with the chain and the payment currency. A contract that says only “by onchain escrow” leaves the parties to settle the venue under time pressure, which is when one side tends to accept an arrangement it has not examined.

What each side prepares before closing day

Preparation on both sides is what makes a closing day routine. Most closing-day problems trace back to preparation that was deferred.

The seller’s preparation

The TLD token must be in a wallet the seller controls on closing day. It should not be committed to an earlier attempt to sell, held in a wallet shared with another party, or left in the hands of an operator without clarity on who holds the key. Confirm the token’s location and the chain it sits on before any closing date is set. Check the token ID and contract address against the registry record so that the asset being sold is identified without ambiguity in the purchase agreement.

On Freename, 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. The seller should confirm that the status of this royalty program for the TLD is documented accurately. If the royalty stream is part of what the buyer is acquiring, its status needs to be disclosed in writing as part of the deal, not assumed. Escrow does not carry representations.

A seller that is a company has one more task: establishing who is authorized to act. The person who operates the wallet on closing day is not always the person entitled to dispose of a company asset. Settle the internal approval first, and record it, so that the transaction on the chain matches a decision on paper.

The buyer’s preparation

The buyer must have a receiving wallet ready, funded with the agreed payment amount in the agreed currency, and capable of holding the token. This is a more involved step than it appears and has its own section below. Beyond wallet readiness, the buyer should obtain the token ID and chain from the seller or the seller’s adviser, check them against the public registry record, and confirm that the chosen aftermarket supports that token.

What both sides agree in advance

Both sides should agree, before closing day, on the exact wallet addresses that will appear in the transaction. Addresses should be confirmed in writing, through the same documented channel that carried the negotiation, not supplied on the day in a hurried message. An address altered in transit, or mistyped, sends an asset somewhere it cannot be recalled from. Confirming addresses in advance through a documented channel, and comparing them character by character before execution, is the basic control.

Agree also on the practicalities: the time of the closing, who will be present on each side, and how the two sides will communicate while it happens. A short call during execution, with the purchase agreement open in front of both parties, removes most of the room for misunderstanding.

Closing day from the buyer’s side

The steps below describe a closing in which the aftermarket’s smart contract governs the atomic swap. The exact sequence varies by venue, but the logic is the same.

1. Check the asset on the public recordBefore confirming anything onchain, look up the TLD's token ID on a block explorer. Confirm that the holder address matches the seller's wallet address as stated in your purchase agreement. This quick check confirms the asset is where the seller says it is.
2. Compare the terms on the aftermarketOn the agreed aftermarket, confirm that the token ID, contract address, price, currency and seller address shown for the sale match what your purchase agreement records. Do not proceed if any field differs from the agreed terms.
3. Fund the receiving walletMake sure the wallet that will receive the TLD holds enough of the payment currency to complete the transaction, plus a margin for gas fees, the transaction costs charged by the blockchain network for processing. Gas fees fluctuate, so prepare a modest buffer above the agreed price.
4. Approve the payment token if requiredSome venues require a separate approval transaction before the main swap, authorizing the smart contract to move the payment amount from your wallet. Complete this step before starting the purchase. It appears as a separate transaction in your wallet interface.
5. Execute the purchase transactionConfirm the transaction in your wallet. The smart contract transfers the TLD token to your wallet and the payment to the seller's wallet in a single atomic operation. Both transfers appear in the same block.
6. Check the result on the public recordAfter the network confirms the transaction, look up your wallet address on the block explorer and confirm that the TLD token now appears there. Then look up the transaction hash to confirm that both legs of the swap are recorded in the same transaction.

A buyer who has not used an onchain marketplace before should rehearse the funding, approval and purchase steps with a small test transaction on the same chain before closing day. The mechanics are identical, and familiarity with the wallet interface reduces the likelihood of a manual error at the moment of execution.

Read what the wallet asks you to confirm. A wallet interface summarizes each transaction before you approve it: which contract is being called, which asset moves and how much. If the summary does not correspond to the purchase you expect, decline it and ask. Declining costs nothing; a confirmed transaction cannot be recalled.

Closing day from the seller’s side

The seller’s closing-day sequence is simpler in execution but requires the same level of attention.

Confirm, in the hour before closing, that the TLD token is still in the wallet you designated. If something stands in the way, such as a pending transaction, an approval left over from an earlier sale attempt, or a hardware wallet that needs to be reconnected, deal with it before the buyer begins.

The terms the aftermarket shows for the sale must be exactly those agreed: the same token, the same price, the same currency. Check them yourself against the purchase agreement before the buyer’s session begins, not during it. If anything differs, stop and correct it first.

Once the buyer executes the purchase, the swap is complete. You do not need to take any action to release the token. The smart contract handles both legs at once. You will see the payment arrive in your wallet and the TLD token leave it in the same transaction. Confirm both on the block explorer before treating the closing as complete.

If the Freename royalty program applies to the TLD, the transfer raises a practical question: how the program applies to the new holder. A Freename TLD has no annual renewal fee, but taking part in the royalty program carries an annual cost that the registry sets, and the buyer should budget for it. Some TLDs were registered under earlier terms that include the program for life, and whether those terms pass to the buyer is a point to confirm with the registry before closing, not to assume. It belongs in the handover checklist, with a named person responsible for it on each side.

Checking the result on the public record

What the swap moved is a token: Freename records a TLD onchain in that form, and a wallet holds it. Its registry record is public, so a block explorer shows it to buyer, seller, adviser or anyone else who looks. After closing, both parties should check the outcome independently.

To check the result:

• Take the transaction hash from the closing. Wallets and marketplaces show this identifier once the transaction confirms.
• Enter the hash into the block explorer for the relevant chain. The explorer shows the transaction record: the token that moved, the address it left (the seller), the address it reached (the buyer), and the payment in the other direction.
• Separately, look up the TLD by its token ID and contract address on the block explorer. The holder shown is now the buyer’s wallet address.

This is not a technical exercise reserved for developers. Block explorers are publicly accessible and require no credentials. Any adviser can perform this check without access to either party’s wallet. In the stages of a file, from mandate to transfer, this check is the last step.

Keep the transaction hash, the block number and a copy of the explorer record in the closing file. For a corporate buyer, this is the record of the acquisition that accounting, the IP function and any future counterparty will ask for.

A lawyer new to this kind of record should note what it does and does not say. It shows which wallet holds the token and how the token arrived there. It does not say who controls that wallet, or on whose behalf. The link between a wallet address and a legal person is made in the purchase agreement, which is one more reason the addresses belong in that document.

The receiving wallet: readiness of the acquiring organization

For an individual buying a TLD, wallet readiness is a matter of personal logistics. For a company, a legal team or a brand protection function, it requires planning that should begin well before closing day. An organization that leaves this step to the last week risks a delay at the moment of transfer, because the questions involved are about governance more than technology.

Several questions need answers before the wallet address is written into the purchase agreement:

Who controls the private key? A wallet’s private key, the secret credential that authorizes transactions from that wallet, must be held by the right person or function. For a corporate asset of this kind, a multisignature wallet (one that requires approval from more than one key holder to execute a transaction) is a common answer. It distributes control and avoids a single point of failure.

On which chain is the TLD recorded? Wallets are specific to a chain in practice, even when one interface supports several. Confirm that the wallet is set up for the chain on which the TLD token exists, and test it there. A mistake about the chain is the kind of error that is simple to prevent and slow to resolve.

Can the wallet display and manage the token? Not every wallet interface displays a TLD token without help. Confirm in advance that you will be able to see the token once it arrives. If the interface does not show it, the block explorer still shows where the token is, but managing the TLD (issuing names, updating records) requires an interface that recognizes it.

Is the wallet’s security adequate for an asset held for the long term? A TLD the organization intends to hold and operate for years is not a trading asset. A hardware wallet or a properly governed custody arrangement suits it better than a browser wallet connected to daily operations. Decide also who succeeds the key holders when people change roles, and write that down.

What escrow does not cover

Onchain escrow is a settlement mechanism. It is precise within its scope, and it has no reach outside that scope. Understanding its limits is part of closing well.

Each gap in the right column is a drafting task for the purchase agreement. Escrow guarantees the mechanics of the transfer; it cannot guarantee what the seller told you about the asset before you agreed to buy it.

Representations that matter in an onchain TLD sale include: that the seller is the lawful holder and knows of no competing claim; that no other transfer of the token has been started; that the royalty program status is as disclosed; that no undisclosed liabilities are attached to the namespace; and, if the holder is a company, that the seller has the authority to transfer. These points belong in any competent purchase agreement, whether closing is onchain or not.

Third-party claims deserve particular note. An onchain TLD is not part of the ICANN DNS, and the UDRP, the dispute policy that applies to domain names registered through ICANN-accredited registrars, does not reach it. Whether and how a trademark owner can challenge an onchain TLD depends on the law of the country concerned, and it varies considerably. Escrow has nothing to say about that risk. Your counsel does.

Off-chain commitments also need explicit treatment. If the deal includes a seller’s commitment to hand over an operator agreement, to pass on records of the names already issued, or to assist with configuration after the transfer, those obligations live in the purchase agreement, not in the smart contract. The atomic swap closes the transfer of the token; it does not compel any further action by either party.

Confidentiality is separate again. Every exchange with this desk is covered by a standard mutual NDA. That is a confidentiality agreement, not a purchase agreement: it creates the conditions for a safe negotiation, while the purchase agreement carries the substantive obligations. Both documents are necessary; neither substitutes for the other.

After closing

Once the token is in the buyer’s wallet and the transaction is confirmed on the public record, the transfer itself is complete. Several practical steps remain.

For the buyer, the immediate priorities are to confirm that custody of the wallet is in the right hands internally, to update the organization’s own registers of intangible assets and brand protection records, and to begin activation if the TLD is to be put to use. A TLD that is held but not used issues no names, and without registrations there is nothing for a royalty program to share. The Launch Roadmap tool on this site builds a launch plan for a newly acquired TLD.

For the seller, confirm that anything tied to the royalty program has been dealt with as agreed, and that any operator relationship, if you were running the TLD as a live namespace, is wound down or transferred in accordance with the purchase agreement.

Both parties should retain the closing record: transaction hash, block number, wallet addresses and the purchase agreement, indexed together. For corporate parties, this package is what future counsel, auditors or counterparties will request.

If a closing is still ahead of you

Start with the three documents that do the work escrow cannot: the confidentiality agreement, the purchase agreement with its representations and wallet addresses, and the handover checklist. Then fix the venue, test the receiving wallet, and rehearse.

Hush Partners is a private desk for onchain TLDs. It acts under mandate, either for a holder who wants a buyer or for an organization that wants a holder found and approached. One named partner follows a file from first note to closing, and closing runs through onchain escrow on an aftermarket, as described above. Putting the TLD to work afterwards is the subject of post-transfer activation. The desk is reached through the contact form.

Questions people ask

Does the smart contract hold the token before the swap, or does the seller keep it?

This depends on the venue. In one design, the seller authorizes the smart contract to transfer the token but keeps it in the seller’s own wallet until a buyer executes the purchase. In another, the token is deposited into the contract first, held there until the conditions are met, and then released. Both designs aim at the same protection: no payment without delivery, no delivery without payment. Confirm with the chosen aftermarket which one applies.

What currency is used to pay for a TLD in onchain escrow?

The parties agree on it, and the chosen aftermarket must support it. A stablecoin, a token designed to track the value of a national currency, limits the effect of price movements between agreement and closing. The purchase agreement should name the currency precisely, not just “cryptocurrency”. Your counsel should confirm that the currency is acceptable under the regulatory and accounting requirements that apply to you.

Can closing be undone after the transaction confirms?

No. An atomic onchain transfer is final once the network confirms it. There is no reversal and no chargeback. This finality is what makes the settlement certain, but it means that an error in a wallet address or an amount cannot be corrected after the fact. Check every address and amount before execution.

What happens if only one party is ready on closing day?

If the buyer has not funded the wallet, the transaction does not execute. The token remains with the seller and no payment has moved. Provided neither party has taken a step that commits funds, a delayed closing is recoverable: the parties set a new time and start the sequence again. The purchase agreement should include a final date for closing and a process for postponement to manage this cleanly.

Is a purchase agreement necessary if escrow is onchain?

Yes. The smart contract settles the mechanics; it does not record the representations, warranties or post-closing obligations that govern a commercial sale. A purchase agreement establishes what is being sold, including any off-chain rights or commitments, on what terms, and what remedies apply if either party fails to perform outside the transfer itself. Onchain settlement replaces the escrow agent; it does not replace the contract.