The accounting questions an acquired onchain TLD raises

When your organization acquires an onchain top-level domain, the legal and commercial teams typically move fast. The finance team moves more carefully. An onchain TLD is a string such as .yourbrand, recorded as a token held in a blockchain wallet, with no physical form and no ICANN registry behind it. It does not fit neatly into any slot on a standard chart of accounts. Auditors who have never seen one will ask questions your team may not yet have answers to.

This article works through those questions in the order a diligent controller or financial auditor would tend to ask them: what kind of asset this is, how you show you acquired it, how you show you control it, what the cost base includes, how you measure it afterward, whether any revenue flows from it, what you disclose, what internal controls the wallet requires, and what to keep on file. It gives questions and evidence, not answers, because the answers depend on the reporting framework you apply, on your country and on the facts of your acquisition.

After reading, you will know which questions to raise with your auditor before the annual close, and what documentary evidence to have ready when you do.

What kind of asset this is, and why the question is harder than it looks

An onchain TLD is recorded as a token on a public blockchain. On the Freename registry, for example, the TLD is held as a token in a wallet, and only the holder of that token can issue names under it. There is no annual renewal fee. Those features make it different from a domain name registered through a traditional registrar, which is a contract renewed period after period, and that difference matters to classification.

The starting point many finance teams reach, after working through the alternatives, is some form of intangible asset. An onchain TLD has no physical substance. It is identifiable: it is one specific string, not a pool of value. It is separable, because it can be transferred on its own. It is not cash, and it does not represent an ownership interest in a legal entity. Whether those observations are enough to settle the classification under the framework you report under is the first question to put to your auditor, and it should be put as a question.

The purpose for which you hold the TLD belongs in that conversation. An organization that acquires .yourbrand to use it for its own names, payments and websites is in a different position from one that acquires TLDs in order to resell them in the ordinary course of business. Some frameworks treat assets held for sale in the ordinary course differently from assets held for use. State your intent in writing at the date of acquisition, because intent reconstructed afterward carries less weight with an auditor.

The harder sub-questions follow immediately. Is this an intangible with a finite useful life or an indefinite one? A finite life calls for a defensible estimate of that life and a way of spreading the cost over it. An indefinite life usually moves the weight onto regular testing of the carrying amount instead. An onchain TLD has no expiry date and no renewal obligation, which points one way. It also depends on a registry and on resolution software that the holder does not control, which may point the other. Your auditor will want to see that you weighed both.

A further sub-question is whether your framework has specific guidance for digital or crypto assets, and whether a TLD falls inside or outside its scope. Where such guidance exists, it is often written with interchangeable tokens in mind, the kind where one unit is equivalent to any other. A TLD is not interchangeable: .yourbrand and .yoursector are different strings with different uses. That scoping point can decide which measurement model is available to you, so raise it at the outset and not at the year-end.

The glossary gives definitions of TLD, token, wallet and the related terms used throughout this article, which is useful when you brief an audit team that has not met them before.

Evidence of acquisition: what the transaction record needs to show

The starting point for any asset is evidence that the acquisition occurred. For an onchain TLD, the primary record is the blockchain itself: the registry record is public and anyone can check it on a block explorer, a website that displays the contents of a blockchain. The transaction hash, the unique identifier of the transfer of the token to the wallet address your organization controls, is the foundational reference.

That record alone is not sufficient for an auditor. It shows that a token moved from one address to another at a given time. It does not show who was behind either address, what was paid, or why. You need to connect the onchain record to a commercial event. That means preserving:

• The purchase agreement or order confirmation. This shows the price paid, the date, and the counterparty or the intermediary acting between you and the seller. Where the transaction closed through onchain escrow on an aftermarket, as it does when the desk closes a file, the escrow transaction record is part of this evidence chain.
• Payment records. Whether the consideration was paid in ordinary currency or in a digital asset, the outgoing payment needs to be traceable to the acquisition.
• The receiving wallet address. The transaction record shows the address that received the token. You must be able to show that this address was, at that moment, under your organization’s control.
• The date of acquisition. The date the token arrived in your wallet opens the asset’s history in your books. Where the agreement and the transfer carry different dates, note both and agree with your auditor which one governs recognition.

For organizations that mandated an intermediary to find and approach a holder, which is how a buy-side acquisition works, the engagement letter, the standard mutual NDA and any mandate confirmation form part of the acquisition record. Keep them even if they contain no pricing detail: auditors want to understand the provenance of the asset, not just its cost.

One practical point: collect this evidence at closing. A block explorer will show the transfer for as long as the chain exists, but emails, confirmations and the names of the people who approved the purchase are much harder to assemble a year later.

Evidence of control: who can act on the TLD and how you know

