Introducing Stele v2: From Names to Ethereum-Native Identifiers

Stele was built around a simple idea: human-readable identifiers for Ethereum should be permanent, soulbound, and safe to use for payments.

Since launching Stele, we have continued building around it and discussing integrations with wallets and applications. That process has highlighted a few areas where the original design can be simplified and improved.

We have therefore launched Stele v2.

The fundamental philosophy behind Stele has not changed. Names remain permanent and soulbound. Instead, Stele v2 introduces a clearer identifier format, removes unnecessary special cases, separates Stele from the namespace collisions created by domain-style naming systems like ENS, and includes several smaller improvements that make Stele easier to integrate and build on.

The main changes are:

• A new label@namespace identifier format
• No blocked eth namespace
• Removal of bare names
• Direct registration of names for owned smart contracts

Other smaller (technical) changes include:

• Expiring registration authorizations
• More readable events and a cleaner contract design
• Additional ownership safeguards

Most importantly, existing Stele users and namespace owners do not need to do anything. All existing registrations have been migrated to Stele v2 as part of the deployment process.

Given that Stele is still at an early stage with limited usage and integrations, we believe now is the right time to make these changes. Making them later, after significantly more applications and users depend on the existing format, would be considerably more disruptive.

From alice.xns to alice@xns

The most visible change in Stele v2 is the identifier format.

Stele v1 used:

alice.xns

Stele v2 uses:

alice@xns

The underlying concept remains the same: a label combined with a namespace, but now separated by an @ instead of a dot.

There are two important reasons for this.

First, the dot notation makes Stele identifiers look like internet domains. This naturally leads to comparisons with DNS and naming systems such as ENS, even though Stele is fundamentally different.

Stele identifiers are permanent, soulbound Ethereum identifiers designed to make transacting on Ethereum simpler and safer. They are not internet domains.

The new format makes that distinction much clearer:

alice@xns
company@dao
uniswap@swap

More importantly, the domain-like format creates practical namespace collisions for wallets.

Different naming systems can use the same suffix. For example, .gwei exists in both GNS and Stele. A wallet receiving alice.gwei therefore cannot determine which naming system the user intends simply from the identifier.

This complicates wallet integrations. Supporting Stele can require decisions about competing namespaces, precedence rules, or excluding namespaces that are already associated with another naming system.

A visually distinct identifier removes Stele from much of that problem.

A simple convention becomes possible:

. → domain-style naming systems such as ENS, WNS or GNS
@ → Stele

Instead of competing over suffixes, Stele gets its own recognizable syntax.

alice@eth Is Not alice.eth

This distinction also allows us to remove one of the original restrictions in Stele.

The eth namespace was blocked in Stele v1 to prevent name collisions with ENS.

With the new format, the distinction is obvious:

alice.eth → ENS
alice@eth → Stele

As a result, the eth namespace is available in Stele v2.

One Format, No More Bare Names

Stele v1 also supported a special type of identifier: bare names.

A name such as:

alice

implicitly represents a name within the special x namespace. In other words, registering alice.x also allowed the holder to use the shorter alice form for resolution. This was originally designed as a premium feature, giving names in the x namespace a uniquely short and simple representation.

In practice, however, it introduces special-case logic for applications building on top of Stele and for smart contracts extending it.

Instead of every identifier following the same parsing and resolution rules, integrations need to distinguish between bare names and regular namespaced identifiers.

Stele v2 removes this distinction.

Every Stele identifier follows exactly one structure:

label@namespace

No implicit namespace. No alternative parsing path.

There is another reason for removing bare names.

We are working on another addressing standard that will complement Stele names. Bare identifiers could create ambiguity between the two systems, whereas giving Stele one explicit and recognizable format makes coexistence straightforward.

Smaller Improvements (technical)

Stele v2 also includes several smaller changes intended to expand the reach of Stele, simplify the contract, and make integrations easier.

Naming Existing Smart Contracts

Stele was designed to support human-readable identifiers for smart contracts.

In Stele v1, this was supported through ERC-1271. An existing smart contract that implements ERC-1271 can authorize a sponsored name registration, allowing a Stele name to be assigned directly to the contract address.

The limitation is that many existing smart contracts were deployed without ERC-1271 support. Because these contracts generally cannot initiate arbitrary transactions themselves, there is no way for them to authorize a Stele registration retroactively.

Stele v2 expands smart-contract naming to a much larger set of existing contracts.

Many contracts expose their owner through the widely used owner() function or an equivalent getOwner() function. Stele v2 allows that owner to directly register a Stele identifier for the contract.

For example, if a contract returns Alice from owner(), Alice can register:

protocol@defi

directly for that contract address.

This means smart-contract naming is no longer limited to contracts that were specifically designed with ERC-1271 support. Existing protocols and applications using common ownership patterns can also receive permanent Stele identifiers without modifying or redeploying their contracts.

Expiring Registration Authorizations

Stele supports authorized registrations, allowing someone else to pay for a name while the recipient explicitly authorizes the registration through an EIP-712 signature.

In Stele v2, these authorizations include an expiration timestamp to prevent old registration authorizations from remaining valid indefinitely.

More Readable Events

Stele v1 used indexed strings in several events. On Ethereum, indexed strings are represented by their hashes in event topics rather than their readable contents.

Stele v2 instead emits both hashes for efficient filtering and plaintext labels and namespaces.

This makes the interpretation of Stele activity considerably easier for explorers, indexers and applications.

A Cleaner Constructor

Stele v1 assigned the Stele name xns.x (or simply xns in its bare-name form) to the Stele contract itself.

Stele v2 removes this because there is little reason for the registry contract used to look up Stele identifiers to assign an identifier to itself.

Protocol Ownership Cannot Be Renounced

Stele v2 also prevents protocol ownership from being renounced, avoiding a situation where the protocol owner could permanently lock themselves out of access to protocol fees. Ownership can still be transferred through the existing two-step process, but it cannot accidentally be sent to the zero address.

Existing Users Don't Need to Do Anything

This is perhaps the most important practical point of the upgrade:

Existing Stele name and namespace owners do not need to migrate anything themselves.

All existing registrations have been migrated to Stele v2 as part of the deployment process.

If you owned:

alice.xns

your corresponding Stele v2 identifier is now:

alice@xns

and remains associated with the same address.

Existing namespace ownership and configuration have likewise been recreated in Stele v2.

No action required from existing users.

Stele v1 remains permanently on-chain as an immutable historical registry, while applications (incl. the x2xPay.me app) and future Stele development move to Stele v2.

Conclusion

Stele v2 is an important evolution of Stele.

The goal is to establish a clearer and stronger foundation for an ecosystem of human-readable identifiers on Ethereum.

Stele is still young, which makes now the right time to get that foundation right and build on it for the long term.

One format. One name. One address. Permanent by design.