How a corporate treasury pays for an onchain TLD

The budget is approved, the terms are agreed, and the file lands on the treasury desk with one unusual line: the price is paid onchain, into escrow, against a token. Nobody in the team has done that before. The payment run, the bank portal and the approved vendor file do not have a field for it.

This is less exotic than it looks. A treasurer already knows how to move a large sum once, to a counterparty the company has never paid, against delivery of an asset. The controls are the same: segregation of duties, verified payment details, a dated record. What changes is the rail, and the rail has three properties that deserve respect: a transfer cannot be recalled, the destination is a string of characters instead of a bank account with a name on it, and nobody on a help desk can stop a payment once it is sent.

This article follows the money from the approved budget to the moment escrow releases. It is written for the treasurer or the CFO office, not for the lawyers who negotiated the terms. It states no amounts and names no assets, because both depend on your deal. Tax and accounting treatment vary by country, and your own advisers decide them.

What changes for a treasurer when the rail is a blockchain

An onchain TLD is a top-level name, such as .yourbrand, recorded on a blockchain as a token that sits in a wallet. Whoever controls that wallet holds the TLD and issues the names under it, such as pay.yourbrand. Buying one means the token moves to a wallet you control and the price moves to the seller, with an escrow in between so that neither side has to go first.

A wallet is the tool that holds the keys authorizing transfers from an address. It is closer to a signing device than to a bank account: there is no bank behind it, no account officer, and no statement issued by a third party. The ledger itself is the statement, and it is public.

For a treasury team, the useful comparison is with a high-value bank wire, because that is the process you will adapt.

Two rows matter most. The destination carries no beneficiary name, so the check your bank performs for you, matching a name to an account, becomes a check you perform yourself. And there is no recall, so every control has to sit before the transfer, never after it.

Three ways to hold the paying wallet, and who signs in each

The first decision is whose wallet pays. It is a treasury decision with a legal and a security dimension, and it should be settled before anyone discusses the day of payment. There are three workable arrangements.

A company wallet with several approvers

A multisignature wallet is one that executes a transfer only when a set number of its keyholders have approved it, for instance two out of three. For a treasury this is the familiar dual-control rule, enforced by the wallet instead of by a bank portal. The company holds the keys itself, each on a separate device kept by a named person.

This is the arrangement that leaves the company fully in control and fully responsible. No provider stands behind the wallet, and nobody can restore it if the keys are lost. It requires a short written procedure: who the keyholders are, where each device is kept, how a keyholder is replaced when that person leaves, and where the recovery material is stored. If the company intends to keep the TLD in a wallet of the same kind after closing, the work is done once and serves twice.

An account with a regulated custodian

A custodian holds the keys for you and executes transfers on instructions from your authorized users, in a portal that will feel close to online banking: users, roles, limits, approval chains, an activity log. The custodian is a vendor you can onboard, review and put under contract, which many finance functions prefer for a first transaction.

The questions to settle are practical. Can the custodian send to an escrow address you nominate, or only to addresses it has screened in advance, and how long does that screening take? Does it support the network and the asset the escrow expects? What are its cut-off times and its limits for a single transfer? Ask these before the timetable is fixed, because the answers set the timetable.

An agent that pays on your behalf

In the third arrangement the company pays a law firm, a payment agent or another intermediary by ordinary bank transfer, and that party funds the escrow from its own wallet under a written mandate. The treasury team never touches a wallet for the payment.

This is the lightest path operationally, and it moves the questions somewhere else. You now have counterparty exposure to the agent between your wire and the escrow funding. The mandate must say exactly when the agent may release funds, and the audit file must connect your wire to the onchain transaction that the agent sent. Whether a given intermediary is permitted to handle funds this way depends on the rules of its country and its profession, so your counsel confirms it before the structure is chosen.

Turning a bank balance into the asset escrow expects

Expect an onchain escrow to be funded in a digital asset, not in bank money, and confirm with the venue which ones it accepts. The agreed terms should state which asset and on which network, and treasury should read that clause as carefully as it reads the currency clause of any contract. The same asset can exist on several networks, and a transfer sent on the wrong one may not arrive where escrow expects it. Confirm the pair, asset and network, in writing.

If the price is denominated in a national currency and settled in a token designed to track that currency, the conversion is close to a foreign exchange spot purchase of a small kind: you buy the token with bank money through a regulated provider and withdraw it to the paying wallet. If the price is denominated or settled in an asset whose value moves, treasury has a real exposure between the day the price is agreed and the day it is paid. The ordinary answers apply: fix the price in the currency you report in, shorten the gap between conversion and funding, or agree in the terms who carries the movement. That choice belongs in the negotiation, and treasury should be asked before the terms are final, not after.

Three operational points catch first-time payers.

The first is onboarding time. A conversion provider or custodian will run its own checks on your company before it lets you buy and withdraw anything. That is a vendor onboarding exercise with its own documents and its own calendar, and it usually takes longer than the payment itself. Start it when the acquisition is likely, not when it is signed.

