A shared suffix or a TLD of your own: two naming models

When an organization starts exploring onchain naming, it quickly encounters two structurally different arrangements. The first is familiar in spirit: register a name under a suffix that already exists and is operated by someone else. The second is more unusual: acquire or mint the suffix itself, so that every name under it is yours to issue, price and define.

The distinction sounds simple, but it reaches into brand strategy, legal exposure, commercial structure and long-term operational dependence in ways that are worth mapping carefully before any commitment is made. This article lays out both models, compares them on the criteria that matter most to an organization, and closes with the questions that determine which path, or which combination, is right for a given situation. Several naming systems exist under each model. None is named or ranked here: the structure is what matters.

After reading, you should be able to explain the structural difference between the two models to a room that includes lawyers, brand managers and technologists, and you should know which questions to bring to your advisers before choosing.

The shared-suffix model: registering a name under someone else’s TLD

In the shared-suffix model, a registry operates a TLD (a top-level domain, the ending of a name), .yoursector for instance, and opens it for registrations. Any party meeting the registry’s eligibility rules can register a name under it: company.yoursector, project.yoursector, pay.yoursector. The TLD itself stays with the registry. You hold only the name beneath it.

The registry decides what the TLD is called, what names are allowed, how much they cost, what renewal terms apply, and what happens if a name is disputed. Some registries let the market set those parameters loosely. Others impose strict policies from the outset. Either way, the structural point is the same: the rules of the namespace are not yours to write.

This model is the dominant pattern in the traditional DNS. Under ICANN’s framework, a registration under a generic TLD is a tenancy: an accredited registrar sells you the right to use a name for a period, subject to the registry’s own terms and to ICANN’s policies. Those policies include the Uniform Domain-Name Dispute-Resolution Policy (the UDRP, the process by which a trademark owner can challenge a domain registration). Onchain registries that run a shared suffix follow a parallel logic, adjusted for a custody model in which the name is a token in the registrant’s wallet instead of an entry kept by a registrar. The form is different. The tenure relationship is not.

From a practical standpoint, the shared-suffix model is faster and cheaper to enter. A name under an existing TLD can be registered quickly, at a cost set by the registry, with no namespace to manage. For individual users, developers or small projects, that simplicity is precisely the point. For an organization with a brand to protect and users to serve, the limits of tenancy become relevant quickly.

The own-TLD model: holding the suffix itself

In the own-TLD model, the organization holds the TLD itself: the record that says .yourbrand belongs to this wallet. On a registry such as Freename, a TLD is recorded onchain as a token held in a wallet (a wallet being the software or device that keeps the keys controlling the token). There is no annual renewal fee on a Freename TLD, and only the holder of a TLD can issue names under it.

Holding the TLD means holding the namespace. You decide what names to issue (pay.yourbrand, id.yourbrand, agent.yourbrand), on what terms and to whom. You also decide what those names do: a name can resolve to a wallet address, point to a website published to IPFS (a network that stores files by their content instead of by a server’s location), or serve as the identity of an AI agent. The capabilities that are live span payments, websites, wallet resolution and agent identities, each with its own limits.

The own-TLD model has an equivalent in the traditional DNS, but a distant one. ICANN runs application rounds in which a brand can apply for a dotBrand, .yourbrand in the ICANN DNS root. That process is long, involves a substantial evaluation fee and the duties of a registry operator, and is open only when a round is. A side-by-side comparison of an ICANN dotBrand and an onchain TLD is useful reading for any organization evaluating both paths. The onchain route does not produce a TLD in the ICANN DNS root, which means an ordinary browser does not open its names without additional support. That is a real constraint, covered in more detail below.

Control: who sets the rules for names

Control is the sharpest difference between the two models, and it operates at two levels: the rules that govern the namespace, and the technical permissions that enforce them.

Under a shared suffix, the registry sets both. It decides whether names can be freely registered or must meet eligibility criteria. It decides the dispute-resolution mechanism that applies when a trademark owner objects to a registration. It decides what happens if it changes its terms, stops operating or is acquired. Your name sits inside that rule set. You did not write it and cannot change it unilaterally.

Under an own TLD, you write the namespace rules, within what the registry’s contracts and tools support. You can decide that names go only to entities you have vetted, set a naming policy, and settle in advance how a contested name is handled. Nothing forces you to open the namespace to the public: an organization can issue names only to its own services. The registry’s role becomes infrastructure more than governance. It records the token and runs the smart contracts (the programs on a blockchain that keep the records and apply the rules), but the decisions about who gets which name are yours.

