3 posts tagged with "identity"

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.