Tokens, wallets and keys: what a lawyer needs to know

A client hands you a transaction document. The subject of the deal is described as “a token held in a wallet.” The representation and warranty clause asks your client to confirm that they hold the private keys. You know what the asset does commercially, but the vocabulary sits just outside your fluency, and there is no time to become a cryptographer.

This article gives you that vocabulary, precisely enough to be useful. Each term is defined once, then connected to the legal question it raises. By the end, you will be able to read a transaction document for a digital asset, identify the provisions that carry real risk, and ask the right questions of the technical adviser on the other side.

The asset used throughout is an onchain top-level domain (TLD): a namespace string such as .yourbrand or .yoursector recorded as a token on a public blockchain. The principles apply to most tokens that represent a unique asset, but the TLD is concrete enough to keep the analysis grounded. Nothing here characterizes a token under the law of any country. That is a question for your own analysis, and the answer varies by jurisdiction.

What is actually recorded when a TLD is a token

A blockchain is a distributed ledger: a database replicated across many computers that agree, through a defined protocol, on a single authoritative state. When a TLD is created as a token on that ledger, the ledger records one entry: this token identifier is associated with this address. Nothing more and nothing less.

The entry is short, and the asset it stands for is defined elsewhere, in the rules of the registry that issued the token. On the Freename registry, for example, a TLD exists onchain as a token that sits in a wallet, and issuing names under that TLD is reserved to whoever holds it. The token is therefore the handle on the namespace: the address that holds it can issue names such as pay.yourbrand, and can send the TLD itself to another address.

The token record does not contain the word “owner.” It contains an address. The legal consequences of holding that address (whether the holder has property rights, contractual rights or something else) are determined by the law of the relevant jurisdiction and, in transactions, by the contract. The blockchain is indifferent to those questions. It will execute a transfer instruction from anyone who holds the correct key, whatever a court might later say about who should have been permitted to give that instruction.

It also helps to list what the record leaves out. It carries no trademark right, no contract term, no statement of the price paid and no note of any promise the holder made to a third party. Where the registry charges no annual renewal fee, as is the case for a Freename TLD, the record does not lapse for want of payment either, so there is no renewal date to diarize and no expiry that would return the asset to a pool. The entry simply persists until the key that controls it moves it.

That indifference is not a flaw. It is the architecture. Your job, as counsel, is to build the legal structure that sits on top of it.

What a wallet is, and what it is not

The word “wallet” is almost always misunderstood on first contact. It does not store tokens. Tokens live on the blockchain, and the blockchain is not inside any device or application.

A wallet is software, or a small hardware device, that stores keys and uses them to prepare and authorize transactions. It shows the holder what the ledger records at their address and lets them act on it. The distinction matters: if a wallet application is deleted, the tokens recorded at that address are unaffected. They remain there, within reach of whoever can produce the correct private key.

A wallet address is a public identifier, derived mathematically from the corresponding key pair. It functions like an account number: you can see it, send assets to it, and look up its history on a block explorer. Knowing an address tells you nothing about who controls it, because the private key that controls it is never exposed. The address is public. The key is not.

Wallets fall into two broad categories: self-custody wallets (also called non-custodial) and hosted wallets. In a self-custody wallet, the private key stays on the holder’s own device or storage. In a hosted wallet, a third party such as a custody provider holds the key on the holder’s behalf. That distinction maps directly onto control: in a hosted arrangement, the holder’s access to the asset depends on a contract with the custodian. Due diligence on an acquisition must establish which type is in use before representations about key control mean anything.

When the word appears in a document, three questions follow. Does “the wallet” mean an address, a piece of software or a device? Who can operate it day to day? And is the address named in the document the same one the public record shows as holding the TLD? A definition clause that answers all three removes most of the ambiguity before negotiation starts.

Keys: the anatomy of control

A private key is a very long, randomly generated number, usually displayed as a string of letters and digits. It is the secret that authorizes any transaction made from the address it belongs to.

Every address rests on a pair of keys: a public key and a private key. The public key, or an address derived from it, is the identifier anyone can see. The private key is the authorization credential. Whoever has access to the private key controls what the address holds, which in the context of a TLD means the namespace. The key is not a password that can be reset. It is the credential itself. Losing it, or allowing a third party to copy it, has permanent consequences.

