Expiring Names Are Not Suitable for On-Chain Bank Accounts

ENS recently published an article arguing that new blockchain naming systems like XNS are unnecessary because ENS already provides the infrastructure needed for decentralized identity.

The ENS article attempts to justify ENS's position as the standard naming layer on Ethereum by pointing to its broad ecosystem integrations, its compatibility with DNS, concerns about namespace fragmentation, and the fact that it was first (see the URL of the article).

However, it does not address the central concern: sniping and phishing risk introduced by expiring account identifiers.

We, Ethereum OGs, see it as our responsibility to raise this issue with the Ethereum community. After nine years of playing around, we cannot remain calm. If Ethereum aims to support serious financial applications, the naming layer must meet the safety expectations of traditional financial systems.

Traditional bank accounts do not expire

ENS names expire. If the owner does not renew the name, it can be reassigned to someone else.

This model may be reasonable for web domains, but it is deeply problematic for bank account identifiers.

Imagine if bank account numbers worked this way. If you forgot to renew your bank account number, the bank can reassign it to someone else. Your salary payment could suddenly go to a stranger.

No serious financial system would ever adopt such a model.

Yet this is exactly the design ENS asks users to accept for on-chain payments, because "ens-was-here-first".

Besides reassignment risk, expiring identifiers also introduce phishing risks through renewal reminder emails.

These risks are not theoretical. We have already seen:

• Name sniping incidents involving loss of funds (example)
• Users reporting phishing emails related to ENS renewals (example)

In smart contract audits, these type of findings would be immediately flagged as critical. Yet the broader ecosystem appears largely comfortable ignoring them.

XNS is not "experimentation"

The ENS article describes the emergence of new naming systems like XNS as "experimentation".

But the real experimentation is building financial infrastructure on expiring account identifiers.

Systems like XNS emerge to address these structural issues that should never have been normalized in the first place. After nearly nine years of experimentation, Ethereum should start building naming infrastructure suitable for serious financial applications.

ENS confuses web domains with bank accounts

Much of ENS's design philosophy originates from DNS. ENS argues that blockchain naming should extend the existing DNS root, allowing domains like yourbrand.com to function as on-chain identifiers.

This assumes that merging web identity and financial identity is desirable. It's not. In traditional systems, these layers are deliberately kept separate.

A company's website might be:

yourbrand.com

But its bank account identifier is something entirely different:

IBAN: CH93 0076 2011 6238 5295 7
SWIFT: UBSWCHZH80A

Web domains are storefronts. Bank accounts are financial identifiers. We keep them separate for a reason.

If someone compromises a website domain, that should not automatically compromise the company's financial routing identifiers.

Merging these layers introduces new risks without solving a real problem.

Fragmentation and collision risk

ENS argues that alternative naming systems introduce fragmentation and collision risk.

However, this argument does not apply to XNS.

To avoid conflicts with the .eth namespace, XNS explicitly disallows registration of a .eth namespace. This ensures that ENS and XNS do not overlap.

Users can therefore choose between two different models:

• expiring .eth names
• permanent names within a wide range of first-class namespaces (.xns, .og, .gm, .me, etc.)

Within XNS itself, there is no collision risk. Names are scoped by namespace. For example, Alice could register any of the following identifiers:

• alice.xns
• alice.og
• alice.me
• alice.trb

In addition, XNS is deployed exclusively on Ethereum, which acts as the single source of truth for name resolution. XNS does not exist on other chains, avoiding situations where the same name could resolve to different addresses across different networks.

Subnames do not solve the expiration problem

ENS suggests that projects can launch their own naming systems via subnames such as:

• uni.eth
• linea.eth
• celo.eth

However, these systems still depend on a single entity renewing the parent name before it expires.

If that entity stops renewing, the namespace itself becomes vulnerable to reassignment.

In XNS, namespaces exist as first-class objects: .uni, .linea, .cb.

Integrations are not the only path to adoption

ENS emphasizes that it is integrated into many wallets and dApps. That is sadly true (sadly because many integrators seem to have skipped proper due diligence). But integrations are not the only path to adoption.

The x2xPay.me payments app demonstrates another approach. It works with every wallet because it operates at the application layer.

Users can register a permanent name starting at 0.001 ETH (~ $2) and send and receive payments using those identifiers.

No wallet integrations required. If users find it useful, integrations will naturally follow.

Being first or widely integrated does not automatically make a design the right long-term solution.

Horses were once widely integrated into transportation infrastructure too. Then cars arrived.

Coordination requires dialogue

The ENS article stresses coordination. Yet concerns raised about risks associated with expiring names have largely gone unanswered, even in the broader Ethereum ecosystem that claims it stands for security (see here).

ENS and their founder have blocked us on X without addressing our concerns.

Open dialogue is essential if Ethereum's naming infrastructure is meant to serve real financial use cases. The goal should not be protecting incumbency. The goal should be building safe primitives for global finance.

Ethereum needs safe payment identifiers

Ethereum is increasingly used for financial applications:

• payments
• stablecoins
• tokenized assets
• prediction markets
• on-chain finance

In that context, naming systems are not cosmetic features. They are financial infrastructure.

Financial infrastructure must prioritize safety. Permanent identifiers are the safest model. Expiring identifiers introduce risks.

Let the ecosystem decide

ENS and XNS represent different design philosophies. They do not collide. There is no fragmentation.

ENS prioritizes DNS compatibility and integrations. XNS prioritizes permanent financial identifiers.

Users can choose:

• expiring .eth names
• permanent XNS names

The ecosystem can decide which model it trusts more for financial transactions. Healthy ecosystems allow competing ideas to coexist and prove themselves over time.

That is how Ethereum itself evolves.