Running a market TLD for events: who it serves and how

A sector TLD for events sits at an unusual intersection: the industry already runs on identity. Every festival, conference, stadium show and trade fair has a name, a venue, a box office, a lineup of suppliers and, in the end, an audience. The question is whether adding an onchain layer to that identity creates enough value for enough people to justify building and running a namespace.

This article works through that question group by group. It identifies who would register a name under a hypothetical .yoursector TLD, what each of them would actually do with it, where the real demand lives and where it is thin, what breaks under load, and what it costs in time and judgment to operate the TLD responsibly. By the end you should be able to decide whether a namespace in this sector is worth acquiring and, if so, what a credible first year looks like.

The operators page covers the general role in more depth. This article is about what is specific to events.

Who would register a name, and how durable their demand is

Before modeling revenue or drafting registration rules, an operator needs to understand who is actually motivated to register. In events, four groups stand out, but their motivations differ sharply and so does the durability of their demand.

Organizers are the anchor registrants. They have a professional reason to hold a persistent onchain identity: contracts with artists, agreements with suppliers, revenue splits and ticket proceeds all involve parties who need to know where to send money. A name that resolves to a wallet is more useful than a raw address because it is readable by a human and carries over from one edition of an event to the next.

Venues sit close behind. A venue that hosts events week after week has a continuous need to receive funds from many organizers, settle with its own suppliers and show a clean payment trail to its auditors. A stable name under .yoursector gives its finance team one identifier to publish, even when the wallet behind it is replaced and the name is pointed to the new one.

Ticketing services have a narrower but real use case: receiving proceeds from ticket sales and passing on the organizer’s share while keeping a service fee. The name is the payment endpoint that appears on receipts and in the terms of a smart contract, the program on a blockchain that executes a transfer when its conditions are met.

Attendee demand is the weakest of the four and deserves honesty. Many attendees do not hold a wallet at all. Among those who do, the incentive to register a name under a sector TLD is low unless the organizer actively requires it, for instance to control resale or to issue proof of attendance. Attendee names are therefore a downstream consequence of organizer adoption, not an independent source of demand. An operator who projects large attendee registration volumes in year one is projecting something fragile.

What a name would do, concretely

A name under .yoursector, issued on the Freename registry, is an onchain record held in a wallet. The holder can point it to a wallet address and, where the software in use supports it, receive payments to the name instead of to a long string of characters. For an organizer’s box office or a supplier paying to a name, three places support Freename names: Bitcoin.com Wallet, MetaMask by way of Freename’s resolver, and desktop browsers that have the Freename Web3 extension installed. That support covers part of the wallets and browsers people use, and the list moves over time. An operator should say so plainly in its registration terms and never promise that a name resolves everywhere. The capabilities that work now are tracked on the site with their sources.

For an organizer, the practical uses are:

Payment receipt. summit.yoursector receives ticket proceeds from the box office. An onchain payment router such as shaka lets a payment link pay out to names in place of raw addresses, with the shares of the organizer, the venue and any co-producer agreed and signed onchain ahead of any movement of funds. The router passes the money on and never keeps custody of it.

Contractual anchor. When an organizer engages artists, speakers or production suppliers, the contract can name summit.yoursector as the payer in place of a wallet address that may change. That small move reduces the risk of a payment being traced to, or expected from, a stale address, and it leaves a record both sides can read.

Website and credential publishing. Where resolution is supported, the name can also point to an event page published on IPFS, a network that stores files by their content instead of on one server. This is supplementary. The ICANN DNS remains the better choice for a public-facing website, because every browser opens it, and an operator should not overstate the web publishing use case.

For a venue, the name works similarly as a stable inbound payment address and a booking identity. For a ticketing service, it is the destination that appears in onchain payment terms. For an attendee, when the use case exists at all, it is an identity tied to a wallet that can hold proof-of-attendance tokens or qualify for resale permissions set by the organizer.