In practice, a private key is rarely handled as a string of characters. Most wallet software generates a seed phrase, a sequence of ordinary words from which the private key can be reconstructed. The seed phrase is the human-legible version of the key. Whoever holds the seed phrase holds the key. A representation that a seller “holds the private keys” should, in a well-drafted document, extend to the seed phrase and to any hardware device on which the key is stored.

A signature, in this vocabulary, is the output a wallet produces when the private key approves a transaction. The network checks it against the public key and, if it matches, executes the instruction. No name, no corporate authority and no power of attorney is examined at that point. Control, in other words, is not registered anywhere. It is exercised by whoever can produce a valid authorization. Your contract needs to capture that reality.

A key can also be copied without leaving a trace. A seed phrase that was photographed, typed into a document or shared with a former service provider still works, and nothing on the ledger shows that a second copy exists. This is why a representation about keys has two halves: that the party holds the key, and that nobody else does.

Ownership against control: why they diverge

In most legal systems, ownership of property is a conclusion of law. A court can declare who owns something. A blockchain cannot. It responds to the key, not to a judgment.

This creates a gap that every transaction document must address. Consider a mid-sized manufacturer, an invented one, that acquires an onchain TLD for its brand. The deal closes, the token is transferred to the buyer’s address, and the registry record reflects the new address. Under the agreement, the TLD is the buyer’s. But if, some months later, the buyer’s IT team replaces a device without carrying the key across and loses access, the buyer has its rights under the agreement and no practical control. Conversely, if the address the token was sent to had been set up by an outside contractor who kept a copy of its seed phrase, that contractor would have practical control of an asset to which it has no claim. Neither the blockchain nor the registry will alert anyone to the discrepancy.

These are not scenarios invented to alarm. They are direct consequences of the architecture, and they can arise in any onchain asset transaction. Documents address them through representations, warranties and covenants about key management, but only if the drafting party understands that the problem exists.

A useful habit is to read every clause about the asset twice. The first reading asks who is entitled. The second asks who is able. Where the two answers differ, or where the document is silent on the second, there is a provision to add. The same double reading applies after closing, to the buyer’s own internal arrangements.

For background on what an onchain TLD can do once control is properly established, the page listing what works with onchain TLDs is a useful reference.

Transfer: what changes on the ledger and what does not

When an onchain TLD is transferred, one thing happens: the ledger’s record of which address holds the token is updated. The old address disappears from the current state and stays visible in the history. The new address becomes the only one that can act on the token.

That write is permanent. A public blockchain has no undo function and no cancellation window. If the transaction was signed with the private key, the network treats it as valid, regardless of whether the signer was permitted to transfer under any applicable contract or law. Whether a given registry’s own contract reserves any administrative power over tokens is a point to check in that registry’s terms, not one to assume.

What the transfer does not change: any legal obligation the transferring party has under a separate agreement, any trademark rights that run alongside the TLD, and any names issued under the TLD before the transfer. Those matters follow from contract and law, not from the ledger update.

Because neither side wants to perform first, a transfer of value is commonly run through onchain escrow. In general terms, a smart contract (a program stored on the blockchain that executes as written) holds the token and the payment and releases each to the other party only when both are present. That removes the settlement risk that arises if either step is taken unilaterally. The mechanics are worth specifying in the purchase agreement, not left to be agreed at closing.

After the transfer, the new holder still has work to do before the TLD is in use: deciding which names to issue, where they point and who inside the organization may act. That phase is separate from the legal transfer and should be addressed in the timeline provisions of the agreement. The service page on post-transfer activation describes that phase.

What the public record proves and what it does not

Every transaction on a public blockchain is visible to anyone. A block explorer, a public website that reads the blockchain, will show, for any token, the address that holds it, the full history of transfers, and the time and transaction identifier of each event. That record is the closest thing to a title register that onchain assets have.

