Designing a Name Service - Part 5: Retaining Trademarks

This article is also available as part of our Tezos Name Service publication on Medium. That’s where you can find our future articles on the topic as they become available, but we will post them here too for easy discussion.

In our previous article Name Distribution And Pricing, we covered the topic of creating a fair system for generic names. These names could be defined as names to which everybody has the same right or no right at all. In this article, we are trying to explore the options for registering names based on verifiable claims.

Verifiable claims can be defined as claims based on demonstratable real-world possession of any kind. We can imagine brand names like “BMW” or “Tezos Foundation” to be verifiably claimable. Related names could be reserved for the owners or offered to them preferentially.

One of the biggest challenges in integrating external systems is the verification process. A reliable and trusted connection must be established between TNS and an external system. Using distributed oracles might be a reasonable approach. Integration can be added, when oracles are available on Tezos. TNS domain pricing must include a margin for oracle costs.

Names that require verified claims should be rented/sold using a flat-fee price model because there is no competition involved.

Here are some examples of systems usable for verifying claims:


A trademark is a sign capable of distinguishing the goods or services of one enterprise from those of other enterprises. Trademarks are protected by intellectual property rights.

Because trademarks are registered under specific jurisdictions, it is debatable if they can be acknowledged globally. World Intellectual Property Organization (WIPO) created a Global Brand Database that aims to aggregate registered marks by countries. This system could be used to look up valid trademarks upon TNS registration and prevent it. Unfortunately, it wouldn’t be able to provide any sort of verification.

Domains in Domain Name Service (DNS)

If TNS uses the same structure as DNS, it would mean an excellent option for the integration and adoption of the whole DNS namespace. TNS will most likely use TLD .tez or .xtz , none of which are used as DNS TLD. It is essential to keep the TNS and DNS sets disjoint to prevent name collisions. The domain claim in TNS would be verified by consulting a TXT entry for the respective DNS domain. The ownership would not be freely transferrable and could only be updated based on a new TXT entry value.

To claim a DNS domain, we need a trusted DNS record. Thanks to the DNSSEC standard, it is possible to query a DNS record and trust its information.

DNSSEC uses digital signing to assure users that the data originated from the stated source and that it was not modified in transit.

Ethereum Name Service used the same approach and announced an integration with DNSSEC allowing registration of Internet TLDs (nearly 90%).

Identity information

Any verifiable information could be used as an alias for an address in TNS. From a usability point of view, common contact information shared by individuals include:

  • Phone number could use an E.164 standard i.e., +14155552671, which would be registered as a top-level entry. DNS domains don’t allow + sign, so no collision would occur. Verification would be done by sending codes via SMS.
  • Email relies on DNS and therefore could be managed by company administrators by adding additional TXT entries with email addresses. After DNS is integrated, email support could be added as well. An individual setup would be also possible by sending a verifiable code to an email address.

Any verification through sending codes in the trustless system is a challenging task. Apart from the risk of an attacker initiating a verification process and intercepting a code sent to another user’s device, there is also a possibility of oracles colluding with the attacker directly.


Verifiable claims using external systems could be added given a suitable option for using distributed oracles is available. Approaches relying on the security of external systems must be carefully examined and their risks weighed (i.e., email and phone number could easily be stolen). A newly added system must not cause name collision.

External resources

Join the Conversation

We are excited to start a discussion on this topic with the community! Do you have an opinion on trademarks and their adoption in TNS? Did we miss something? Let’s share ideas.

And if you want to chat, come join TNS Group on Telegram!


Just an idea I thought of recently. There was a contentious proposal from metastate on improving baking by splitting private key. Instead of that, wouldn t it be possible to register your tezos dns, and delegate to the dns instead of the public key? That would mean you can delegate to an entity instead of their tech setup.

I would like to see dns become part of the core protocol and having this delegating possibility…

1 Like