What an onchain name proves, next to a certificate

Three signals compete for the same small patch of user attention. A padlock in the browser’s address bar. A badge next to a social handle. A name issued under a top-level domain your organization controls. Each one costs effort to obtain. Each one looks, to a general audience, like a mark of legitimacy. Yet they are different instruments: they verify different things, by different methods, through different chains of trust. Confusing them leads to gaps in how you deploy them and to misplaced confidence when you rely on them.

This article takes each signal apart: what it verifies, who does the verifying, and what a user can check independently. It then turns to the harder problem, which is what none of them proves alone and what an organization must do to close that gap.

By the end you will be able to state precisely what each signal commits you to, choose the right one for a given purpose, and explain the difference to a colleague who asks why a name under .yourbrand is not simply “the same thing as a padlock, but onchain.”

The question every counterparty is really asking

When a user arrives at a payment address, a website or a social profile, the underlying question is almost never “is this connection encrypted?” or “does this account have a badge?” It is: am I dealing with the organization I intended to reach, or with someone who has dressed to look like it?

That question has two distinct parts. The first is technical: does the server, account or name I am interacting with belong to the party that presents it? The second is organizational: is that party the counterparty I trust, or a convincing imitation? Technical signals can answer the first part well. The second is harder, and no single signal answers it alone.

The distinction matters because every one of these signals can be genuine on its own terms and still say nothing about the party behind it. An imitation website can carry a valid certificate for its own domain, and the browser displays the padlock as it would for anyone else. A social account can, on some platforms, obtain a badge without any check of organizational identity. An onchain name can be issued under any TLD, including one whose string resembles a well-known brand. In each case the signal is technically correct. It is the reading of it that goes wrong.

The job of a legal, security or product team is therefore not to pick the “strongest” signal. It is to know exactly what each one asserts, so that nobody inside the organization, and nobody dealing with it, reads more into a signal than it carries.

What a web certificate proves

A web certificate, usually called a TLS certificate after the protocol that uses it, is a digital document that binds a website identity (in practice a DNS name) to a public key. It is issued and signed by a certificate authority, an organization whose job is to vouch for that binding. On every connection, the browser checks that the certificate presented by the server was issued by an authority it already trusts, either directly or through a chain of intermediate authorities, using the list of trusted authorities that ships with the browser or the operating system.

What the padlock tells a user is narrow but precise. The server on the other end holds the private key that matches the certificate, an authority the browser recognizes has vouched for the link between that key and that domain name, and the connection is encrypted. The certificate gives the browser a reason to believe it is talking to the domain in the address bar and not to an intermediary sitting between the two.

The three levels of vetting

Certificates come in three validation levels: domain validation, organization validation and extended validation. They differ in how much the authority checks about the applicant. They do not differ in the strength of the encryption.

Domain validation is the most basic level. The applicant shows that it controls the domain name, typically by placing a file or a DNS record at a prescribed location. The check is technical and usually automated. Nobody at the authority confirms who the applicant is.

Organization validation adds a check that the organization named in the certificate exists and is the party applying. Extended validation goes further, with documented checks against company registers and similar records. The detail of these checks is set by industry rules and can differ between authorities, so treat this as an outline.

The implication for brand teams is significant. A padlock alone does not tell a user whether any check of organizational identity was performed. Domain validation is the common case: the padlock is present and the organization is not verified. A careful user can open the certificate details and see which level applies, but very few ordinary users ever do.

What the padlock does not prove

The certificate proves control of a domain and possession of a key. It does not prove that the organization behind the domain is the one the user has in mind, unless the certificate is of a higher validation level and the user reads the organization fields. It does not prove that the content of the site is legitimate. It says nothing about commercial intent or reputation.

The padlock is still indispensable. Without it, nothing else on the page can be relied on, because the page itself could have been altered on the way. It is the floor of web trust, not its ceiling.

What a platform’s verified badge proves

A verified badge is a small icon, often a checkmark, displayed next to an account name on a platform. It signals that the platform has checked something about the account. The badge is awarded by the platform itself, not by a neutral third party. Its meaning is therefore bounded entirely by the platform’s own criteria, and those criteria vary widely.

On some platforms, verification involves identity documents, review by staff and evidence that the account is the authentic presence of a known person or organization. On others, it follows from a paid subscription with lighter checks. A badge on one platform is not equivalent to a badge on another, even though both look much the same to a user. Criteria also change over time, so the same icon can mean different things in different periods on the same platform.