The public record proves which address holds the token, when each transfer occurred, and the sequence of addresses that have held it. It does not prove who controls the holding address, whether the person who gave a transfer instruction was authorized under any legal agreement, or whether the address corresponds to any particular legal entity.

A transaction shows which address authorized it, never which person stood behind that address. Connecting an address to an identified legal person is a task for the transaction documents, not for the ledger.

For due diligence on an acquisition, this means the block explorer gives you the chain of custody (address to address) but not the chain of title (person to person). You need both. The first you can read yourself, without asking anyone’s permission and without alerting the holder. The second comes from the seller: corporate records, the documents by which earlier holders passed the asset on, and representations that tie the seller to the address by its exact characters.

The record also has a practical use during the deal. An address written into the agreement can be compared, character by character, with the one the explorer shows as holding the TLD. After closing, the same lookup confirms that the token sits at the buyer’s designated address. Neither check requires trust in the counterparty. The glossary on this site sets out the relevant terms as they are used in onchain TLD transactions.

Several signers: multisignature arrangements

A multisignature wallet (commonly called a multisig) is an arrangement in which more than one private key must approve a transaction before it is executed. It is usually a smart contract that holds the asset and acts only when the required number of signers have approved.

Configurations are expressed as “M of N”: two of three signers must approve, three of five, and so on. No single signer can move the asset alone, and the loss of one key does not lock the asset as long as the threshold can still be met.

For a corporate holder, a multisig is good governance: it mirrors the authorization controls that exist in conventional treasury management, prevents a single employee from transferring a valuable asset without approval, and provides resilience if one key is lost.

The legal questions that multisig arrangements raise are specific and should be addressed in the documents governing the arrangement:

• Authorization. Which individuals hold the keys, in what capacity, and under what authority? If the keyholders are employees, what happens when one leaves?
• Threshold changes. Can the threshold or the list of signers be altered, and who must approve that change?
• Quorum failure. Nobody stands above the contract with the power to override it. If so many signers become unavailable that the threshold cannot be reached, the asset stays where it is, permanently. The governing agreement needs to specify how a signer is replaced before that situation arises.
• Acquisition due diligence. If the seller is an organization that holds the TLD through a multisig, the representations about key control must cover every keyholder, not only the lead contact.

A multisig also changes how a signature block maps to reality. The person who signs the purchase agreement for the seller may be one signer among several on the wallet, or not a signer at all. Closing then depends on people who are not parties to the negotiation. Ask early who they are, whether they have been told, and how long gathering their approvals takes.

The same questions apply when you never speak to the holder directly. An organization that prefers not to approach a holder itself can mandate a desk to find and approach one, which is what a buy-side acquisition is. The keyholder questions above belong on your list from the first exchange.

Loss of keys: permanent and without remedy on the chain

Key loss is the failure mode with no technical remedy. If a private key is lost and no backup of the seed phrase exists, access to whatever the address holds is gone for good. No company, no support team, and no court order can recover it.

That last point bears emphasis for a legal audience: “no court order can recover it” is a statement about mathematics, not about judicial authority. A court can award damages for the loss, declare who should have had access, and make orders against the person responsible. It cannot reconstruct a key that was never backed up and has been destroyed. The TLD stays on the ledger at an address nobody can operate. For practical purposes, it is out of reach.

The risk takes three common forms in commercial contexts. First, a sole holder who loses their device and never made a backup. Second, an organization that leaves its keys with a single employee, who then departs or dies. Third, a multisig whose threshold can no longer be reached because too many keyholders have lost their keys or become unavailable.

Loss and compromise are different events with different consequences. A lost key freezes the asset: nobody can move it, including a wrongdoer. A copied key leaves the asset movable by two parties, and the first to act prevails on the ledger. The response differs too. After a suspected copy, the holder can move the token to a fresh address whose key was never exposed. After a loss, there is nothing to move it with.

In a transaction, key-loss risk translates into two drafting obligations. Before closing, the seller warrants that the keys have not been lost, that no unauthorized party has a copy, and that backups exist. On the buyer’s side, a key-management procedure must be in place before the transfer occurs, not after: who generates the receiving address, where its backup is kept, and who can reach it.

What to put in a contract because of all this

