Names for staff and teams under your own TLD

Holding your own TLD gives you authority over every name issued beneath it. That authority is worth very little if the organization does not use it deliberately. Most organizations that acquire a TLD think first about public-facing uses: a payment address, a website, an identity that customers see. The internal use is quieter and deserves the same care: giving names to the people and teams that make up the organization itself.

This article is for the head of IT, the head of people operations, or whoever sits where identity systems meet access governance. It walks through what a staff naming program under your TLD does, how to design one that holds together over time, and where the edges are: the uses that are out of scope, the privacy questions that need answers before you start, and the moment when a pilot of a few names turns into something that needs a policy.

By the end you will have enough to decide whether to issue names at all, who should receive them, what rules the program needs, and how to write a lifecycle that keeps the namespace clean when people move or leave.

What a name under your TLD does for the organization

A name issued under your TLD is a public statement that software can read. What gives the statement its meaning is a Freename rule: issuing names under a TLD is open to its holder and to no one else. When finance.yourbrand resolves to a wallet address, anyone who reads that resolution knows that whoever holds .yourbrand issued the name. No company directory has to be consulted for that. The registry record is public and anyone can check it on a block explorer, a website that displays what is recorded on a blockchain.

For a person or team inside the organization, that means the name can carry real operational weight. A treasury function that receives onchain payments from a counterparty can give that counterparty treasury.yourbrand instead of a long raw wallet address. In a wallet that supports the name, the counterparty resolves it at the moment of payment and does not have to store the address. If the organization later replaces the wallet behind that name, the name stays the same and the counterparty changes nothing.

The same logic applies to an AI agent that runs under the organization’s namespace, a use described on the page about identities for AI agents under a TLD. The name is a stable identifier that outlasts any particular wallet, key rotation or infrastructure change.

What a name does not do, on its own, is prove anything about a specific natural person. It shows that the holder of the TLD issued it. The link between the name and a human being is a matter of internal record, not something the blockchain asserts. That distinction matters for the privacy discussion below, and it matters for how you explain the purpose of the program to staff.

It also sets the standard for counterparties. A name tells them which organization stands behind an address. It does not tell them that a given payment is due or that the person who sent them the name may give instructions. The first time a name is used with a counterparty, the name should be confirmed through a channel both sides already trust, exactly as a change of bank details would be.

Functional names and personal names: two very different things

Before issuing a single name, the organization needs to choose between two models, or decide where each applies.

A functional name identifies a role, a team or a system: legal.yourbrand, payroll.yourbrand, infosec.yourbrand. The name belongs to the function, not to the individual who fills it. When the person moves on, the name stays; only the wallet or record it resolves to changes. Functional names are easier to govern and easier to explain to staff, because no one is asked to carry a personal identifier they will eventually lose.

A personal name identifies an individual, for instance alice.yourbrand. It is tied to a person’s tenure. It may feel more human, and it may be the right choice where individual accountability needs to be visible. Consider a professional services firm in which each client-facing partner receives payments for the engagements that partner leads. Personal names raise harder lifecycle questions, they touch employee privacy in a way functional names do not, and they create a collision the day a second person with the same first name joins. A convention has to settle that case in advance, and it has to do so with a single label, since a name under your TLD has two levels: the TLD and the name.

Most organizations are better served by starting entirely with functional names and adding personal names only where there is a documented operational reason. The table below maps the main kinds of name, who holds each, and when the name ends.

Three of the four rows name no natural person. A role name comes close, because a role with a single holder identifies that holder to anyone who knows the organization. The third row is plainly different. The moment alice.yourbrand resolves publicly, you have made a statement about a person visible to anyone who looks at the registry. That warrants a separate conversation with whoever advises the organization on data protection.

Who holds the name itself

One design choice runs under the whole table. A name can sit in a wallet the organization controls and merely point to the address a person or team uses, or it can be transferred into the wallet of the person it describes. The first arrangement is the one this article assumes. The organization keeps the name, changes what it points to, and can withdraw it without asking anyone.