Control is the criterion that decides whether the asset appears on your balance sheet and not on someone else’s. For an onchain asset, control is technical before it is legal. A token is moved by whoever holds the private key of the wallet it sits in, the secret that authorizes transactions from that wallet’s address. No registry clerk checks a company register first.

Your evidence of control is therefore, at its core, evidence about keys. A bank account carries the name of its holder. A wallet address carries no name at all. The auditor has to be given a basis for concluding that the organization controls the keys, that the wallet is not a personal wallet of an employee or founder, and that nobody outside the approved group can use it.

The specific questions your auditor is likely to ask include:

• Who holds the private key, or each of the keys if the wallet is a multisignature wallet?
• Is each key held on behalf of the organization, under a written assignment, or by an individual acting in a personal capacity?
• If a third-party custodian holds the keys, what are the terms of that arrangement, and does the organization keep the economic benefit of the asset and the right to direct its use?
• Can the organization transfer the TLD without the cooperation of any party whose interests could diverge from its own?

Where a custodian is involved, no single fact tends to settle the analysis. The contract, the technical setup, the custodian’s own controls and what happens if the custodian fails all bear on it. Document the analysis in writing, with input from your legal counsel, before the first audit.

Control also has to be shown over time, not only at the date of acquisition. A change of signer, a departure, a new device or a move to a different wallet each alters the facts. A short dated record of every such change lets you show continuous control across the reporting period.

Cost and what it includes

For a purchased asset, the opening carrying amount is ordinarily built from cost. The question for an onchain TLD is which outlays belong in that cost, and the general test in most frameworks is whether an outlay was directly attributable to acquiring the asset and making it ready for its intended use. The candidates to put in front of your auditor are:

• The purchase price paid for the TLD, as reflected in the transaction record and the purchase agreement.
• Network transaction fees paid at the time of the transfer. They are typically small next to the price, but they are a real cost of the acquisition.
• The fee of an intermediary, if the acquisition was mandated. Hush Partners, for example, charges a fixed amount, never a percentage, and only to the client who mandates the desk. Whether such a fee is added to the cost of the asset or expensed is a question for your framework, often answered by analogy with adviser fees on a conventional intellectual property purchase.
• Legal and adviser fees directly attributable to due diligence on the TLD, the drafting of the purchase agreement or the escrow and transfer at closing.

Other outlays are the usual candidates for expense: internal staff time, the cost of evaluating TLDs you did not buy, costs incurred before the decision to acquire, and the later cost of operating the TLD. Frameworks differ on some of these, internal costs in particular, so do not assume.

Keep a cost build-up schedule as a working paper. It should show each component, the document that supports it, the amount and the currency. Where the price was paid in a digital asset and not in ordinary currency, the schedule also needs the exchange rate used to translate it, the source of that rate and the date and time of the transaction. Paying in a digital asset can raise a second question, which is whether giving up that asset is itself a disposal with its own gain or loss. Ask it early, because it concerns a different line of the accounts.

Subsequent measurement: the question your auditor will press hardest

Initial measurement is rarely contested. Subsequent measurement is where the real work begins, and where frameworks differ most.

Broadly, three families of answers exist, and which ones are open to you is for your auditor to say. The first carries the asset at cost and writes it down when its value to the organization has fallen below the carrying amount. The second, where a framework allows it, carries the asset at a revalued amount, usually on the condition that a market exists in which the asset trades often enough to give reliable prices. The third applies to assets with a finite useful life and spreads the cost over that life.

Each one turns into a factual question about your TLD.

If the asset is carried at cost

What would count as an indicator that the carrying amount is no longer supportable? Candidates include a loss of technical function, a decision to abandon the namespace, a rebrand that leaves .yourbrand without a purpose, or a transfer of a comparable asset at a price well below your cost. Ask also whether a write-down, once taken, can be reversed if conditions improve. Frameworks do not all answer that the same way.

If a revalued amount is considered

Is there a market that meets the framework’s test? Each TLD is a unique string. Sales are individual, often private, and not frequent. That makes the test harder to meet than it is for a token that trades continuously on exchanges. An auditor will expect a reasoned analysis before accepting any carrying amount above cost.

If a useful life is assigned

On what evidence does the estimate rest? The absence of a renewal fee and an expiry date removes the usual anchor. The estimate would have to rest on your own plans for the namespace and on your view of the registry and of the software that resolves the names.

Whatever the model, you will need a repeatable process to review the carrying amount: who performs the review, when, on what evidence, and where the conclusion is recorded. An independent view of value can serve as one input, and the page on how a TLD valuation is built describes what such a view rests on. The decision on whether an adjustment is required remains a judgment for your team and your auditor, not for a third party.

Revenue from names issued beneath the TLD