The analysis above points to a checklist of provisions that a purchase agreement or a governance document for an onchain TLD can address. None of these are exotic. They are adaptations of concepts already present in software licensing agreements, IP assignments and custody arrangements. The list is information, not legal advice: which provisions fit, and how they are enforced, depends on the governing law, and your own judgment as counsel decides.

In a purchase agreement

• Representations on key control. The seller warrants that it holds, and is the sole holder of, the private key or keys to the address recorded in the registry as holding the TLD. The representation extends to seed phrases and any hardware storage devices.
• No unauthorized copies. The seller warrants that no third party has a copy of the key or seed phrase, including former employees, service providers or custodians.
• Transfer mechanics. The agreement specifies that the transfer will run through onchain escrow, identifies the aftermarket used, and states the sequence of steps. Consideration reaches the seller only once the token has arrived at the buyer’s designated address.
• Buyer address confirmation. The buyer warrants that the receiving address is controlled by the buyer, that the buyer holds the corresponding private key, and that the address is not held by a custodian unless the agreement expressly permits that.
• Post-transfer steps. The agreement identifies the technical steps required after the blockchain transfer, such as configuring the TLD and setting up a multisig if one is required, and allocates responsibility for each.
• Risk before closing. The agreement says what happens if the seller’s keys are lost or copied between signing and transfer and the TLD cannot be delivered: who bears the loss, and on what measure.

In a governance document for a corporate holder

• Identify which individuals hold keys, in what capacity, and whether they hold them personally or on a hardware device owned by the organization.
• Specify the threshold required to authorize a transfer, a configuration change or a change of signers.
• Record the backup procedure for seed phrases, including the physical storage location and who may access it.
• State the succession procedure if a keyholder becomes unavailable.
• Schedule a periodic review of the key-management arrangement.

Lawyers and advisers who are handling a file for a client will find a page written for advisers who refer a file.

Applying the vocabulary to a file in front of you

The vocabulary above is the foundation. The practical work is applying it to a specific file: looking up the registry record on a block explorer, confirming the wallet type and key-management arrangement, specifying the transfer mechanics in the agreement, and establishing post-transfer controls before the token moves.

Hush Partners is a private desk that works only on onchain TLDs. It takes mandates from holders who want a buyer and from organizations that want a holder found and approached. A standard mutual NDA covers every exchange, and a single named partner stays with the file from the first note through to closing, which runs through onchain escrow on an aftermarket. The fee is a fixed amount, not a share of the price, and only the client who gave the mandate is charged it. A party that answers a note pays the price of the TLD and nothing to the desk.

If you are advising on a file that involves an onchain TLD, the page on how a file runs describes the stages from mandate to transfer. To open a conversation, use the contact form.

Questions people ask

Does the registry know who the legal owner is?

The registry records the address that holds the token. It does not record the legal identity of the person or entity that controls that address. Connecting the address to a named party is the work of the transaction documents, not of the registry itself.

Can a court order a transfer of an onchain TLD?

In general terms, a court can direct an order at the person who controls the relevant private key, and the consequences of refusing depend on the jurisdiction. It cannot instruct the blockchain to move the token directly. Where no one holds the keys any longer, compliance is impossible, and the dispute turns to whatever remedies the law offers against the person responsible.

What does a hosted wallet add to due diligence?

A review of the custody agreement. Confirm that the custodian’s terms permit a transfer out, whether any consent or release from the custodian is needed to complete the transaction, and how long the custodian takes to act on an instruction. Where the holder keeps its own keys, none of this applies, and the review turns to the key-management questions set out above.

What does “onchain” mean compared to a domain name in the conventional DNS?

A conventional domain name under a generic TLD is a record in a registry operated under contract with ICANN and sold through registrars. Its transfer requires those intermediaries to update their databases, and their policies provide for locks, suspensions and dispute procedures. An onchain TLD is a token on a public blockchain. Its transfer requires a valid transaction from the key that controls it, with no registrar involved, and ICANN’s policies do not govern it. That removes some procedural friction and some administrative recourse at the same time. The comparison of an ICANN dotBrand and an onchain TLD sets out the differences in detail.