The technical mechanism matters here. Control over the TLD is control over the token. For .yourbrand, as for any TLD, that record sits in public view at the registry, where a block explorer lets anyone check it. Transferring the token transfers the TLD. Losing access to the wallet loses control. Wallet management and custody are therefore governance questions as much as operational ones. An organization will usually want the token in a multisignature wallet, one that needs several approvals before anything moves, with a written rule for who approves and what happens when one of those people leaves.

One practical implication for legal teams: the rules of a shared-suffix namespace, including its dispute-resolution process, are contractual terms set by the registry. Your rights under them are no stronger than those terms allow. With an own TLD, your governance of the namespace is as strong as your custody of the token, and no stronger.

What control does not give you

Writing the rules of a namespace is not the same as controlling everything around it. The holder of a TLD does not decide which wallets and browsers resolve its names. The holder does not set the registry’s own terms, which still apply to the TLD. And holding a string in one naming system gives no right over the same string in another system or in the DNS. Control is real, and it stops at the edge of the namespace.

Identity: what the ending signals

A suffix is not neutral. It carries meaning that attaches to every name registered under it, and that meaning is shaped by who uses the suffix and how.

Under a shared suffix, the ending is shared with every other registrant. If the suffix is a sector word, .yoursector, then any company in that sector can register under it. The suffix says something about the field, not about you. company.yoursector places you in a category alongside competitors and unrelated parties. That can be a useful signal of relevance, or it can dilute the identity value of the name, depending on how the namespace is managed and how it is perceived by the audiences you care about.

Under an own TLD, the ending is yours within that registry. Every name under it, pay.yourbrand or id.yourbrand, carries your brand in the suffix. The ending itself becomes a mark of provenance. A user who knows that .yourbrand belongs to your organization can treat pay.yourbrand as yours to operate, because only the holder of the TLD could have issued it. One limit deserves a plain statement: several naming systems exist, and the same string can be recorded in more than one of them. Holding .yourbrand in one registry is exclusive there, not everywhere.

For trademark and brand protection teams, the distinction has practical weight. A trademark protects a sign as an indication of where goods or services come from. A suffix you hold can work in the same direction in practice, since every name under it traces back to one holder whose record is public. A suffix you share with others cannot. Whether any of this carries legal weight depends on the country and on the facts, and holding a TLD is not a substitute for a trademark registration. The implications for enforcement and for consumer trust are worth working through with your own counsel, who decides.

There is also a reputational dimension that brand teams understand instinctively. The organization that holds .yourbrand decides what appears under it. The organization that holds company.yoursector shares the suffix with every other registrant, including those whose conduct it cannot influence. If a shared suffix becomes associated with poor practice, the association reaches every name under it.

Dependence on whoever runs the suffix

Every naming arrangement involves some dependence on infrastructure. The question is what form that dependence takes and what happens when something changes.

Under a shared suffix, your names depend on the registry’s continued operation, its pricing decisions, its policy choices and its survival as an entity. If the registry raises fees, changes eligibility rules, adds new dispute mechanisms or ceases to operate, every name registered under that suffix is affected. You have whatever rights the registration terms provide, and no more.

The architecture of an onchain registry changes the shape of that dependence without removing it. A name held as a token in your own wallet is not an entry that an intermediary keeps on your behalf. But you still depend on the registry for the resolvers that translate the name, for the policy that governs the suffix, and for the meaning the market attaches to that ending. A name under a suffix nobody resolves or respects is a token with little use.

Under an own TLD, the form of dependence shifts. You still depend on the registry for the underlying infrastructure: the smart contracts that record names, the resolvers that translate them, and the wallets and browser tools that support them. But you do not depend on the registry’s policy choices for the names under your TLD, because you make those yourself. If the registry stopped operating, the token would remain a record on the blockchain, but a record that nothing resolves does little work. What portability means in practice, and what would be needed to keep names working, are questions to put to any registry before you commit.

A dependence both models share

Neither model frees you from the people inside your own organization. A name under a shared suffix registered from an employee’s personal wallet, or a TLD whose keys sit with one person, is a dependence too, and often a more immediate one than the registry. Whichever model you choose, record which wallet holds what, who can act on it, and how that is handed over.

Issuing names to others, and what each model costs

For most individual users, the question of issuing names does not arise. For an organization, it often does. A brand may want to issue pay.yourbrand to its payment service, id.yourbrand to its identity service, agent.yourbrand to an AI agent, and partner.yourbrand to an accredited distributor. An operator running a community or a platform may want to issue names to members.