Not every organization that acquires a TLD will issue names under it to third parties. Many will use it only as an internal namespace: for payments to pay.yourbrand, for websites, for the identities of AI agents or for other operational uses. In that case there is no revenue line to account for, and the questions are limited to the asset itself.

If you do open the TLD to third parties, revenue recognition becomes a question. On Freename, the holder of a TLD receives a share of each registration fee for names registered under that TLD through the registry’s royalty program, advertised at up to half, subject to the registry’s current terms and activation conditions. Whether that share is revenue, how it is measured and when it is recognized depend on the substance of the arrangement. Is the holder providing a service to the registrant, licensing a right, or receiving a share of a sale made by the registry? On price, the position is plain: the holder of the TLD sets the price of the names issued under it, and can price one name differently from another. Who contracts with the registrant, and who owes anything after the registration? The answers are not the same in every framework, and the registry’s terms are the document your auditor will read first.

A worked example shows the scale question. Assume, purely for illustration, that names under .yoursector are registered at a fee of 20 units each, that 500 names are registered in the first year, and that the holder’s share is the advertised maximum of half. Total registration fees are 20 multiplied by 500, or 10,000 units. The holder’s share is half of that, or 5,000 units. These figures are assumptions, not a forecast. They also leave out one cost: a Freename TLD has no annual renewal fee, but taking part in the royalty program carries an annual cost set by the registry, which is not included here and must be deducted from the 5,000 units. Some TLDs were registered under earlier terms that include the program for life, so if yours was acquired from such a holder, confirm with the registry before closing whether those terms pass to you. The point is the comparison: whether 5,000 units is material next to the organization’s total revenue determines how detailed a recognition policy and how much disclosure are needed.

The subname revenue calculator can help estimate volumes for planning, but the commercial estimate and the accounting policy are separate matters. Royalty income may also become an input to your review of the carrying amount, as evidence of what the asset earns. Agree with your auditor how the two are kept consistent.

What to disclose in the notes

Guidance on what to disclose about digital assets is uneven across frameworks, and an onchain TLD is unusual enough that a reader of your accounts may not know what it is. The useful question is therefore not only what the framework requires, but what a reader needs in order to understand the holding. Discuss with your auditor whether the notes should cover:

• A description of the asset: what an onchain TLD is, which registry records it, and what rights come with holding the token.
• The accounting policy: the classification chosen, the measurement model, how and when the carrying amount is reviewed, and the revenue recognition policy if names are issued.
• The movement in the period: the carrying amount at the start and the end, additions, disposals and any write-downs.
• Custody arrangements: the type of wallet, who controls access in terms of roles, and whether a third-party custodian is involved.
• Any restriction on transfer or use, contractual or technical, including any pledge.
• The judgments and estimates involved, where the carrying amount rests on estimates and not on observable prices.

Materiality governs all of this. A TLD that is small next to the balance sheet may need no more than a line of policy. One that is individually significant among your intangibles may deserve its own line and not a place in a pooled total. Where your auditor asks for the assumptions behind a review of the carrying amount, record them in a memo: the comparable arm’s-length transfers you looked at, an income view if the TLD earns royalties, or both.

Disclosure has a security dimension that is specific to this asset. A note can describe custody by wallet type and by role without publishing the wallet address or naming keyholders. Agree the level of detail with your auditor and your security lead together.

Internal controls around the wallet

The wallet that holds the TLD behaves, in practice, like a bearer instrument. Whoever holds the keys can move the token, and if the keys are lost there is, in general, no central party who can restore access. Internal controls for the wallet are therefore not a compliance formality. They are what keeps the asset in your hands.

The steps below set out the controls an auditor will commonly expect to see documented.

1. Formalize the wallet policyWrite a wallet management policy that states the purpose of each wallet, who may initiate, approve and execute a transfer, and which approvals are required. The policy is the control. The wallet is the tool.
2. Use a multisignature walletA multisignature wallet requires approval from more than one key before a transaction goes through, for instance two keyholders out of three. That separates the authority to propose a transfer from the authority to approve it, and it means the loss of one key does not mean the loss of the asset.
3. Separate initiation from approvalThe person who can initiate a transfer should not also hold enough keys to approve it alone. Assign keys to roles, record which individual fills each role, and update the record when roles change.
4. Secure the backupsThe seed phrase, the list of words from which a private key can be regenerated, should be stored offline in a physically secure place, with access restricted to named individuals. Document where it is stored and who has access, never the phrase itself.
5. Test access periodicallyConfirm on a set schedule that the current keyholders can open and operate the wallet without relying on knowledge held by one person, who may since have left.
6. Keep a logRecord every transaction, every change to the list of approved signers and every access test. The log should be available to internal audit without access to the wallet itself.

A wallet enforces only what was configured into it. It does not know your delegation of authority, your approval limits or your board resolutions. The written policy and the log are what tie the technical setup to the organization’s own governance, and they are what an auditor can actually test.