The second is the bank side. Some banks ask questions about a large first transfer to a provider of digital assets. Tell your relationship manager in advance what the payment is, to whom it goes and why. A payment held for review on the day of funding is an avoidable problem.

The third is the network fee. Every onchain transfer pays a fee to the network, and that fee is paid in the network’s own asset, which is often not the asset you are transferring. A wallet that holds the full price and nothing else may be unable to send it. Keep a small working balance of the fee asset in the paying wallet, and record it as a cost of the transaction.

Mapping your payment approvals onto wallet controls

Your payment policy already says who can initiate a payment, who can approve it, and above what amount a second or third approver is required. Nothing about an onchain payment requires a new policy. It requires a mapping, written on one page, from the roles in the policy to the roles in the wallet or the custodian portal.

Start with initiation. One person prepares the transfer: destination address, asset, network, amount. That person should not be able to approve it alone. In a multisignature wallet, the person who proposes a transfer is simply one of the approvers and the wallet waits for the others. In a custodian portal, the roles are set by the administrator, and the administrator should be someone outside the payment chain.

Then approval. Each approver checks the transfer on their own device, against a source they obtained independently, and only then approves. An approver who approves because a colleague said the details were right has not performed a control. This is the same principle as call-back verification for new bank details, and it matters more here because of the missing beneficiary name.

Then the authority itself. A one-off asset purchase of this size normally rests on a specific resolution or delegation. Ask the company secretary to make sure the resolution names the transaction, the maximum amount, the fact that settlement is in a digital asset through escrow, and the officers authorized to execute it. Auditors look for that link between the board’s decision and the keys that moved the money.

The test transfer: a small payment that proves the path

A test transfer is a transfer of a trivial amount, sent before the real one, along exactly the same path. Treasurers sometimes do the same with a new bank beneficiary. Onchain it is a sensible precaution, because it turns the irreversibility of the rail from a risk into a check: if the small amount arrives where it should, the path works.

Be clear about what the test is meant to prove. It should exercise every element that the real payment will use:

• the same paying wallet, with the same approvers and devices
• the same asset on the same network
• the same destination, or a destination agreed with the escrow for testing
• the fee balance in the paying wallet
• the confirmation step, in which the receiving side states in writing that the amount arrived

Where to send the test depends on the escrow. Whether it can receive a small first transfer, or only the exact amount, is a question for the venue. Ask before sending. If the escrow cannot receive a test, send one to the company’s own receiving wallet instead. That proves your side of the path: wallet, approvers, asset, network and fee. It does not prove the destination, so the address verification described above carries that part alone.

Run the test with the people who will run the real payment, substitutes included. Keep the record of the test: the transaction reference, the time, who approved, and the confirmation of receipt. It belongs in the audit file as evidence that the control was performed.

What escrow holds, what it releases, and when

Escrow exists so that neither party delivers first: at the end, the buyer holds the token and the seller holds the price, or neither has moved. How that is achieved depends on the aftermarket on which the closing runs. This article does not describe any venue’s mechanics, and the venue’s own documentation is the reference. Treasury does not need to understand the contract code. It needs written answers to a short list of questions before it funds.

What exactly triggers release? The answer should name an observable event, such as both assets being committed, and not a person’s discretion.

What happens if the other side does not perform? You need to know how and when the funds come back, and to which address.

Is there a time limit? If the escrow expires, know the hour and the time zone, and plan funding with a margin.

Who pays which fees? Network fees and any venue fee should be allocated in the terms, so that the amount that reaches the seller matches the agreed price.

What do you receive at release? The token, in the receiving wallet you nominated. Confirm that address with the same second-channel discipline as the escrow address, because a token delivered to a wrong address is as final as a payment sent to one.

One point is worth stating to colleagues who expect a closing meeting. Do not plan on a period after release in which the payment can be suspended while documents are checked. Everything that must be verified, including the registry record of the TLD, which is public and can be checked by anyone on a block explorer, is verified before funds are committed. Legal sign-off is therefore a condition of funding, not of release. Our page on escrow and transfer describes how the desk runs this stage of a file.

If several parties are to be paid out of the price, the allocation is settled before funding as well. With a payment router such as shaka, the parties agree the split and sign it onchain ahead of any movement of funds, and the router passes the funds on without ever holding them. Whether that is used is a matter for the terms of your deal.

Funding day: a run sheet for the treasury team

By the time funding day arrives, nothing should be decided for the first time. The run sheet below assumes a company wallet with several approvers. With a custodian, the approvals happen in its portal. With an agent, the same steps apply to the agent, and your team witnesses them.