Event names that expire and organizer names that persist

One design question is specific to an events namespace: whether names should be short-lived or lasting.

An event itself is bounded in time. A three-day festival held in summer has little use for its onchain name by autumn. A name registered for the period around the event and then released is tidier for the namespace and cheaper for the registrant. It also leaves a trace: the name was held, transactions passed through it, and that history stays public on the block explorer.

An organizer’s identity, by contrast, benefits from permanence. If summit.yoursector is the payment address for an annual conference, the organizer wants that name to persist between editions so that contracts, split agreements and payment history remain anchored to the same identifier. Changing the name each year breaks continuity.

An operator running .yoursector should therefore consider two kinds of registration: a short-lived name at a lower price, valid for a defined period around the event, and a lasting name for organizers and venues. The two prices are the operator’s to set: the holder of a TLD decides what names under it cost and can price an event name differently from an organizer’s lasting one. How duration and renewal are set depends on the terms and tooling of the registry, so confirm that before you design the offer. What the operator must think through in any case is what happens when a short-term name lapses: whether it becomes available immediately, is held in reserve, or goes through a waiting period during which the previous holder or a rights owner can object.

That choice matters more in events than elsewhere, because a lapsed event name still carries the reputation of the event. If the name of last season’s festival can be registered by a stranger the day after it lapses, the next edition’s ticket buyers may meet it. A reserve period, or a right of first refusal for the previous holder, costs the operator little and protects the organizers it wants to keep.

Short-lived names also keep the namespace clean. Events are created and abandoned constantly, and a TLD that never retires anything will accumulate names that point nowhere.

Tickets, resale and proof of purchase

Resale is the part of ticketing where trust is weakest: a buyer on a secondary market often cannot tell whether a ticket is genuine or has been sold more than once. A namespace does not fix that problem by itself, but it can make some of the mechanics cleaner.

Consider what a ticketing service registered as boxoffice.yoursector could do. When a ticket is issued as an onchain token and the purchase is recorded against the buyer’s wallet, the proof of purchase can be checked without relying on the ticketing service’s own database. If the organizer writes resale conditions into the ticket’s smart contract (a price cap, a transfer restriction, a share that returns to the organizer on each resale), those conditions execute as written wherever the contract itself governs the transfer. The organizer’s name can appear in those terms as the beneficiary, so the returning share has a readable destination.

That last qualification is important. Conditions written into a contract bind transfers that pass through the contract. They do not bind a private arrangement between two people who hand over a wallet, and how a given resale venue treats such conditions is its own decision. Consumer rules on ticket resale also differ from country to country, so the organizer’s counsel decides which conditions are lawful where the event takes place.

Proof of attendance is a related mechanic. Once a ticket has been scanned at the door and marked as redeemed onchain, the wallet that held it carries an attendance record that others can check. That record is controlled by the attendee, not locked in a single service. For conferences and professional events, where attendance can count toward a credential, this is a concrete benefit. For concerts, it is a collectible: meaningful to some, irrelevant to others.

The operator should not overstate what the namespace adds here. The ticketing logic, the issuing of tokens, the resale rules and the scan at the gate all depend on the ticketing service’s own integration. The name is an identity layer on top of that infrastructure, not a substitute for it. An operator who acquires .yoursector expecting it to end ticket fraud on its own is misreading what a TLD does.

Payouts to artists, venues and suppliers

The payment side of live events is complex. A single show may involve an artist and their management, a booking agent, a venue, a production company, a caterer, a merchandise licensee and a streaming partner, each owed a share of revenue under agreements negotiated separately. Settlement commonly happens after the event, through several separate transfers, and the parties do not share one record of who was paid what.