What the badge covers, and what it does not

On most platforms the badge is a status attached to an account. The account passed whatever check the platform applies, and the badge stays until the conditions stop being met. It says nothing about any individual post or message sent from the account.

The badge also lives entirely inside the platform. It covers the account on that platform. It does not extend to a website, a payment address, an email or any other channel the organization runs. A user who receives a message outside the platform cannot check the sender’s badge. The most they can do is compare what they received with what the badged account itself publishes.

Where a badge does reflect an identity check, it confirms authentic presence on the platform. It is not an endorsement by the platform, and it does not confirm the organization’s legal standing or reliability beyond that narrow claim.

What a name under a TLD proves: control of a namespace

An onchain TLD works on a different model. On the Freename registry, for instance, a TLD exists as a token recorded onchain and sits in a wallet. Whoever holds the TLD is the only party able to issue names under it. A name such as pay.yourbrand or app.yourbrand exists because the holder of .yourbrand chose to create it.

The registry record is public. Anyone can check it on a block explorer, a public website that indexes what is recorded on a chain. No certificate authority, no platform and no editorial review stands in this chain of trust. The record is simply there to be read by anyone.

What a name under a TLD proves, precisely, is control of the namespace. If you see pay.yourbrand, you know that the name was issued by whoever holds .yourbrand. The name is not a forgery within the namespace. Nobody else could have placed it there.

That is a real property, and neither of the other two signals has it. A certificate says nothing about how the names of an organization relate to each other. A badge covers one account. A namespace is a boundary: everything inside it comes from one holder, and a user who has learned to trust the TLD can extend that trust to every name under it without a new check each time.

What namespace control is not

Namespace control is not organizational identity. Knowing that pay.yourbrand was issued by the holder of .yourbrand is useful only if you already know, from some source outside the registry, that the holder of .yourbrand is the organization you trust.

The registry record shows wallet addresses and transactions. It does not show legal names, company registration details or trademark registrations. A user who sees a name under .yoursector resolve in a wallet that supports onchain names sees that the name works. They do not learn who holds .yoursector, or whether that holder is the party they meant to reach.

This is the structural difference between a certificate and an onchain name. With a certificate, a recognized intermediary stands between the site and the user, and the browser already trusts that intermediary before the user arrives. With an onchain name, there is no intermediary of that kind. The chain goes from the name to the TLD to the wallet, and stops there. The step from the wallet to the organization is not recorded in the registry.

The missing link: connecting the namespace to the organization

A TLD that matches your brand is a strong namespace signal only if a user can confirm, independently, that .yourbrand is yours. The registry record establishes that a name was issued by the holder of the TLD. It does not tell a stranger who that holder is.

This is not a weakness unique to onchain names. A domain name in the ICANN DNS has a registrant record as well, and that record is often not visible to the public. Higher levels of certificate validation bridge the gap formally, but they are not the norm. The practical difference is habit. Users have had a long time to learn that a familiar domain name probably belongs to the brand it spells, and they hold that belief without checking anything. Names under an onchain TLD do not benefit from the same habit, and it would be unwise to assume it.

The answer is attribution: making the link between the namespace and the organization visible through channels where the organization’s identity is already established and beyond reasonable dispute. Without attribution, a name is a label. With attribution, it becomes a signal with something behind it that a third party can check.

Organizations that use an onchain TLD for payments to a name, for websites published on the TLD or for agent identities meet this problem at launch. It is solvable, but it requires deliberate action. The namespace alone does not close the loop.

There is also a question of direction. Attribution has to run from the organization to the namespace, not the other way. A page reached through a name under .yourbrand that says “this is the official namespace of the organization” proves nothing, because the holder of any TLD can write that sentence. The statement only carries weight when it appears somewhere the organization alone controls and where users already expect to find it.

How an organization makes the link: publishing on channels it already controls

The most reliable way to connect a namespace to an organization is to publish the connection where the organization’s identity is already established. The logic is corroboration: a statement becomes more credible when it can be confirmed from several independent directions.

Consider an invented scenario. A mid-sized manufacturer has acquired .yourbrand and issues pay.yourbrand for supplier payments. The TLD is recorded onchain, and anyone can read the registry record on a block explorer. But a new supplier who receives payment instructions containing pay.yourbrand cannot confirm, from the registry alone, that .yourbrand belongs to this manufacturer and not to another party holding a similar string.