1. Confirm the conditionsLegal confirms in writing that the terms are signed, the registry record has been checked and the conditions for funding are met. Treasury does not start without that message.
2. Reconfirm the destinationThe preparer obtains the escrow address, asset, network and exact amount from the agreed source and confirms them through a second channel.
3. Check the balancesThe paying wallet holds the full amount in the right asset on the right network, plus the working balance for the network fee.
4. Prepare the transferThe preparer enters the transfer and shares the reference with the approvers, without sending the address by email.
5. Approve independentlyEach approver compares the address, asset, network and amount on their own device with the verified details, then approves.
6. Confirm receiptTreasury records the transaction reference and obtains confirmation from the escrow side, kept in writing, that the funds are committed.
7. Witness the releaseWhen the exchange completes, treasury and legal each check that the token sits in the nominated receiving wallet, and record the reference of that transaction too.

Two habits make the day uneventful. Hold a short call with everyone in the chain before the transfer is prepared, so that each person knows their step and who precedes them. And agree a stop rule: any approver who sees a detail that does not match stops the process, and nobody is asked to justify a stop. A payment that goes out a day late costs little. A payment that goes to the wrong place cannot be repaired by anyone.

The audit file: what treasury keeps and why

An auditor who has never seen an onchain payment will ask the same questions as for any large disbursement. Was it authorized? Did it go to the right party? Was it for the stated purpose? Is it recorded at the right amount, in the right period? The public ledger answers part of that, and your internal documents answer the remainder. Assemble the file as you go, because reconstructing it later means asking people to remember.

Three details make this file useful years later. First, store the transaction references as text and also keep a dated capture of each transaction as displayed by a block explorer, because the people who review the file may not know how to look one up. Second, record which address belonged to whom at the time: the ledger shows addresses, and only your file connects them to your company, the escrow and the seller’s side. Third, keep the conversion trail unbroken from the bank debit to the escrow funding, so that the amount in the general ledger can be traced to the amount onchain without a gap.

How the acquired TLD is recognized, measured and tested afterward is an accounting question that depends on the standards you report under and on your auditors’ view. Raise it with them before closing, not at year end. They will want to know what was acquired, what rights it carries and what was paid, and the file above gives them the third of those.

Where a treasurer should expect friction

It is fair to say that, for the payment itself, the banking system is the better tool in several respects. A wire carries a beneficiary name, passes through institutions that can sometimes stop or recall it, and fits the systems every finance team already runs. An onchain transfer offers none of that. Its advantages lie elsewhere: the closing runs through escrow so that neither side delivers first, the record is public and lasting, and a transfer does not wait for banking hours.

Expect friction at three points.

Internal systems. Your treasury management system and your accounting system may have no native way to record a wallet or an onchain transaction. Most companies handle a single purchase with manual entries supported by the audit file. That is acceptable for one transaction and should be agreed with the controller beforehand.

Policy gaps. An investment policy or a treasury policy may forbid holding digital assets, having been written with speculation in mind. Holding an asset for a few hours to settle a purchase is a different thing, but the policy may not say so. Obtain a written exception or an amendment before the conversion, not a retrospective approval.

Compliance checks. The seller’s side and the venue may need to identify your company, and your own compliance function may want to screen the counterparty and the addresses involved. When a seller’s identity is confidential at the start, agree with your counsel how and when these checks are completed before any funds move. Plan time for it.

None of these is a reason to avoid the transaction. Each is a reason to start treasury’s preparation when the acquisition becomes probable, in parallel with the negotiation.

What to settle before the terms are signed

The most useful thing a treasurer can do is to get into the file early. Ask the deal team for the draft settlement clause and check five items against what you can actually execute: the asset, the network, the paying arrangement, the party who carries any price movement, and the allocation of fees. If one of them does not fit your controls, it is far easier to change in a draft than after signature.

Then write the one-page mapping between your payment policy and the wallet or custodian roles, start the onboarding of any provider you need, and put a test transfer on the calendar. If your company wants background first, the glossary defines the terms used here, and what is live sets out what onchain TLDs can and cannot do, including payments to a name once the TLD is in your wallet.

Where Hush Partners comes in is before the payment. An organization can mandate us to find and approach a holder through a buy-side acquisition, the exchanges on a file sit under a mutual NDA in standard form, and closing runs through onchain escrow on an aftermarket. The page on how a file proceeds shows where the payment sits among the other stages. Questions about a specific situation go through the contact form.

Questions people ask

Can the price simply be paid by bank transfer?

Closing runs through onchain escrow, so expect the price to have to be onchain at that moment, and confirm it with the venue. A company that wants to pay only by bank transfer can use an agent that funds the escrow on its behalf under a written mandate, if the rules that apply to that agent allow it. The company then carries exposure to the agent for the time in between.

What if the transfer is sent and escrow does not complete?

That depends on the escrow’s terms, which is why treasury asks for them in writing before funding. The point of an escrow is that funds which are not released to the seller come back to the payer. Confirm how, when, to which address and at whose cost.

Is there a recurring payment after closing?

Not for holding the TLD: a Freename TLD carries no annual renewal fee. Taking part in the registry’s royalty program does have an annual cost set by the registry, and some TLDs were registered under earlier terms that include the program for life. Whether a buyer inherits those terms is a question to put to the registry before closing. Budget for the program only if the company intends to take part.