Under a shared suffix, you cannot issue names to others in any structural sense. You hold company.yoursector, and the examples in this article stop at those two levels because that is where your position stops: the registry issues names, and you receive one. If you want a set of names that others can hold under your brand or your community’s identity, the shared-suffix model does not provide it.

Under an own TLD, issuing names is the central act. You decide who gets a name, on what terms, and what that name can do. For operators who run a market TLD as a namespace, opening it for registration in a sector or a community, this is the business model. For a brand using .yourbrand only for its own services, it is an internal governance mechanism.

Issuing brings duties that a registrant never meets. Someone has to decide whether a requested name is acceptable, answer the party who says a name issued under your TLD conflicts with its trademark, and keep the list of names in order. A brand that issues a name to a distributor needs a rule for what happens when the distribution agreement ends, and should check in advance what the registry’s tools allow it to do with a name once issued. Under a shared suffix, the registry carries these burdens. Under your own TLD, you do.

The commercial dimension is separate. On the own-TLD side of this comparison, Freename operates a royalty program: for each name registered under a TLD, part of the registration fee goes to that TLD’s holder, a share advertised at up to half and subject to the registry’s current terms and activation conditions. A TLD opened to the public can therefore earn something each time a name is registered beneath it. Taking part is not free, though: the TLD itself carries no annual renewal fee, but the registry sets a yearly cost for the royalty program. Certain TLDs were registered under earlier terms that include the program for life, and anyone acquiring one should confirm with the registry, before closing, whether those terms carry over to a new holder. The Subname Revenue Calculator estimates that revenue from your own assumptions about the number of names and the price of each.

Cost structure: recurring rent or a single acquisition

The two models cost money in different shapes, and the shape matters more than any single figure.

Under a shared suffix, you pay what the registry charges to register a name. Many shared suffixes also charge a renewal, which makes the name a recurring line in a budget and gives the registry a lever over time: the fee can change, and a missed renewal can cost you the name. The entry cost is low, and the cost of holding one name stays low. The cost grows with the number of names you want and with the number of suffixes you want to be present under.

Under an own TLD on Freename, there is no annual renewal fee. The cost is the price of minting or acquiring the TLD, which depends on the string and on whether somebody already holds it, followed by the cost of running the namespace: custody, policy, and the staff time that issuing names takes. Names you issue to yourself under your own TLD are yours to create. For a namespace you plan to use for years, with many names, the comparison leans one way. For a single name in a community you want to be present in, it leans the other.

Two cautions keep the comparison honest. A TLD with no renewal fee still has an owner’s costs, the yearly cost of the royalty program among them if you take part, and a TLD nobody uses returns nothing on its price. And the low entry cost of a shared suffix says nothing about what the name will cost to keep, so read the renewal terms before you build anything on it.

The table below sets the two models side by side on six criteria.

Resolution and the limits of onchain naming

Any honest comparison of the two models must address resolution, because this is where onchain naming as a whole differs from the DNS, whichever model you choose.

Onchain names resolve outside the ICANN DNS root. An ordinary browser does not open them without support. Whichever of the two models a Freename name comes from, it works in three places: Bitcoin.com Wallet, MetaMask by way of Freename’s resolver, and a desktop browser fitted with the Freename Web3 extension. Coverage is partial and changes. Where anyone in the world must reach a public website from an unmodified browser, the DNS is simply the better infrastructure, and an onchain name complements a domain name without replacing it.

This constraint applies to both models, but it bears on them differently. Under a shared suffix, you benefit from whatever support the registry has obtained for its suffix, and you are limited by it. Under an own TLD, your names resolve wherever the registry that records your TLD is supported. You do not negotiate that support yourself, which makes the registry’s reach one of the first things to check before you acquire a TLD.

The uses that fit onchain names, such as payments to a name inside a wallet, identities for AI agents and naming for an organization’s own services, are not the ones where browser resolution is the deciding factor. Organizations that see this distinction deploy onchain naming where it adds something, not where it merely repeats what the DNS already does well.

Coexistence: organizations often hold both

The framing of “shared suffix or own TLD” can suggest a binary choice. In practice, an organization with an onchain naming strategy often holds both.

Consider three invented cases. A brand holds .yourbrand for its own payment addresses, agent identities and service names, and also registers company.yoursector under a shared suffix where its users are already active. An operator runs .yoursector as a public namespace and holds .yourbrand for its own product. A fund holds several TLDs serving different communities, and its portfolio companies register names under shared suffixes.