The manufacturer’s answer is to publish the name in every channel where its identity is already confirmed:

• The official website at its established DNS domain, on a page specifically about payment instructions
• Supplier contracts and formal correspondence that reference the onchain name explicitly
• The organization’s official social profiles, including accounts that carry a verified badge

Each of these channels has its own anchor of trust. The website carries a certificate. The social profiles carry badges. The contracts carry legal standing. None of those anchors is transferred to the onchain name by the act of publishing. What publication does is create a public record, across several channels, that this organization has claimed this namespace, available to anyone doing due diligence.

The step is practical and inexpensive. It needs no new technology and no new legal instrument. It needs a policy decision: namespace attribution is part of the launch, not something added afterwards.

The wording of the statement deserves care. It should name the TLD exactly, say which names under it are in use and for what purpose, and say what the organization will never ask a counterparty to do through a name. A supplier who has read “payment details are only ever confirmed in the contract and on this page” has a rule to apply, which is more useful than a general assurance.

For organizations planning how a TLD is put to work after the transfer, attribution belongs in the first phase: before names are issued at scale, before payment instructions go out, and before the namespace appears in external communications.

Combining signals: what a layered approach looks like

The three signals are not substitutes for each other. They answer different questions, and the most robust onboarding flows use more than one. The table sets them side by side.

No cell in this table contains “trustworthiness.” None of these signals certifies it. Trustworthiness is built from reputation, legal standing, commercial history and obligations met over time. Signals let an existing trust be carried to a new channel. They do not create it.

For an organization that deploys pay.yourbrand for business payments, the layers fit together as follows. The registry record establishes that the name was issued by the holder of .yourbrand. The organization’s website, at its established DNS domain and under a certificate of a higher validation level, states that .yourbrand is its onchain namespace. Contracts with counterparties name pay.yourbrand as an authorized payment identifier. The official social profiles point to the same statement.

Each layer answers a different part of the question. Together they close the gap between “this name was issued by the holder of the TLD” and “that holder is the organization I trust.” Colleagues who need a common vocabulary first will find TLD, subname, wallet, resolver and block explorer defined in the glossary.

To whom each signal speaks

The signals also differ in their audience, and this shapes where each one earns its place.

The padlock speaks to software first. The browser performs the check and shows the result, and the user is protected without doing anything. It reaches everyone who uses a browser, which is why it remains the base layer for any public website.

The badge speaks to people inside one platform. It is read at a glance by a general audience and is useful exactly where that audience already is. It carries no weight in a procurement file or a contract.

A name under a TLD speaks to two audiences. The first is software that resolves onchain names, such as a supporting wallet, where the name replaces a long address a person would otherwise have to compare character by character. The second is a counterparty doing due diligence, who can read the public record directly. It does not yet speak to the general web audience, because an ordinary browser does not open onchain names without support.

Choosing which signal to rely on for a purpose starts from that audience. For a public website, the certificate does the work and a name adds an identifier. For a payment between businesses that already have a contract, the name and the contract do the work together. For a general consumer audience on a social platform, the badge is what will be seen, and the namespace statement should be reachable from the badged profile.

What none of them proves

Every trust signal is a snapshot. Each describes a state of affairs at the moment of verification. None proves that the state persists, that the organization remains reliable, or that the specific transaction in front of you is legitimate.

None proves permanence

A certificate expires and must be renewed. An organization can lose a DNS domain through a lapsed registration or a loss of account access, and a new certificate can then be issued to whoever controls the domain. A badge can be withdrawn, or its meaning can shift when the platform changes its policy. An onchain TLD can be transferred. The registry record will show the new holder, but a user relying on an old mention on a website will not learn that the holder has changed unless the statement is updated.

None proves authorization

The party that controls a domain, holds a badge or holds a TLD is not necessarily authorized to carry out the specific transaction you are asked to complete. Whether a person may bind the organization, change payment details or accept an order is a matter for contracts, mandates and corporate governance, not for naming or identity signals.

None proves that access is still in the right hands