An onchain name simplifies one part of this: it gives each party a stable, readable payment address that can appear in the terms of a split before any money moves. Applied to events, the artist’s manager is named as artistname.yoursector for the artist’s share, the venue as venue.yoursector, the production company under its own name. Each party can read the split and see its own name in it before agreeing. When the box office releases proceeds through a payment router, the amounts follow the split that was agreed and signed onchain beforehand, which removes one common source of argument after the show: nobody has to reconstruct what was promised.

It does not remove the others. A split fixes shares, not the facts the shares depend on. If the artist’s fee rises above a certain attendance, someone still has to establish the attendance. If a supplier delivered late, the dispute about that is commercial and no name settles it. The honest claim is narrow: the destination and the share are fixed in advance and visible to all parties.

This is the use that gives an events namespace its strongest concrete value. It is also the use most dependent on the parties actually holding wallets and being willing to receive funds onchain. An operator should expect adoption to be gradual, led by organizers comfortable with onchain tools and their immediate counterparties, before it reaches the full supplier chain, if it ever does. Many suppliers will prefer a bank transfer for a long time, and the namespace has to be useful alongside that preference. The page on payments to a name explains the mechanics in more detail.

Demand peaks and what they break

Events have an unusual load pattern: registrations and payments cluster tightly around on-sale dates, event dates and settlement windows. A namespace that sees a steady trickle of registrations for most of the year will face bursts many times larger during those windows.

For an operator, this has practical consequences. The registry handles the onchain record, and a TLD operator does not run that layer. But the operator does run everything above it: the registration interface it offers, the support queue, the intake of disputes, and any integration with ticketing services or payment routers. When thousands of attendees try to register names in the hours after a large festival, the operator’s interface and support capacity determine whether the experience is credible.

Most operators of a sector TLD will not have the capacity to absorb a burst of that scale at launch. The practical answer is to launch with a narrower scope: serve organizers, venues and ticketing services first, hold off on opening attendee registration until the system is proven, and work with one or two willing organizers whose events are modest in size. Expand once the system has shown that it holds up.

There is also a peak on the money side. Settlement of ticket proceeds may involve large onchain transactions within hours of each other. If payment to names is part of what the namespace promises, the operator needs to have tested resolution and routing under realistic conditions, with the wallets its registrants actually use, before presenting it as a feature.

Support peaks at the worst moment too. An organizer whose name does not resolve in a supplier’s wallet on the afternoon of the show needs an answer within the hour, not the next business day. An operator who cannot staff the days around its registrants’ events should say in its terms what response time it does offer.

The operator’s role: rules, issuance, support and disputes

Running .yoursector is not passive. The operator sets the registration policy, decides who receives a name, fields support requests, and makes judgment calls when names are abused. These responsibilities are heavier than they appear from the acquisition side.

Registration rules. The operator decides who can register. In events, a plausible policy is to ask registrants to state their role: organizer, venue, ticketing service or individual. Verification can be light (a declaration at registration, with checks reserved for disputes) or heavier, such as asking for evidence that the registrant runs the event or the venue it names. The right level depends on how much the operator values the quality of the namespace against the volume of registrations. In a sector where a name stands for a place people will pay to enter, quality deserves the greater weight.

Issuance. On Freename, issuing names under a TLD is reserved to whoever holds it, so the operator is the gate for every name under .yoursector. The price of a name, which the holder sets, and the registry’s royalty program are the two levers that decide what the holder earns, and the program’s terms and activation conditions are set by the registry, not by the operator. Read them before you model anything.

Support. Events produce real edge cases: an organizer who registered an event name and then canceled the event; a ticketing service that registered a name and then ceased trading, leaving payment terms pointing to it; an attendee who lost access to the wallet that held their proof of attendance. The operator needs a process for each of these. It does not need to resolve them all in the registrant’s favor, but it does need a published policy and a way to receive and answer requests.

Disputes. Name conflicts in events are frequent. Two organizers may independently use the same event name in different cities. A festival name may be a registered trademark of a third party who did not register under .yoursector. A ticketing service may register a name that another service claims to have used first. The operator is not a court, but it must have a dispute policy that explains what evidence it considers and what outcomes are possible.

