Running a market TLD for places: who it serves and how
For operators considering a TLD that names places: who would hold a name under it, what they would use it for, and what running it involves.
A namespace built around geography works differently from one built around a brand or a profession. The word at stake is shared by many parties who each have a legitimate, if different, claim: the city authority, the tourism board, the street-level restaurant, and the resident who has lived on a named square for decades. Each of them would reach for a name under a places TLD for a different reason, and none of them can simply be told they have no standing.
If you are considering acquiring a TLD that corresponds to a geographic word (a city name, a regional label, a neighborhood term), this article lays out who your registrants would be, what they would actually do with a name, where the legitimacy questions arise, and what the work of running the namespace looks like month to month. The operators page gives the full framing of what it means to hold and run a market TLD; this article stays specific to what is different when the sector is places.
By the end you should be able to judge whether there is real, sustainable demand among the users you would serve, what governance choices the geography of the word forces on you, and whether the revenue model closes.
Who would hold a name, and what for
Four distinct groups would realistically register names under a places TLD. Their motivations do not overlap much, and a well-run namespace designs for all four rather than optimizing for one.
| Holder type | Primary use | Strength of intent to register |
|---|---|---|
| City or regional authority | Official digital presence and citizen-facing services | High if operator earns recognition; low otherwise |
| Tourism board or destination marketing organization | Destination landing pages, campaign addresses, partner coordination | Moderate; budget-driven |
| Local business | Payment address, storefront, loyalty program anchor | Moderate; depends on wallet and resolution coverage |
| Resident or community member | Personal address, neighborhood identity, collector use | Low to moderate; early-adopter skew |
The table describes the realistic spread. A places TLD does not have a single dominant user class the way a professional sector TLD might have practitioners. That breadth is an asset, because it enlarges the potential registrant pool. It is also a challenge, because the arguments for registering are different for each group and your onboarding has to speak to each one.
The four groups also depend on each other in a fixed order. Businesses and residents register when the official bodies of the place are visibly present, and the official bodies take part only when they trust the operator. A plan that starts with residents and hopes the city follows has the order backwards.
What a name does for city authorities and tourism boards
A city authority that holds cityname.yoursector can use it as a public identifier that others can verify. The record of who holds a name sits on a public ledger, and any member of the public can look it up on a block explorer, so nobody has to take the operator’s word for which name belongs to the authority. That is something a city’s IT or digital-services team can appreciate: it removes one layer of intermediary from the question of who controls an identifier.
In practice, the authority might point the name at a published page, use it as the destination for a payment link tied to a civic service, or hold several names, one per department or service, each issued by the operator. A tourism board operates differently: it tends to run campaigns with short lives and multiple partners. A name under a places TLD gives each campaign a stable anchor address that survives redesigns and partner changes. The board can also nominate accredited partners (hotels, guides, local transport operators) for names that the operator then issues, which gives those partners a visible tie to the official destination identity.
The limit here should be stated plainly: resolution is partial. Onchain names sit outside the ICANN DNS root, so a visitor cannot type cityname.yoursector into an ordinary browser and reach the authority’s page without support. On Freename, names are supported in Bitcoin.com Wallet, in MetaMask through Freename’s resolver, and in desktop browsers through the Freename Web3 extension, and that coverage changes over time. The page on what works and where keeps the picture with its sources. As long as coverage is partial, the authority is managing two presences: the DNS domain it already holds, and the onchain name it is building. For reaching the general public, the DNS is simply better, and some authorities will see the dual overhead as too much. That is not a problem you can design away. It is a constraint you describe honestly when you talk to them.
What a name does for local businesses and residents
For a local business, the most concrete use is a payment address. A name that resolves to a wallet address, trattoria.yoursector for instance, can receive onchain payments without the payer copying a long raw address. A payment router such as shaka lets a payment link pay out to that name, and where several parties share the money, they agree and sign the split onchain before any funds move. The router passes funds along and does not hold them.
Local payments and services
Places produce many small payments with more than one party behind them. A guesthouse booking that arrives through a local guide, a festival stall that owes a share to the organizer, a table deposit at a restaurant: in each case a readable name tied to the place tells the payer who is being paid, and the split settles the question of who gets what before the money moves. The payer still needs a wallet that supports the name, which narrows the audience to visitors and residents who already pay onchain. For most local trade, cards and cash remain the default, and a places namespace adds a channel next to them without replacing them.
Services follow the same logic. A name can stand for a recurring local service, such as a market pitch, a mooring or a guided walk, and serve as the address where it is booked and paid for. The value depends entirely on whether the people who use that service can resolve the name where they already are.
Residents
The resident case is different again. A resident who holds surname-district.yoursector is doing something closer to staking a claim on a personal address in a digital geography. The uses are narrower: receiving funds in a wallet, a recognizable identity in community forums, or simply the collector logic of owning a meaningful string. Resolution in wallets is what matters for residents: if a name resolves in the wallets their community already uses, registration makes sense; if it does not, the value proposition is thin.
Be honest in your projections. Resident demand at launch is an early-adopter phenomenon. It grows if the namespace earns relevance through businesses registering, the tourism board using it and the city authority taking part, and it stays flat or declines if the operator does not build that legitimacy first.
Who is entitled to run a place name
This is the most distinctive governance question in a places namespace, and it has no clean answer that applies everywhere.
In the ICANN DNS, geographic top-level domains (country codes, and strings that correspond to cities or regions) are subject to specific rules, and governments have a formal advisory voice in how new strings are approved. Onchain TLDs exist outside that process entirely, which means the operator carries the legitimacy question directly, without an institutional framework to defer to.
That does not mean anything goes. A .yoursector that corresponds to a recognized geographic term will attract attention from the authority that governs that place. Whether that attention takes a legal form depends on the country: some protect geographic designations by specific legislation, others rely on trademark law, and some have no clear mechanism. Your own counsel decides which of those applies to your situation.
The practical answer is partnership. Approaching the relevant city authority or regional government early, before marketing to businesses and residents, establishes a basis for recognition rather than opposition. That conversation does not require transferring the TLD or sharing revenue by default. It requires a clear agreement about what names the authority holds, what the authority can require you not to issue, and how disputes inside the namespace are handled.
Geographic sensitivity and the DNS precedent
The DNS precedent is worth understanding even though onchain TLDs operate outside it, because it shaped what public authorities expect, and because trademark law follows its own path whatever naming system a name sits in.
In the ICANN system, applicants for certain geographic strings, city names among them, have been expected to show the support or non-objection of the relevant public authority. That standard reflects a political judgment: geographic names are a shared resource, and private operators should not be able to capture them without accountability to the communities they name. An onchain TLD recorded as a token carries no equivalent requirement, but the underlying judgment does not disappear. A city government that objects to a private operator running a namespace under its name has tools: it can issue public statements, refuse to participate, and pursue trademark or geographic-designation claims where local law provides them.
Some countries also protect geographic designations for products linked to a region. Whether that kind of protection reaches services or digital identifiers is not uniform and varies by country. If your TLD corresponds to a term that is or could be a protected designation, get country-specific advice before proceeding.
The flip side of this sensitivity is that it creates a barrier to entry. An operator who has built a legitimate relationship with the relevant authority, published a clear registration policy, and established a working dispute process is in a substantially stronger position than one who simply holds the token. The governance overhead is real, but it is also the thing that makes the namespace defensible.
The operator’s role: rules, issuance, support, disputes
Running a market TLD for places is not passive. On a registry such as Freename, names under a TLD can be issued by its holder and by nobody else, which means every name that exists under it is a decision the operator made, either actively or by omission.
The minimum set of policies a places operator needs before opening registrations:
Registration eligibility. Who can register what? A policy that lets anyone register any string produces a namespace where taxoffice.yoursector is held by a satirist and emergency.yoursector is held by a private party running a paid service. Either outcome damages the namespace’s credibility with the city authority and the tourism board you need on side.
Reserved names. Before the first registration opens, reserve the strings that correspond to official bodies, emergency services, and the place name itself. Those strings should be issued only to verified holders or left unregistered until the right holder appears.
Abuse channel. A form or published contact point where anyone can report a name being used to defraud, impersonate, or mislead. The report triggers a review; the review follows a written policy.
Dispute process. For disputes about who is entitled to a name, you can model your process on the UDRP, the Uniform Domain-Name Dispute-Resolution Policy that governs disputes over ICANN domain names, but you are not bound by it and it does not automatically apply to onchain names. What matters is that the process exists, is written down, is applied consistently, and has a defined outcome.
These policies are the first part of putting the TLD to work after the transfer. If you acquire the TLD before they exist, the gap between acquisition and first registration is the time to build them, not the time to start selling.
Support for registrants who are not technical
A places namespace draws registrants that a technical namespace never meets: a municipal clerk, a cafe owner, a retired resident. Each needs a wallet before a name, and each will ask where the name resolves and where it does not. Plan for support that explains this in plain words, in the language of the place, and that is candid about partial coverage. Support is also where you learn which segment is actually registering, which no forecast will tell you.
Disputes where place and identity overlap
Place names carry emotional weight that sector words often do not. A name under a places TLD is not just a technical identifier; for some holders it is a statement of belonging. That attachment helps the namespace, but it is also a source of friction.
Disputes in a places namespace are more likely to have a community dimension than disputes in, say, a professional-services namespace. A resident who loses a name that corresponds to their street may feel that more acutely than a company that loses a keyword. Your dispute policy needs to account for that: the process should be legible to someone who is not a lawyer, the timelines should be reasonable for an individual, and the outcomes should be explained, not just announced.
One structural protection is worth considering for reserved names: a multisignature wallet, meaning a wallet that acts only when several designated people approve. If the city authority’s name sits in a wallet that needs approval from more than one representative of that body, the risk of a unilateral error, or of one compromised account moving the name, is much smaller. Check what the registry and the wallets involved support before committing to it in your policy.
Revenue from names: a worked example
The revenue model for a places TLD is a royalty on registrations. Freename runs a program that pays the holder of a TLD part of every registration fee for a name under it; the advertised share goes up to half, and the registry’s terms and activation conditions in force decide what applies. The subname revenue calculator lets you model this with your own assumptions. The following worked example uses explicit numbers so the logic is transparent.
Assumptions. A mid-sized regional TLD with a tourism economy. Year-one volume: 400 paid registrations, split as 200 local businesses, 120 tourism partners, 60 residents and individuals, and 20 names for the city authority and public boards. Registration fee paid by the registrant: USD 30, an assumed figure, not a registry price. Royalty share received by the operator: half of the fee, the top of the advertised range, so USD 15 per registration. Only first registrations are counted. No staff, legal or support costs are deducted; those are real and reduce the net figure. The same goes for the royalty program itself: a Freename TLD has no annual renewal fee, but taking part in the program carries an annual cost set by the registry, which is not in these figures and must be deducted. For some TLDs the program is included for life under the earlier terms they were registered on, so a city or region buying one should confirm with the registry, before closing, whether those terms pass to the buyer.
400 registrations times USD 15 equals USD 6,000 in gross royalty income in year one.
Assumptions stated above. The royalty share, terms and activation conditions are set by the registry and may change. Staff, legal and support costs are not deducted.
USD 6,000 in year one is not a business on its own, and with a lower royalty share the figure falls in proportion. The example also shows where the money sits: the 20 official names bring in the least, yet they are the ones that make the other 380 plausible. A places TLD is not a high-volume consumer namespace and should not be modeled as one. The case for running it rests on royalty income combined with the strategic value of holding the namespace for a place where the operator already has a relationship.
Sought-after strings such as hotel.yoursector or market.yoursector raise a separate question. The holder of a TLD sets the price of the names issued under it and can price one string differently from another, so you need a clear policy on how these are priced and who may hold them. In a places namespace, who holds hotel.yoursector is a matter of local fairness as much as revenue, and a published, transparent process is easier to defend than a private arrangement.
What to check before acquiring the TLD
Acquiring a geographic TLD without due diligence on the following points creates problems that compound. None of them is a reason not to proceed; all of them are things to resolve before the token transfers.
Trademark position. Does the geographic string correspond to a registered trademark in any class relevant to the services you intend to offer? Geographic terms are often hard to register as trademarks because they describe where something comes from, but there are exceptions, and rules vary by country. A search in the relevant trademark registers is a minimum. Your counsel decides what it means.
Government stance. Has the relevant city or regional authority made any public statement about digital namespaces, onchain identifiers, or the use of the place name in technology contexts? A favorable stance from the authority is an asset; silence is neutral; active opposition is a material constraint on what the namespace can achieve.
Existing registrations under the TLD. Check the public record for names already issued under the TLD. If names exist, you are acquiring an incumbent population of holders. Review those names: do any of them conflict with the policies you intend to run?
Activation state. A TLD that has never been put to work needs setup: meeting the registry’s activation conditions, and the policies above. A TLD that has been partly set up may carry inconsistencies. The activation roadmap tool builds a launch plan you can hold against what is already done.
Valuation basis. The value of a geographic TLD depends heavily on the size and engagement of the place it names, the operator’s relationship with the relevant authority, and the plausibility of the revenue model. A valuation that makes these inputs explicit is more useful than a comparison with other TLDs, because two places are rarely alike.
A realistic first year
The first year of running a places TLD is primarily operational and relationship-building. Revenue is secondary.
- Secure the TLD and confirm activationClose the acquisition through onchain escrow. Confirm that the TLD meets the registry's activation conditions and that a test name resolves in the supported wallets and browsers. Do not open registrations before this step is complete.
- Draft and publish the registration policyDefine eligibility, reserved names, pricing, and the dispute process. Have the policy reviewed by counsel familiar with how the country treats geographic designations. Publish it before the first outreach.
- Approach the city or regional authorityOpen a conversation with the relevant government body or tourism authority. The goal is recognition or at minimum non-opposition. Reserve the authority's strings while the conversation is open, and offer them on terms a public body can accept.
- Identify and onboard anchor registrantsTourism boards, business improvement districts, and established local businesses that already accept onchain payments make the strongest anchors. A small group of well-known local names gives the namespace credibility before public launch.
- Open general registration with a defined processAnnounce through channels the people of the place actually use. Make the registration flow simple and the support channel visible. Track which segments are registering and adjust outreach accordingly.
- Monitor and enforceRun the abuse channel actively. Any name reported in the first year sets a precedent: how you respond defines whether the policy is real or decorative. Issue your first dispute decisions within the timelines your policy states.
The first year ends with a namespace that has a functioning policy, a relationship with the relevant authority, an anchor registrant base, and a dispute record. Revenue at that point will be modest. What you have built is the footing on which later registrations depend, and nothing in it guarantees that they come.
Before you approach a holder
If you have identified a geographic TLD that you want to acquire, and it is already held by someone else, you can mandate Hush Partners to find and approach the holder: that is the buy-side acquisition service. If you hold a places TLD and would rather pass it to an operator better placed to build the namespace, a holder can mandate the desk to find a buyer. Either way, the exchange is covered by a standard mutual NDA.
The decision of whether to run a places namespace yourself depends on one question more than any other: do you have, or can you build, a working relationship with the authority that governs the place the TLD names? The technical and commercial parts of the operation are learnable. The legitimacy question is not solvable by technical means. An operator with a genuine connection to the place, through an existing business, a civic role, or a long-standing community relationship, is in a far better position than one who holds the token but has no standing in the geography.
So the first step costs nothing and comes before any acquisition: write down who at the authority you would speak to, what you would ask them to recognize, and which names you would reserve for them. If you cannot fill in those three lines, the namespace is not ready to be bought.
Questions people ask
Can the city authority demand that the operator transfer the TLD to it?
In the onchain context, no mechanism automatically compels a transfer. The TLD is held as a token in the operator’s wallet, and a token moves only when its holder moves it. However, a city authority may have grounds under local trademark law, rules on geographic designations, or unfair competition law to seek relief in a court that has jurisdiction over the operator. The outcome depends on the country and the specific facts. Operators who build a cooperative relationship with the relevant authority from the outset reduce this risk; operators who ignore the authority or act adversarially create it.
Does the UDRP apply to onchain names?
The UDRP binds those who register domain names in the ICANN system, through their registration agreements. Onchain names on a registry such as Freename exist outside the ICANN DNS root and are not subject to the UDRP by default. The operator can choose to model its dispute process on the UDRP’s logic (a complainant files, the respondent answers, a panel decides, and the outcome is a transfer or a cancellation), but that is a policy choice, not a legal obligation. What the UDRP does provide is a body of published decisions on geographic names, personal names, and descriptive terms that a places operator can study to anticipate the disputes that will arise.
What happens to names already issued if the operator transfers the TLD?
A name issued to a business, a resident or a public body stays with that holder when the TLD moves to a new operator. Names the outgoing operator holds itself under the TLD can pass to the buyer along with it, if the two parties agree on that. Your registration agreement should state what happens to existing names if the TLD changes hands, and what obligations a successor operator takes on. A city authority will ask this question early, because its own names are at stake. Anyone acquiring a TLD with an existing registrant base should review those obligations before closing.
Can the operator protect the place name as a trademark?
Geographic terms are generally treated as descriptive, and many trademark offices refuse them for services connected to that geography. An operator is unlikely to obtain a trademark in the place name itself. Acquired distinctiveness, where a term has come to be associated with one operator’s services through long use, is possible in principle in some countries but requires evidence of sustained use that a new namespace will not have. Your counsel decides what protection is available and through what mechanism.