The second arrangement hands control of the name to an individual. What the organization can then do on its own depends on the registry’s terms and on the way the name was issued. Check that point with the registry before any name leaves a wallet you control. A name you cannot withdraw is not a staff name. It is a gift.

The lifecycle: joining, moving and leaving

The largest operational risk in a staff naming program is not issuing a name. It is failing to withdraw one. A name that still points to the wallet of someone who has left can go on receiving payments meant for the organization, and it lets that person appear to be inside the organization. Neither outcome is acceptable. The lifecycle has to be settled before the first name is issued.

Joining

When a new employee or contractor starts, the question is not whether to issue a name immediately but whether there is an operational need. Issuing names by default at onboarding fills the namespace with names that have no purpose and that someone must still track. A better pattern is to issue a name when a specific function requires one: a finance officer who will receive onchain payments, an IT team that will operate a smart contract (a program that runs on a blockchain), an AI agent that needs a stable identifier. Each issuance goes through the approval workflow described in the next section.

Moving

Promotions, lateral moves and restructurings all affect names. A functional name tied to a role has to be pointed to the wallet of the incoming person. A personal name held for someone who has moved to a role with no onchain duties may need to be retired. Neither operation is technically complex, since each is an update of a record. Both have to happen as part of the HR or IT change workflow, not as a separate manual step remembered afterward.

Moves are where names quietly go stale. A departure is an event everyone notices. A transfer between departments is not, and the old name keeps working. The person who changes role should lose the old name on the day the new role starts, even if the handover of duties takes longer.

Leaving

This is the highest-risk moment. The leaving procedure needs to be formal, fast and logged.

1. Trigger on noticeThe day notice is given or a termination is decided, IT flags every name associated with that person in the internal register of names. This happens the same day, not at the end of the notice period.
2. Stop resolutionBefore the last day of employment, update the record so the name no longer resolves to the wallet the departing person uses. Point it to a holding address controlled by IT, or clear the record if the name is personal and will not be reused.
3. Confirm wallet accessCheck that the departing person no longer controls a key to any wallet associated with a name, including the wallet that holds the TLD. This is an access-governance step, not only a registry step.
4. Decide on reuse or retirementPoint a functional name to the wallet of the incoming person once that wallet is confirmed. Retire a personal name, and do not give it to another person, because that confuses the reading of past records.
5. Log the changeRecord the date of each update, the name affected and the operator who made the change. This log is the audit trail if a question arises later about a payment made to that name.

A larger program may add a reconciliation that runs every night against the HR system and flags any name whose holder has changed status. The reconciliation is simple to build. Whether to build it is a governance question about how many names justify the overhead.

Who approves a name

Every staff name traces back to one wallet. Freename records the TLD onchain as a token, that token is held in a wallet, and the power to issue names under the TLD belongs only to whoever holds it. That technical fact has to map to an organizational one: a designated function has custody of that wallet and exercises the authority to issue.

A three-part structure works well. The TLD sits in a multisignature wallet (one that requires more than one key to authorize a transaction) controlled by IT or treasury, so that no issuance or withdrawal rests on one person. Requests for new names come from functional owners: the head of finance asks for treasury.yourbrand, the head of IT asks for infra.yourbrand. A designated authority, such as the chief technology officer or the chief operating officer, approves them. IT then carries out the operation against that approval.

That structure does three things. It prevents any single employee from issuing names alone. It leaves a trail from request to approval to execution. And when someone who held a key to the TLD wallet leaves, the departure does not interrupt the program, although that key must be replaced as part of the leaving procedure.

The approving authority should also define naming conventions before the first name is issued. Conventions keep the namespace from fragmenting. A simple rule saves a great deal of cleanup later: all names are lowercase, each team name is a single word, and role names follow the organization’s standard job titles.

The same authority should own a short list of reserved names. Names such as ceo.yourbrand, board.yourbrand or security.yourbrand carry weight with outsiders whatever they resolve to. They are issued only to the function they describe, or not at all.

Employee privacy and what the organization owes staff

