# Running a market TLD for independent work

> For operators considering a TLD that names independent work: who would hold a name under it, what they would use it for, and what running it involves.

Source: https://hush.partners/running-a-market-tld-for-freelancers-and-creators
Category: Acquiring
Published by Hush Partners.

---
Independent work has a structural problem with identity. A freelancer or creator builds reputation across several platforms at once, but owns none of the identity those platforms assign. A platform profile can be restricted, suspended or made irrelevant by a product decision the worker had no part in. The work continues; the address it lives at does not.

A sector TLD for independent work is one response to that problem. The operator acquires a TLD whose word belongs to independent work, written here as `.yoursector`, and issues names under it to the freelancers, creators and platforms that make up the sector. A name such as `name.yoursector` then travels with its holder across every context where onchain names resolve.

This article works through who would actually register a name, what each registrant would use it for, what the operator takes on, and how the numbers look in one worked example. It is written for the person deciding whether to acquire the TLD, not for someone who has already committed. Where demand is thin, it says so.

## Who would hold a name under `.yoursector`

Four distinct populations exist in this sector, and their reasons for wanting a name differ enough to treat separately.

| Holder type | Primary use of a name | Strength of demand |
|---|---|---|
| Independent freelancer | Portable identity, payment address | Moderate, conditional on payment utility |
| Creator or publisher | Portfolio anchor, audience-facing address | Moderate, conditional on resolution support |
| Platform or marketplace | Names issued to its own users | Strong if the platform sees retention value |
| Membership association | Credential for verified members | Moderate, requires an active issuance program |

The asymmetry between the rows is the first thing to take from the table. Individual freelancers and creators are price-sensitive. They will register if the name does something specific for them that they cannot get more cheaply elsewhere. Platforms and associations are a different calculation: one organization that chooses to issue names to its members or users can bring more registrations in a single decision than a long campaign aimed at individuals.

The rows also differ in who carries the effort. A freelancer who registers alone has to set up a wallet, connect the name and explain it to clients without help. A member who receives a name through an association arrives with the setup done and with a context that gives the name meaning: other members hold one too. For the operator, that difference decides where the first months of work go.

## What a name does for a freelancer: getting paid across borders

### The payment address

The most common use case is payment. A freelancer working across borders deals with a recurring frustration: clients pay through platform escrow, wire transfer or consumer payment services, each with its own fee structure, currency conversion and delay. A name that resolves to a wallet lets a client send funds to `name.yoursector` rather than to a long string of characters that nobody can read back over a call, and the transaction settles between the two wallets.

This already works in practice. [Payments to an onchain name](/onchain-tld-payments) go through in wallets that support the registry's resolver. A payment router such as [shaka](https://shaka.deal) goes one step further: its payment link can pay out to a name, and the parties agree and sign the split onchain before any funds move, while the router itself never holds the money. That matters when a freelancer and a subcontractor share a project fee and neither wants to wait for the other to forward a share. The operator does not control any of this flow; the infrastructure sits at the registry and payment layer, not at the TLD level.

### Clients in other countries

Cross-border payment is the most concrete pain point in independent work, and it is where an onchain name does its clearest work. A freelancer in one country whose client is in another faces friction at every step of the conventional payment chain: bank fees, currency conversion spreads, holding periods and, in some countries, restrictions on receiving foreign currency through certain channels.

A name that resolves to a wallet removes the intermediaries between the two wallets. The client pays to `name.yoursector`; the network delivers the transaction to the freelancer's wallet; the conversion from one asset to another, if needed, happens separately and at the freelancer's discretion. No platform takes a cut of the invoice for standing in the middle.

The limits deserve the same plain statement. The network charges its own transaction fee. A freelancer who needs local currency still has to convert, and the route for doing so depends on the country. Invoicing, tax and reporting duties do not change because the payment arrived onchain; the freelancer's own accountant or counsel decides how they apply. The largest limit is the client. A corporate client with a fixed accounts payable process will often not pay to a wallet at all, so the name helps with the clients who are willing and does nothing for the rest. An operator should expect payment-driven demand from freelancers whose clients already pay onchain, and should not expect the name to convert the others.

