Conor Svensson

In 1995, most organisations did not have a domain name. The ones that did were not always sure what to do with it. Email and a static website were considered ambitious uses. The idea that an organisation might one day operate the bulk of its identity, infrastructure, and customer relationships through structured DNS namespaces would have seemed unlikely to many business leaders.

A small number of companies were thinking differently. They saw the trajectory of the internet, recognised that their organisation was going to need to operate in this new environment, and started building the structures that would let them do it. They registered their domains early. They thought about subdomains for departments, products, and services. They put email addresses on business cards before most of their competitors knew what email was for.

Five years later, those companies looked prescient. Ten years later, they looked obvious.

I think we are at a similar inflection point with onchain identity, and the parallel is worth taking seriously.

Most teams approaching ENS for the first time start with the same question: what do I actually name? It sounds like a small question, but it is usually the hardest part of getting onchain identity right. Get the structure wrong at the start and you can spend years unpicking it. Get it right and everything that comes after is much simpler.

The good news is that we do not need to invent the answer from scratch. Three decades of DNS have already given us a set of patterns that work well, and most of them translate directly to onchain identity.

SSV Network has adopted ENS-based naming across its smart contract infrastructure as part of Contract Naming Season.

SSV is a leading implementation of Distributed Validator Technology on Ethereum. Its protocol distributes validator keys across multiple independent operators to reduce single points of failure in staking. With more than 7.5 million ETH secured and roughly 19 percent of Ethereum validators running through its infrastructure, SSV is one of the more important pieces of staking infrastructure on the network.

The most common reason organisations give for not using ENS is not technical. It is not cost either, though that gets mentioned. The real reason, when you talk to enough teams, is that they do not want to manage another identity.

They already have a domain. They already have a brand built around it. Their users know them by it. Their email runs through it. Their website lives on it. Adding a separate .eth name on top of that feels like duplication, and duplication is something experienced operators try to avoid.

There is a related concern that gets voiced less openly, but matters just as much. Their existing domain comes with legal protections they have come to rely on, including trademark coverage, dispute resolution mechanisms, and decades of case law. ENS does not have an equivalent legal layer today. For organisations with valuable brands to protect, building part of their identity on a system without those protections is a real concern.

These concerns are reasonable. They are also both addressed by something most teams do not realise ENS supports.

ENS has supported DNSSEC-enabled DNS names for years. In practice, that means if your organisation already owns a DNS domain such as yourcompany.com, you can import that name directly into ENS and use it as your onchain root. You do not need to register a .eth name. You do not need to manage two identities. You do not need to give up the legal protections attached to the domain you already own.

When DNS was introduced in 1983, it was framed as a technical convenience. The internet was growing, the host file approach was starting to break down, and a naming system was needed to translate human-readable names into machine addresses at scale.

That is how DNS was designed. It is not how it ended up being used.

The interesting part of DNS was not just the protocol. It was what organisations did with it once they realised they had a structured naming system at their disposal.

Within a few years, companies stopped treating a domain as just the place where a website lived and started using it as the root of an identity hierarchy. Sales, engineering, support, corporate, and internal tools all got their own subdomain. Production, staging, and development environments were separated by name. Regional deployments were organised by geography. Service names started mapping to functions rather than machines.

By the late 1990s, no serious organisation operated without a structured DNS namespace. By the mid-2000s, the namespace had become almost invisible because it was so fundamental to how companies operated.

Over the past year, we have spent a lot of time working on onchain naming. We ran ENS Contract Naming Season, worked with teams such as Nouns DAO, Liquity, Cork, and Giveth, built a Safe integration, shipped a Foundry plugin, and watched thousands of contracts move from anonymous hexadecimal addresses to human-readable names.

That work changed how we think about both Enscribe and ENS.

Most discussions around ENS tend to focus on .eth names as a new primitive — a way for individuals or projects to establish a native onchain identity. That framing is broadly correct, but it misses a second path that is arguably more relevant for organisations: ENS also supports DNS names, and that support changes the nature of the conversation quite significantly.

Instead of asking an organisation to adopt a completely new identity system, ENS allows them to extend the identity they already have. A company can take a domain like example.com, prove ownership, and bring that identity onchain, gaining access to ENS functionality without introducing a new naming surface.

The DNS name base.org lives on ENS, along with base.eth which manages the record

This creates a form of flexibility that is easy to overlook. An organisation can choose to operate entirely with a native ENS name, such as protocol.eth. Or it can bridge its existing DNS identity into ENS and retain continuity with how users already recognise it. Both approaches are valid, and both lead to the same destination: a named, identifiable presence onchain. The difference is how much change is required to get there.

Enscribe now has a YouTube channel with short tutorials, walkthroughs, and community call recordings that show how smart contract naming works in practice.

You can find it here: https://www.youtube.com/@enscribexyz

One of the stranger design choices Ethereum inherited early on is that users are still routinely shown raw hexadecimal addresses when they interact with smart contracts. These strings were never meant to be human-readable identifiers — they exist because machines need them, not because humans should be making decisions based on them.

Yet in many wallets and transaction flows today, users are still expected to look at a 42-character hexadecimal string and determine whether the interaction they are about to approve is legitimate. That expectation is only reasonable for developers. For regular people, it asks something the human brain is simply not well-suited to do.