Functional names that do not name a person carry less risk. legal.yourbrand says something about the structure of the organization, not about an individual. A personal name such as alice.yourbrand says that someone called Alice is connected to the organization. That record is public and, depending on the registry and the blockchain, its history may be difficult or impossible to erase.

Some steps make sense in any country. First, tell staff which names are being issued, in what form and for what purpose, before issuance. Second, keep personal names voluntary where possible, particularly for staff who have no operational need for one. Third, put nothing in the name beyond the identifier of the person: no department, no seniority, no location. The name resolves to a wallet. It does not need to be a directory entry.

A fourth step concerns the wallet. A personal name should point to a wallet used for work only, provided or approved by the organization, never to a wallet the employee also uses privately. A blockchain shows the activity of an address to anyone. Tying a private wallet to a name that identifies its owner would expose that person’s own dealings to colleagues and strangers alike.

All of this argues for a conservative default: issue personal names only where there is a real operational reason, keep functional names as the primary form, and be explicit with staff about what the name does and does not assert.

Uses that are out of scope

A staff naming program has a defined purpose: operational identity within the organization’s namespace. Several adjacent uses are not appropriate, and the policy that governs the program should say so in plain words.

A name is not an authority to commit the organization. An employee to whom alice.yourbrand is assigned cannot rely on that name to enter into contracts for the organization unless that person has been separately authorized. The name identifies. It is not a power of attorney.

Names must not be used to impersonate another person or to suggest seniority or authority the holder does not have. This becomes concrete when someone requests a name that sounds like the head of a function for a role that is not. The reserved names and the approval workflow prevent it, and the policy states it.

Names must not be passed to third parties or used outside the scope of the holder’s role. A former employee who goes on using a name, because the withdrawal was not completed or because access to a wallet was kept, is using something that belongs to the organization. The leaving procedure exists to prevent this, and the policy gives the organization a basis to act if it happens.

Names must not serve personal business. A work name that receives a private payment mixes the organization’s records with an individual’s affairs, and it becomes harder to withdraw cleanly.

Finally, names issued to individuals must not become a means of watching those individuals. The address a name resolves to is visible on the blockchain, and so is its activity. The organization should not follow the activity of a wallet it has associated with a named employee beyond what the stated purpose of the name requires. Your data protection adviser should review this point as well.

How this sits alongside existing identity systems

The organization almost certainly has identity infrastructure already: an email directory, an identity provider (the system that handles single sign-on), an access management system, and perhaps certificates for electronic documents. Names under your TLD replace none of those. They sit alongside them and serve a different layer.

Email is for communication. The identity provider governs access to systems. A certificate asserts identity within a defined chain of trust. An onchain name identifies the organization in onchain operations: receiving payments, interacting with smart contracts, giving an AI agent an identifier, or publishing to a decentralized address. The page on what works with onchain TLDs sets out the scope of each capability, with sources.

In practice the program needs a mapping between each onchain name and the internal identity record. When treasury.yourbrand is assigned to the head of treasury, the IT system needs to know that, so that a change of head of treasury triggers the update of the onchain record. That mapping is a table or a field in the HR system. It does not need to be public or onchain.

The direction of that mapping matters. The HR system or the identity provider remains the source of truth about who works where, and the onchain record follows it. The reverse does not hold. No internal system should grant access because a name resolves to a given address, since resolution shows only what the record says at that moment.

One constraint shapes everything else. A staff name, like any onchain name, resolves outside the ICANN DNS root, which is why an ordinary browser will not open it unless support has been added. Freename names are supported in Bitcoin.com Wallet, in MetaMask through Freename’s resolver, and in desktop browsers through the Freename Web3 extension, and the page on names that resolve in wallets covers that side in more detail. Coverage is partial and it changes, so the program should not depend on staff or counterparties resolving names in a standard browser. Staff names are suited to wallet operations, payments and agent identity. They do not replace conventional web addresses or email addresses, where the DNS is simply the better tool.

Staff names and the registry’s royalty program