The operator of `.yoursector` does not handle any payments. That is an important distinction. The operator issues names and maintains the TLD's rules. What the operator can do is make sure the documentation explains this use case clearly, and that the onboarding path for a new registrant who wants to receive payments is short.

### A stable address, and where it does not open

The second use is a stable, publishable address. A freelancer who gives clients `name.yoursector` can change the portfolio page it points to or the wallet it resolves to without asking a client to update anything. That stability has real value for anyone who moves between hosting services or shifts their primary platform.

What a name does not do is replace a conventional website for a general audience. Onchain names resolve outside the ICANN DNS root, so an ordinary browser will not open them without support. For a freelancer's name issued on Freename, the supported places are Bitcoin.com Wallet, MetaMask through Freename's resolver, and desktop browsers through the Freename Web3 extension. That coverage is partial and it changes. An operator running `.yoursector` should say this plainly in every piece of documentation issued to registrants; the page on [what works on onchain TLDs](/whats-live) lists each capability with its source.

## What a name does for a creator: portfolios and reputation

A creator's relationship with platforms is different from a freelancer's. The work is often public (articles, videos, visual work, audio) and the creator's address is part of how an audience finds and recognizes them. When a creator builds an audience on a single platform, the platform assigns that address. A name under `.yoursector` does not replace the platform presence, but it gives the creator an address that no platform assigned.

### A portfolio the creator controls

The practical benefit is the portfolio. A name can point to a page published on IPFS, a peer-to-peer storage network in which a file is addressed by its content and not by the server that hosts it. Freename's website builder lets the holder of a name build such a page and publish it; the page is then reached through the name in browsers that support it. A creator can gather selected work, client references and a payment link on that page, and send `name.yoursector` to a prospective client in place of a platform profile.

Because resolution is partial, the portfolio under the name works best as a second address next to a conventional site, not as the only one. A creator whose audience arrives through search and social platforms will keep those channels. The name earns its place when the creator wants one address that survives a change of platform and that carries a payment link next to the work.

Demand here is real but selective. A creator who has never thought about wallets will not register for the sake of decentralization as an abstract principle. They will register if the onboarding is simple, if the name does a concrete job on day one, and if the registration fee is proportionate to what they earn. A name presented as a working tool for a professional has a chance in this sector. A name presented as a collectible does not, because the people the namespace is for are buying a tool.

### Reputation that has somewhere to attach

Reputation in independent work is fragile in a specific way. A freelancer who has built a strong rating on one marketplace cannot carry that rating to a competing one. Each marketplace starts the worker from zero. Ratings and credentials that live on a public ledger instead of inside one company's database are a familiar idea in this sector, and they have not reached general adoption.

A name under `.yoursector` does not solve this by itself. It provides the stable address that any reputation layer would need to attach to. If an operator builds or integrates a credential or review mechanism, `name.yoursector` is the anchor. Without an anchor, a reputation record is either bound to a platform or attached to a wallet address that means nothing to a client.

This matters for operators thinking about long-term value in the namespace. The name is the address. What accumulates at that address (payments received, portfolio items, third-party credentials, onchain attestations) is what makes the name worth keeping. Be honest about the order of events, though: the credentials have to be issued by someone the sector already trusts, such as an association or a platform with verified work histories. An operator cannot manufacture reputation; it can only give it a place to sit.

## An identity that is not tied to one platform

The platforms themselves are a distinct and underappreciated registrant category. Consider a mid-sized marketplace in independent work, an invented one, that gives a profile page to every member. That marketplace has an interest in giving each member something portable: a name under `.yoursector` that the member keeps even after leaving. This is not altruism. A platform that offers its members a portable credential creates a reason to join, and it sets itself apart from competitors that issue only handles bound to their own service.

The argument has a counterweight that an operator should hear before the first meeting. A platform's commercial interest usually runs toward keeping members inside. Portability is attractive to a challenger that wants to draw workers from a larger rival, and to an association whose purpose is the member's career, not the member's activity on one service. It is far less attractive to a dominant marketplace. Choose the first conversations accordingly.