One question to expect early: does the organization have the sole ability to transfer the TLD? If an intermediary, a custodian or any other party keeps a technical ability to move or restrict the token after closing, that fact needs to be known, may need to be disclosed and may affect the control analysis. Ask each party involved in the transaction to confirm in writing what access, if any, it retains once the transfer has closed.

The file to keep, and the questions it answers

Everything above ends in documents. This section gathers them twice: first by the question each one answers, then by where it sits in the file.

The questions and the evidence each one needs

The table maps the questions a first-year audit of an onchain TLD is likely to raise to the evidence that answers each one. Having it ready before the audit starts changes the tone of the first meeting.

The sections of the file

A well-kept file removes uncertainty, speeds the audit and, if you ever sell or license the TLD, gives a buyer’s adviser a clean trail to follow. It is not complex: a single organized folder, physical or digital, with named sections, kept from the date of acquisition.

Acquisition section. Purchase agreement or order confirmation. Transaction hash and a dated capture of the block explorer page showing the transfer. Payment records. Adviser engagement letters and mandate confirmation. A copy of the mutual NDA if one was signed. The cost build-up schedule.

Wallet and control section. Wallet management policy, dated, with its version history. Key assignments by role. The record of the multisignature configuration. The storage record for the seed phrase, meaning its location and access list. Access test logs.

Accounting section. Classification memo agreed with your auditors. Initial recognition entry and supporting calculation. Measurement policy. The review memo for each period, with its assumptions and conclusion. Revenue recognition policy and, where names are issued, the royalty statements and schedules.

Operational section. Any activation plan prepared at or after the transfer. The activation roadmap tool produces a structured version of one. Records of names issued under the TLD, if any, and any material license or use agreement. Monitoring records, if you monitor the namespace.

Disclosure section. The draft note for each reporting period, the note as published, and auditor correspondence specific to the TLD.

The file should be open to finance, legal and internal audit. Reading it should not require the keyholders to be present. If the TLD is ever moved to a new wallet, for instance during a corporate restructuring or a change of custody provider, add an entry recording that transfer, its authorization and its cost, so that the chain from acquisition to the current address has no gap.

Where to start before the next close

Start with a one-page memo. Describe the asset, state why it was acquired, list the questions in the table above and note, for each, the evidence you already hold and the evidence that is missing. Send it to your audit partner with a request for a meeting before the reporting period ends. Auditors respond far better to a question raised early with documents attached than to a new asset class discovered during fieldwork.

If the acquisition has not yet closed, build the file as you go. Ask for the closing documents you will need before the transfer, and set up the wallet and its policy before the token arrives in it.

Where the TLD is acquired through Hush Partners, the transaction closes through onchain escrow on an aftermarket, and the escrow confirmation and the transfer record are the first documents of the acquisition section. External counsel and accountants who support the file can see how the desk works with them on the page for advisers. Once the TLD is in your wallet, post-transfer activation covers putting it to work, which is also when the operational section of the file begins to fill. A finance or legal team with a question on any of this reaches the desk through the site’s contact form.

Questions people ask

Does the carrying amount need to be reviewed every year even if nothing has changed?

It depends on the classification and on your framework. Some require a periodic test for certain intangibles whether or not there is any sign of a problem. Others require one only when an indicator appears. Either way, a short dated memo each period that states the evidence considered and the conclusion is inexpensive, and it is much easier to defend than silence.

If the TLD was acquired with other assets, how is the cost allocated?

If the TLD was bought on its own, at a price set for the TLD itself, the question does not arise. If it was one element of a wider transaction that included other assets or rights, the total consideration will usually need to be split between them on a reasoned basis. Ask your auditor what basis the framework expects and whether a separate valuation of each component is warranted by the amounts involved.

What happens to the asset if the registry ceases to operate?

It is a risk to assess, not one to assume away. If the registry that records the TLD stopped operating, or the software that resolves its names lost support, the usefulness of the TLD could fall, and with it the amount you can support on the balance sheet. Whether the smart contract that records the token, the program on the blockchain that keeps the registry’s records, can be changed by its operator is a factual question your technical advisers can answer. Consider it in each review and disclose it if it is material.

Is royalty income revenue, or does it reduce the carrying amount?

Put it to your auditor as a presentation question. Income earned from an asset is ordinarily reported as income and does not reduce the asset’s carrying amount, but the label, the timing and the line it appears on depend on the substance of the royalty arrangement and on your framework.

Can the TLD be pledged as collateral?

Whether a pledge over a token held in a wallet is valid and enforceable is a legal question, and the answer varies by country. The accounting follows the legal analysis. Expect your auditor to ask whether the pledge changes who controls the asset, and expect any charge or restriction over it to be a candidate for disclosure.