Have counsel review the registration terms, the prohibited-use policy and the dispute policy before registration opens. How far an operator answers for what its registrants do varies by country, and that question belongs to your own lawyers, not to this article.

Revenue from names: a worked example

The Subname Revenue Calculator takes inputs and returns projections. This section works through the logic by hand so you can see where the levers are. It is a worked example, not a forecast, and every assumption is stated here:

• The operator sets a registration price of USD 40 per name per year, and names are renewed yearly at the same price.
• Freename’s royalty program gives the holder of a TLD a share of each registration fee paid for names under it, advertised at up to half and subject to the registry’s terms and activation conditions. The example assumes the full half applies, which is the ceiling and not a given.
• The operator serves three registrant types: event organizers, venues and ticketing services. Attendee registration is not open.
• 400 names are registered in year one. In year two, 900 names are registered in total, renewals and new names together.

These numbers are modest, and they are before any cost. The first cost is 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 the table leaves out and which comes off the holder’s share. An event operator buying a TLD should check how it was registered, since some carry earlier terms that include the program for life, and should have the registry confirm before closing whether those terms pass to the buyer. Support, dispute handling and the registration interface are paid out of the holder’s share. One part-time person answering requests around event dates would absorb most of the year one figure in many places.

The levers move the result in plain ways. Halve the price to USD 20 and the year one share falls to USD 4,000 for the same 400 names. Apply a share below the ceiling and the result falls in proportion. Short-lived event names, priced lower by design, add volume but less fee per name, and they bring their own support load at the moments of peak demand described above.

The example also shows what the result depends on. A sector TLD for events does not produce meaningful royalty income from a standing start unless the operator has a distribution channel (a ticketing integration, a membership base, a relationship with a group of venues) that delivers registrations without each organizer having to discover the namespace alone. An operator without such a channel should treat 400 names in year one as ambitious, not conservative.

How a TLD valuation is built is a separate question from the first years of fees. Registration income is one input among several, and a buyer who pays for a sector TLD on the strength of a projected fee stream alone is relying on the weakest part of the case.

What to check before acquiring the TLD

Acquiring a sector TLD is not the same as launching a business in the sector. The TLD is infrastructure. Whether it produces value depends on a set of prior questions that should be answered before any money changes hands.

Does the word have trademark exposure? A sector word can also be someone’s registered mark, in events or in another field. The UDRP, the dispute policy that binds registrants of domain names in the ICANN system, does not extend to onchain TLDs, but trademark law does not depend on it: a rights owner can still act under the law of the countries where the mark is protected. Search the word in the trademark registers of the countries where your registrants operate, and let your counsel assess what the search returns. The same applies, later, to the event names your registrants ask for.

Is the TLD already held, and in what state? On Freename, the registry record is public and can be read on a block explorer. Check whether the TLD you want is already held and whether names have been issued under it. A TLD with names in active use is a different acquisition from one that has never issued a name: you inherit registrants, their expectations and any commitments made to them. When the TLD is held, an organization can mandate a desk to find and approach the holder, which is what the buy-side acquisition service describes.

What is the governance structure? An association running a sector TLD answers to its members. A commercial operator answers to its investors. A ticketing or event service answers to its users, and its competitors may hesitate to register under a namespace it controls. Each of these constrains how you can set prices, dispute policies and rules. In events, the last point is the sharpest: a namespace run by one ticketing service is unlikely to be adopted by the others unless its rules are visibly neutral.

Who is your first cohort of registrants? A namespace without a committed first cohort is an empty room. Before acquiring, identify a named group of organizers, venues or ticketing services who have confirmed they would register and say what they would use the name for. Their identity need not be public, but they need to be real.