An operator who treats platforms and associations as bulk registrants, organizations that take many names to issue to their own users, changes the economics of the whole namespace. A single decision by one of them can move more registrations than months of individual outreach. The [page for operators](/operators) describes who runs a market TLD as a namespace and where the desk fits.

This also means the operator's policy decisions matter before launch. If a platform obtains `name.yoursector` on behalf of a member, who holds the name: the member, the platform, or both? If the member leaves the platform, does the name leave too? The answers need to be in the operator's terms before the first name is issued, not invented under pressure after a dispute. A namespace that promises independence from platforms and then lets a platform hold its members' names has contradicted its own reason to exist.

## Why individuals rarely pay for a name unless it does a job

This point deserves direct treatment because it is where a namespace launch most easily disappoints its operator. The decentralization argument ("you hold it, no platform assigned it") is real but insufficient as a purchase motivation for a freelancer earning a daily rate. Abstract sovereignty does not justify a registration fee. A concrete job does.

The jobs that motivate individual registration in this sector are, in order of reliability: receiving payments from clients who pay onchain, presenting a portfolio that the registrant controls, and signaling membership in a professional network that the namespace operator has made meaningful. The first two work wherever the name resolves. The third requires the operator to do work: build relationships with platforms and associations, and make the namespace mean something in the community it is meant to serve.

There is also a competing habit to account for. A freelancer already has a platform profile, usually a personal site, and often a page of links. Each of those is free or nearly free and opens in every browser. A name under `.yoursector` has to do something none of them does, and the only clear candidates are the payment address and the portable credential. If neither is ready at launch, an individual has no reason to pay.

An operator who launches `.yoursector` and waits for organic registration from individuals will likely see thin uptake. An operator who has agreed at least one partnership with a platform or association before launch, so that names arrive with a recognizable context, starts from a different position. The [Subname Revenue Calculator](/subname-revenue-calculator) lets you model registration scenarios with your own assumptions, including pessimistic ones.

## The operator's role: rules, issuance, support and disputes

Running a market TLD is not passive. The operator of `.yoursector` is responsible for four things that require ongoing attention.

**Rules.** The operator sets the terms under which names are issued: who is eligible, what names are reserved or prohibited, what counts as misuse, and what happens when a name is challenged. In this sector the reserved list needs thought. Job titles and trade words such as `designer.yoursector` or `editor.yoursector` are the names everyone wants and nobody has a particular claim to; decide whether they are held back, issued to associations, or never issued. These rules do not need to be elaborate, but they need to exist in writing before the first name is issued.

**Issuance.** On Freename, the holder of a TLD is the only party that can issue names under it. In practice the operator needs a working process for receiving applications, verifying eligibility where the rules require it, and issuing names within a delay that registrants find reasonable. An association that wants names for its whole membership needs to know whether the operator can handle that in a batch or requires individual processing.

**Support.** Registrants will have questions. An onchain name is not self-explanatory to someone who has not set one up before, and a freelancer has no IT department to ask. The operator needs a support channel and documentation that answers the most common setup questions: how to point the name at a wallet, how to update a record, how to give the name to a client as a payment address, and what the client needs in order to pay.

**Disputes.** Names that look like trademarks, names registered to pass as another worker, names that a registrant claims were issued to someone else in error: these will arrive. Independent workers trade under their personal names and studio names, most of which are not registered trademarks, so many complaints will rest on identity and reputation, not on a trademark certificate. The operator needs a stated process for handling them, even if that process is simple.

<aside class="callout">
<span class="callout-label">For operators</span>
<h4>When a name under your TLD is abused, the complaint comes to you</h4>
<p>A name used to pass as another worker or to mislead a client is a problem of your namespace, whatever the law of a given country says about liability. Publish the rules before the first name is issued, state how a complaint is filed and decided, and keep a record of each decision. Your own counsel should review the rules, particularly if registrants are in several countries.</p>
</aside>

## Revenue from names: a worked example

On Freename, a royalty program pays the holder of a TLD part of each registration fee for names registered under that TLD. The share is advertised at up to half, and it depends on the registry's current terms and activation conditions. The royalty applies to registrations; this example assumes no income from renewals. The price of a name is the operator's own decision, because the holder of a TLD sets what names under it cost and can price them differently. For the share and its conditions, read the registry's current terms before relying on any figure.