Access to a wallet can be lost or misused, just as access to a DNS account or a social account can. The fact that a name was issued by the holder of the TLD remains true. It says nothing about whether the issuance followed the organization’s own internal process. This is one reason organizations often hold valuable tokens in a multisignature wallet, a wallet that needs several approvals before anything moves, and treat the issuance of names as a controlled operation with its own record.

The practical conclusion is that signals are inputs to a decision, not the decision. A team that understands what each one proves will combine them with counterparty due diligence, contractual authorization and monitoring, instead of using them in place of those controls. For the passage of time in particular, one answer is to keep watching: namespace watch is the service of the desk for monitoring the names of a brand onchain.

Where the DNS remains the better instrument

It would be wrong to present the three signals as equals in every setting. For reaching the general public through a browser, the DNS and its certificates are simply better. They work everywhere, with no extension and no explanation.

A name under an onchain TLD is not part of the ICANN DNS root, which is why a standard browser needs added support before it can open one. Freename names resolve in Bitcoin.com Wallet, in MetaMask through Freename’s resolver, and in desktop browsers that have the Freename Web3 extension installed. That coverage is partial and it changes. An organization should not design a flow that assumes every user can resolve a name.

It follows that a name under your TLD does not replace your certificate or your domain. It adds something the other two do not offer: a namespace whose every entry comes from you, readable in a public record, and usable where onchain names are supported. The sensible position is to keep the established channels as the anchor and let the namespace draw its attribution from them.

Practical steps for brand and legal teams

The analysis leads to four actions for an organization that works with, or is evaluating, names under an onchain TLD.

First, review what you have already published. If your organization holds a TLD, check whether you have explicitly linked it to your identity on your website, in your contracts and in official communications. If you have not, the namespace does not yet carry its full weight as a signal, however well it resolves.

Second, decide how much attribution each use needs. For names used in payment flows, namespace control alone is not enough: you need an explicit contractual reference and a published statement. For names used in wallet resolution or agent identity, the bar depends on the counterparty and on what is at stake. The page on what is live sets out, with sources, which capabilities of onchain TLDs work. Knowing what resolves, and for whom, tells you how far a name will be seen and therefore how much attribution effort it justifies.

Third, plan for change. Record the state of your namespace attribution and when each statement was published. Build a process to update it when a TLD changes hands or when names are issued for new purposes. If the question is whether a TLD of interest matches a mark, the page on trademark TLDs explains what a trademark TLD is and holds the free Trademark Name Check form.

Fourth, brief your counterparties. The gap between “this name was issued correctly” and “this is the organization I trust” is closed by publication and by explanation. Suppliers, partners and their counsel who understand what an onchain name proves, and what to check to confirm the link to your organization, are far less likely to be misled by a namespace that resembles yours.

If the TLD that matches your brand is held by someone else, attribution is not yet your problem to solve: the namespace is. Hush Partners is a private desk for onchain TLDs, and an organization can mandate it to find the holder and make the approach. A standard mutual NDA applies to every exchange, and the way to reach the desk is the contact form.

Questions people ask

Does issuing a name under our TLD count as proof that we own the underlying mark?

No. Issuing a name under a TLD demonstrates control of the namespace, not ownership of a trademark. Trademark rights depend on registration, on use, or on both, according to the country, and none of that is recorded in a registry entry. Whether a namespace has any bearing on a specific dispute or enforcement action is for your own counsel to decide.

Can a counterparty check an onchain name without specialized software?

Reading the record needs nothing special: a block explorer is an ordinary website. Using the name is different. Opening an address or sending funds to a name requires a wallet or a browser extension that supports it, whereas the certificate check happens automatically in every browser. Before telling counterparties what they can do with a name, confirm which tools support it against the registry’s own documentation.

If we publish our onchain name on our website, is that sufficient attribution?

It is a strong start. Whether it is sufficient depends on the use. For informational uses, a single published reference may be enough. For payment instructions or contractual identifiers, the name should also appear in the contract itself and in official correspondence. Attribution is a risk management question, and the threshold is one your own legal team sets in light of the counterparties and the amounts involved.

Who is responsible if a name is misused under our TLD?

This is a question for your own counsel, and the answer varies by country. As a general matter, the holder of a TLD decides which names are issued under it and carries the governance risk that comes with that control. The terms of the registry, the place where the organization is established and any agreement between the holder and the parties using names all bear on the answer. An internal rule on who may issue a name, and for what, is the first thing an adviser will ask to see.