14 posts tagged with "ens"

Superfluid has adopted Enscribe-powered ENS naming across its smart contract infrastructure as part of Contract Naming Season.

Superfluid is onchain financial infrastructure for programmable, real-time value transfer. With more than $1.6 billion in volume, more than 1.2 million wallets, and 50,000 active users across 11 EVM networks, Superfluid powers payment infrastructure for organisations including ENS DAO, Optimism, and Gitcoin.

One of those organisations happens to be ENS DAO, which uses Superfluid to stream grants and contributor payments. There is a nice circularity to this announcement: the protocol that streams payments for ENS DAO is now using ENS to name its own contracts.

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.

It is important to know the history of a name, especially when you want to understand how a name has changed over time.

That's why we have added a new Name History section to the Name Explorer & Contract Details pages in Enscribe. It gives you a compact record of recent activity for a name, including metadata updates, resolver changes, and subname activity.

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.

The Enscribe team was at the latest edition of EthCC, and we had a talk on the agenda: Smart contract identity for orgs and agents.

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.