The following is a worked example, not a forecast. Suppose the operator of `.yoursector` has agreed terms with one mid-sized platform in the sector, an invented one, that issues names to verified members, and also opens registration to individual freelancers and creators. The assumptions are:

- Platform partnership: 400 names registered in the first twelve months.
- Individual registrations: 150 names in the same period.
- Total registrations: 550 names.
- Registration fee per name: USD 20, an assumption made for this example only.
- Royalty share received by the operator: half of each registration fee, the advertised maximum.
- Royalty income: 550 names x USD 20 = USD 11,000 in registration fees, of which half, USD 5,500, reaches the operator over the twelve months.

<figure class="fig">
<figcaption><b>Royalty income in the worked example, by source of registrations</b><span>USD over twelve months; 550 names at an assumed USD 20 per name, royalty share of half</span></figcaption>
<div class="fig-bars">
<div><span>Platform partnership (400 names)</span><i style="width:100%"></i><b>USD 4,000</b></div>
<div><span>Individual registrations (150 names)</span><i style="width:38%"></i><b>USD 1,500</b></div>
</div>
<p class="fig-src">Royalty income only, on the stated assumptions. The acquisition cost of the TLD and the operator's running costs are not included.</p>
</figure>

USD 5,500 over twelve months is not a business. It is what one platform partner and modest individual uptake produce on these assumptions. The point of the example is not to make the number look large; it is to show where the number comes from and what moves it. Doubling the platform partnership to 800 names doubles the platform line to USD 8,000. A lower share than the advertised maximum, or a lower fee per name, reduces every line in proportion. A second platform partner changes the picture more than any amount of individual outreach.

Set the result against the costs it does not show: drafting the rules, writing documentation, answering support questions and handling complaints all take time that has a price. The royalty program has a price too: taking part in it carries an annual cost set by the registry, which is not included in the USD 5,500 and must be deducted from it. So does the acquisition. The cost of the TLD is separate from royalty income and depends on the specific TLD; the page on [how a TLD valuation is built](/valuation) explains what goes into a figure before you approach a holder or answer one. An operator in independent work who cannot name the first partner should treat the example's platform line as zero and judge the acquisition on the remaining one.

## What to check before acquiring the TLD

Acquiring a sector TLD is a capital decision. Before committing, an operator should work through the following.

