Introducing XNSv2: From Names to Ethereum-Native Identifiers

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

Since launching XNS, 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 are therefore preparing XNSv2.

The fundamental philosophy behind XNS is not changing. Names remain permanent and soulbound. Instead, XNSv2 introduces a clearer identifier format, removes unnecessary special cases, separates XNS from the namespace collisions created by domain-style naming systems like ENS, and includes several smaller improvements that make XNS 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 XNS users and namespace owners will not need to do anything. We plan to migrate all existing registrations to XNSv2 as part of the deployment process.

Given that XNS 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 XNSv2 is the identifier format.

XNSv1 uses:

alice.xns

XNSv2 will use:

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 XNS identifiers look like internet domains. This naturally leads to comparisons with DNS and naming systems such as ENS, even though XNS is fundamentally different.

XNS 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 XNS. A wallet receiving alice.gwei therefore cannot determine which naming system the user intends simply from the identifier.

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

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

A simple convention becomes possible:

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

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

alice@eth Is Not alice.eth

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

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

With the new format, the distinction is obvious:

alice.eth → ENS
alice@eth → XNS

As a result, the eth namespace will therefore be available in XNSv2.

One Format, No More Bare Names

XNSv1 also supports 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 XNS 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.

XNSv2 removes this distinction.

Every XNS identifier will follow 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 XNS names. Bare identifiers could create ambiguity between the two systems, whereas giving XNS one explicit and recognizable format makes coexistence straightforward.

Smaller Improvements (technical)

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

Naming Existing Smart Contracts

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

In XNSv1, this is supported through ERC-1271. An existing smart contract that implements ERC-1271 can authorize a sponsored name registration, allowing an XNS 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 an XNS registration retroactively.

XNSv2 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. XNSv2 allows that owner to directly register an XNS 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 XNS identifiers without modifying or redeploying their contracts.

Expiring Registration Authorizations

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

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

More Readable Events

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

XNSv2 will instead emit both hashes for efficient filtering and plaintext labels and namespaces.

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

A Cleaner Constructor

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

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

Protocol Ownership Cannot Be Renounced

XNSv2 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 XNS name and namespace owners will not need to migrate anything themselves.

We will migrate all existing registrations to XNSv2 as part of the deployment process.

If you currently own:

alice.xns

your corresponding XNSv2 identifier will become:

alice@xns

and remain associated with the same address.

Existing namespace ownership and configuration will likewise be recreated in XNSv2.

No action required from existing users.

XNSv1 will remain permanently on-chain as an immutable historical registry, while applications (incl. the x2xPay.me app) and future XNS development move to XNSv2.

Conclusion

XNSv2 is an important evolution of XNS.

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

XNS 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.