Can you handle the operational load? Support, dispute handling and issuance require staff time or a contracted provider, and in events the load arrives in peaks. Estimate the hours before you acquire, not after. The Launch Roadmap tool helps lay out what the first twelve months of operation require.

A realistic first year

The instinct when launching a namespace is to announce it broadly and invite everyone to register. In events, that instinct produces a poor outcome: a namespace full of names registered by people who have no intention of using them, including names of events they do not run, and without the organizers and venues the namespace needs to be credible.

A better first year is narrower and more deliberate.

1. Close and set up the TLDComplete the acquisition, check the registry record on a block explorer, set the registration price, and confirm the royalty program's conditions and annual cost with the registry. Test resolution and payment to a name in the wallets your registrants use before anyone is invited.
2. Register anchor namesRegister names for the operator itself and for two or three anchor partners (an organizer, a venue, a ticketing service) who have agreed to take part. These names show the namespace in use and give you real feedback before you open registration more widely.
3. Run a closed first cohortInvite a defined group of organizers and venues to register. Keep the group small enough that every support request gets a careful answer. Income is not the goal at this volume; evidence of use is.
4. Go through one full event cycleFollow at least one partner event from on-sale to settlement. Record what fails: a wallet that does not resolve the name, a disagreement over who should hold an event name, a payout that had to fall back to a bank transfer. Resolve each one before expanding.
5. Open broader registration with published rulesOnce the system has run cleanly through that cycle, publish the registration policy, the dispute policy, the rule for lapsed event names and the pricing. Open registration to organizers, venues and ticketing services more widely, and decide separately whether attendee names are ready.
6. Review before the second yearCompare renewals, dispute volume and income with your own model. Adjust the price only if use supports it. Begin conversations with ticketing services about registering names for the organizers they serve.

The test of year one is not registration volume. It is whether the names that were registered are in use (receiving payments, appearing in contracts, resolving in wallets) by the time the first renewals come due. A namespace with a few dozen names in active use is stronger than one with several hundred dormant ones, and it is the first that a ticketing service will agree to integrate.

The work that follows the transfer is described under post-transfer activation. If the TLD you have in mind is already held, Hush Partners can act under mandate to find and approach its holder, with one named partner following the file from the first note to closing and closing carried out through onchain escrow on an aftermarket. A standard mutual NDA applies to every exchange, and the desk is reached through the contact form.

Questions people ask

Does an attendee need a wallet to use proof-of-attendance features?

Yes. A name or a token that proves attendance has to be held in a wallet. For most consumer events, this is a real barrier. The practical path is for the organizer or the ticketing service to make wallet creation part of the purchase, which is their design decision and their integration work. The operator of the namespace does not control it and should not plan attendee volumes as if it did.

Can the operator prevent a name from being sold or transferred to a third party?

A name issued under a TLD is held in a wallet, and what is held in a wallet can generally be moved. The operator can restrict transfers in its registration terms, but that is a contractual rule, and its technical means of acting on a name after issuance depend on the registry. Confirm those means before writing the rule, and state in the terms what the restriction means in practice. For event names this matters: an organizer who sells an event will want the name to follow it, and the terms should allow that case.

Is an events TLD better as a commercial operation or as an association-run namespace?

Neither model is better in itself. A commercial operator moves faster and prices more freely. An association has a member base and standing within the sector, which helps adoption. The risk for an association is that its governance slows decisions; the risk for a commercial operator is that, without relationships in the sector, registrations stay low. The answer depends on whether the operator has a distribution channel into the sector and the capacity to run the namespace responsibly.

Should an event still keep its ordinary domain name?

Yes. An onchain name is resolved by the wallets and browser extensions that support its registry and by nothing else, because it sits outside the ICANN DNS root. Ticket buyers arriving from a search engine or a poster need an address every browser opens, and that is a DNS name. An events namespace is an additional layer for onchain uses such as payments, resale permissions and credentials. Operators who say so from the start set better expectations and attract registrants who have a real use for the name.