Conor Svensson

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.

When we published our first Contract Naming Season update in January, the focus was on momentum and what had been achieved. Teams were beginning to name contracts, tooling had improved, and the first public protocol announcements had started to appear.

At that stage, the awards themselves were still ahead of us.

We have now reached a more concrete milestone. The first batch of ENS Contract Naming Season awards has been distributed, and with two months still to go before the program closes at the end of April, we now have a clearer picture of how participation is taking shape.

Identity is often framed as a feature​

Over the past year working on Enscribe, we have noticed that identity is often discussed as if it were a product capability. A wallet "adds identity support," a protocol "integrates ENS," and an explorer "improves labels." The framing implies that identity is something a single team can implement and ship, like a new dashboard or API endpoint.

When teams talk about shipping securely onchain, audits usually dominate the conversation. Deployment scripts are reviewed carefully, contracts are verified and monitoring is configured.

Blockscout smart contract pages now include an Identity score powered by Enscribe.

Blockscout is a leading open-source blockchain explorer for viewing transactions, smart contracts, and onchain activity across hundreds of networks.

Security audits are an essential part of deploying production-grade smart contracts. They review logic, identify vulnerabilities, and reduce the likelihood of catastrophic exploits. For serious protocols, audits are a core component of their security framework.

ENS supports two ways of associating names with addresses.

1. A name can forward resolve to an address (myname.eth -> 0x1234…).
2. An address can declare a primary name which contains a forward resolving address record and a reverse record that points back to the name (0x1234… -> myname.eth).

It’s important to be aware of this distinction between forward resolution and primary names as it defines a security boundary within ENS.