Holding both creates one piece of work: keeping them consistent. Users should be able to tell which names are yours. A short public statement of the names you operate, under your own TLD and under any shared suffix, does more for trust than either holding alone, and it gives your brand protection team a reference when a look-alike name appears.

Coexistence also has a defensive side. An organization that holds .yourbrand gains operational capability, and it also closes the possibility that another party holds that ending and issues names under it that look affiliated with the brand. This is the subject of trademark TLDs, where onchain holdings and brand protection meet. If the TLD matching a brand is already held by someone else, acquiring it is a separate exercise, and not always a simple one.

Questions that decide between the models

No single answer fits all organizations. The following questions are the ones that, in practice, separate the two paths.

Do you need to issue names yourself? If your use requires that you control who holds a name under .yourbrand and what that name resolves to, only the own-TLD model gives you that. Under a shared suffix, you are a registrant, not an issuer.

Is the suffix itself part of your brand? If .yourbrand is meant to work as a mark of origin for everything named under it, sharing a suffix with competitors or unrelated parties defeats the purpose. An own TLD is the arrangement that makes the ending yours within its registry.

How much does namespace governance matter? If you need your own eligibility rules, naming policy or process for contested names, you need the own-TLD model, and the people to run it. Shared suffixes come with governance already set. If you are comfortable operating under someone else’s rules, a shared suffix may be sufficient.

What is your tolerance for registry dependence? Under a shared suffix, your names are subject to the registry’s policy and its continued operation. For many uses that is acceptable, and the model is simpler. If you need to set policy independently, or if the long-term stability of the namespace is a strategic concern, the own-TLD model reduces that exposure without removing it.

Which cost shape fits your organization? A few names under shared suffixes are an operating expense that can change with the registry’s terms. A TLD is an acquisition followed by the cost of running it. The number of names you expect to need, and for how long, usually settles this.

Where must the names work? List the wallets, browsers and applications your users have. A model, and a registry, that those tools do not support cannot serve them, whatever its other merits.

Is the TLD you want already held? A string that is free can be minted. A string that somebody holds has to be acquired from that holder, and there the structure of the approach matters as much as the price.

Starting from the right question

The cleanest way to begin is to decide what you need the naming arrangement to do, and then to ask which model does that.

If you need a presence in an existing community namespace where names are already in use and recognized, a shared suffix provides that immediately. If you need a namespace you govern, because the suffix is your brand, because you issue names to others or because you need policy independence, the own-TLD model is the right frame. Write the answer down in one page: the names you need, who will hold the keys, who decides on issuance, and where the names must resolve. That page is what your advisers and your counsel will ask for first.

For an organization that has not yet looked at its position, the Namespace Exposure Score is a free tool that scores how exposed a brand is onchain. If you acquire a TLD, post-transfer activation covers putting it to work once the transfer is done.

Hush Partners is a private desk for onchain TLDs. It acts for organizations that mandate it to find and approach the holder of a TLD, and for holders who mandate it to find a buyer. Every exchange is covered by a standard mutual NDA, and how a file proceeds is set out from mandate to transfer. The desk is reached through the contact form.

Questions people ask

Does holding your own TLD stop others from holding a similar one?

No. Each TLD in a registry is a distinct string. Holding .yourbrand means nobody else can issue names under it there. It does not prevent another party from holding a different string, such as a plural, a misspelling or a phonetic variant, or the same string in another naming system. Monitoring is a separate discipline from holding a TLD, and a complete brand protection strategy needs both.

Can a TLD of your own be transferred or sold later?

Yes. On Freename, the TLD is held as a token in a wallet, and transferring the token transfers the TLD. An organization that acquires a TLD is not locked in. Internal reorganizations, sales of a business unit and outright sales of the TLD are all possible, and each should be planned with counsel, because of the names already issued under the TLD: those sold to third parties remain theirs under the new holder, while those the seller itself holds can be transferred with the TLD if the two parties agree.

Does the UDRP apply to names under an onchain suffix?

The UDRP is a policy of the ICANN system. It binds those who register domain names through ICANN-accredited registrars. It does not bind a registry that operates outside the ICANN DNS root. Each onchain registry has its own terms and its own way of handling complaints. An organization with a trademark concern about an onchain name should read the terms of the registry involved and ask its own counsel which remedies are available, since they vary by country.

Can one TLD serve internal naming and public registrations together?

In principle, yes. The holder decides who receives a name, so it can keep a set of names for its own products and services while opening others to outside parties on terms it defines. The practical boundary is what the registry’s tools support, and the reputational one is that every public name sits next to your own. Decide which names are reserved before opening anything.