**The word and trademark exposure.** The word in the TLD may be a registered trademark of someone in the sector, in one country or several. An operator who issues names under a TLD whose word is claimed by a rights holder inherits that dispute. A trademark search is the first step. The free [Trademark Name Check](/trademark-tlds#check) is a starting point, and it does not replace advice from a trademark attorney in the countries that matter to you.

**The registry record.** On Freename, a TLD exists as a token in a wallet, and the record is public: you can look it up on a block explorer yourself. Do that before any discussion of price. A TLD acquired through the desk closes through onchain escrow on an aftermarket.

**Names already issued.** If names have already been issued under the TLD, find out which, on what terms, and whether any is contested. A namespace for independent work in which the obvious trade words are already in other hands is a different asset from an empty one.

**Your standing in the sector.** Ask whether you have a real relationship with independent work or whether the acquisition is purely financial. A namespace run by someone with no connection to the community it is meant to serve will struggle to win the partnerships that give an individual registration its meaning. An association or a platform starts with members; an outside operator starts with a word.

**Resolution gaps.** Be clear-eyed about where onchain names do not open. A freelancer who registers `name.yoursector` expecting it to work in every browser will be disappointed, and will say so in the same communities you are trying to reach. Document the limits accurately and invest in registrant education from the start.

## A realistic first year

<figure class="fig">
<figcaption><b>First-year sequence for a market TLD in independent work</b></figcaption>
<ol class="fig-steps">
<li><b>Diligence before acquiring</b>Run the trademark search, look up the registry record on a block explorer, and review names already issued and any open complaint. Write down the registration assumptions you are buying on.</li>
<li><b>Closing</b>Close through onchain escrow and check the public record again once the TLD is in your wallet.</li>
<li><b>Rules and policy</b>Draft the terms of issuance: eligibility, reserved trade words, prohibited uses, who holds a name obtained through a platform, and the complaint process. Have them reviewed by counsel in the countries where registrants will be based.</li>
<li><b>Platform and association outreach</b>Approach two or three organizations in the sector about issuing names to their members or users. One agreed partnership before public launch is worth more than any amount of individual marketing afterward.</li>
<li><b>Documentation and onboarding</b>Write the registrant documentation: how to set up a payment address, how to point the name at a portfolio, what a client needs in order to pay, and what to do when a name does not resolve. Write it for a freelancer who has never used a wallet.</li>
<li><b>First cohort through a partner</b>Issue names to a first group of the partner's members. Record every support question; the list becomes the public help page.</li>
<li><b>Open registration</b>Open registration to individuals with a clear statement of what the name does and where it does not work. Do not promise universal browser resolution.</li>
<li><b>Review after twelve months</b>Compare actual registrations with the assumptions written down in the first step. Ask whether the first partner will continue and whether a second is within reach. If individual registrations fall short, find the specific point of friction before spending more on outreach.</li>
</ol>
</figure>

The first year ends with a decision based on what happened: continue building the namespace, add platform partners, or accept that the TLD does not have the fit with the sector that was hoped for. That decision is easier to make honestly if the assumptions were written down before launch.

Expect the year to be uneven. In independent work, registrations tend to come in groups, when a partner onboards a cohort, and not as a steady flow of individuals. Quiet months between cohorts are normal and are not by themselves a sign of failure. A year with no partner at all is the signal to take seriously.

## The next step when a TLD is in view

If you are deciding whether to pursue a specific TLD, start with the two questions that cost little: is the word clear of trademarks in your countries, and can you name the first platform or association that would issue names? If either answer is no, the acquisition can wait.

If both hold and the holder has not approached you, an organization can mandate Hush Partners to [find and approach the holder](/buy-side-acquisition) on its behalf. Exchanges with the desk take place under a standard mutual NDA, and a single named partner stays with the file from the first note through to closing. The fee for that mandate is a fixed amount, not a share of the price.

Once the TLD has transferred, the [Launch Roadmap](/activation-roadmap) tool builds a launch plan for it, and [putting the TLD to work after the transfer](/post-transfer-activation) is a service the desk describes on its own page.

Nothing in this article is legal or tax advice. The rules that apply to an operator depend on the country, the sector and the terms of the registry. Your own counsel should review all of that before you close.

## Questions people ask

### Does the operator pay each year to keep the TLD?

A Freename TLD carries no annual renewal fee for its holder. The cost of holding the TLD is therefore the acquisition and the work of running the namespace, not a recurring registry charge on the TLD itself. The royalty program is separate: taking part in it carries an annual cost set by the registry. Earlier registration terms, which apply to some TLDs, include the program for life: an operator buying a TLD for a freelance or creator community should ask the registry before closing whether those terms pass to a buyer. Check the registry's current terms for anything that applies to the names issued under it.

### What happens to names already issued if the TLD changes hands?

The sale transfers the TLD. Names sold to freelancers, creators or platforms remain theirs, and names the seller itself holds under the TLD can be transferred with it if the two parties agree. The sale does not by itself settle what was promised to the people who already hold names under it. Before acquiring, read the terms those names were issued on and the registry's terms, and decide with your counsel which commitments you are taking over.

### Will a portfolio at `name.yoursector` appear in search engines?

Onchain names do not resolve in the ICANN DNS, so conventional search engine crawlers do not reach content published under them the way they reach a standard website. A freelancer who wants search visibility still needs a conventional web presence. The onchain name adds a payment address and a portfolio anchor; it does not replace search.

### How does an operator handle a name that appears to infringe a trademark?

The operator's dispute policy should set out a process: who can file a complaint, what evidence is required, how long the operator has to respond, and what remedies are available. The UDRP, the dispute policy that binds registrants of domain names in the ICANN system, does not extend to onchain TLDs, so the operator is not bound by it. Its outline (clear grounds, proportionate remedies, documented decisions) is still a sound model, and trademark law continues to apply to the conduct itself, with differences from country to country.