Alongside issuance, Freename operates a royalty program: each time a name is registered under a TLD, a share of the registration fee goes to the holder of that TLD. The share is advertised at up to half, and it is subject to the registry’s current terms and activation conditions. That program matters when a TLD is operated as a namespace open to registrations by others.

A TLD used purely for staff names is a different case. The organization issues names to itself, so the royalty is not what the program is for. What matters is control: because only the holder of the TLD can issue names under it, the organization decides which names exist.

If the organization later wants to open part of the namespace to partners, clients or alumni, the royalty program becomes relevant and the governance becomes more complex. Its cost belongs in that decision too: a Freename TLD carries no annual renewal fee, but taking part in the royalty program has an annual cost set by the registry, unless the TLD was registered under earlier terms that include the program for life. That is a separate decision from the internal staff program. Keep the two apart in the initial policy, or the rules of each will blur the other.

For the order in which to switch on the capabilities of a TLD, the Launch Roadmap tool builds a roadmap for a newly acquired TLD.

Starting small and building the policy to fit

A staff naming program does not need a hundred names on the first day. Three are enough: a treasury function, an IT operations team and one agent that runs an automated process. Three names test the approval workflow, the leaving procedure and the mapping between onchain records and internal systems. Three names are also easy to redo if the naming convention turns out to be wrong.

The sequence worth following is this. Decide the purpose before issuing any name. Draft the lifecycle rules before the first issuance. Pilot with functional names only. Review after a fixed period before extending the program to personal names or to a wider group. That sequence takes longer than issuing names in bulk, and it produces a program the organization can govern.

The review should rest on a rehearsal. Take one of the pilot names through the whole leaving procedure as if its holder had resigned, and time each step. A procedure that has never been run is a document, and the first real departure is a poor moment to find out which step nobody owns.

A few decisions have to be made before the pilot:

• Which wallet holds the TLD, and who holds its keys?
• What is the naming convention, and who enforces it?
• Where is the mapping between onchain names and internal identity records stored?
• What triggers the leaving procedure, and who carries it out?

None of these requires an investment in technology. Each requires a decision and a written record of it. The written record is the policy. Start there.

If the organization holds a TLD that it has not yet put to work, post-transfer activation is the service that covers putting a TLD to work after the transfer. If the TLD that fits the organization is held by someone else, an organization can mandate Hush Partners to find and approach the holder, as the page on buy-side acquisition explains. Every exchange is covered by a standard mutual NDA.

Questions people ask

Can a contractor have a name under the company’s TLD?

Yes, operationally. The registry does not distinguish between an employee and a contractor. The governance question is whether the organization wants to draw that distinction in its policy. Contractors tend to have shorter and less predictable engagements, which raises the lifecycle risk. A reasonable default is to give contractors only functional names tied to a specific engagement, to write the date of withdrawal into the internal register when the name is issued, and to treat that date as an automatic trigger, not as an occasion for a review.

What happens to the name of a person who leaves on bad terms?

The same as for any departure: the record is updated, resolution is redirected or cleared, and access to wallets is confirmed as ended. None of those steps depends on the departure being amicable. The procedure should be triggered by the fact of departure, not by its tone. Building it around a neutral trigger, the change of status in the HR system, removes discretion from a moment where discretion creates risk.

Should staff names sit under the same TLD as public-facing names?

There is no technical requirement either way. A single TLD gives one namespace, and it also means that internal and public names share the same governance and the same public visibility. Some organizations prefer a separation: one TLD for public use, a second for internal operations. An organization that holds two can separate them easily. An organization that holds one should settle the question before the naming program grows. The glossary defines the terms involved in that decision.

Do staff names work for AI agents?

Yes. An AI agent that operates inside the organization’s systems can be given a name under the TLD in the same way as a human function. The name resolves to the wallet the agent uses, wherever name resolution is supported. The governance is the same: the holder of the TLD issues the name after an approval, the name appears in the internal register with a human owner who answers for the agent, and it is withdrawn when the agent is decommissioned. An agent has no notice period, so the trigger has to be written into the process that shuts the agent down.