ENS Is Fundamentally Broken — and How XNS Fixes It

ENS, in its current form, is fundamentally misdesigned. By adopting the web2 domain model, ENS imported subscriptions, renewals, and tradeable names into what is now widely used as a payment identifier.

That decision has far-reaching consequences:

• Expirations and renewals introduce sniping risk and can lead to silent fund loss through name reassignment.
• Transferability incentivizes speculation and rent-seeking rather than predictable value routing.
• Complexity is wildly disproportionate to the simple task of mapping a human-readable name to an address (anyone who has read the ENS docs knows what I mean).

XNS was designed from first principles. Its design philosophy is simple:

• Permanent ownership. Identity is not a subscription.
• Non-transferability. Focus on secure value routing, not speculation.
• Simplicity. No governance or configuration overhead. No token.

Beyond these fundamentals, XNS introduces capabilities ENS cannot offer, including first-class namespaces, permissionless namespace creation, private namespaces, and ETH-aligned economics via fee burning.

Expirations and renewals are a footgun for payment identifiers

ENS names expire. If you forget to renew:

• your name is released
• anyone can re-register it
• future payments may silently go somewhere else

This may be acceptable for websites. It is unacceptable for payment identifiers.

Imagine a world where your bank account number expires unless you explicitly renew it. If you forget, the number is reassigned to someone else. You keep sharing it. Your employer keeps paying. But your salary now goes to a stranger.

That sounds insane. Right?

Well, this is exactly how ENS works.

ENS has existed since 2017. If, after nearly a decade, we still accept a system where a payment identifier can expire and be reassigned through inaction, it should not surprise that mainstream adoption remains out of reach.

XNS replaces the rent-extracting subscription model with permanent ownership. You pay once and own the name forever. Names in namespaces like .xns can be registered for as little as 0.001 ETH (currently under $2.50; see all available namespaces and prices here). There are no renewals and no expiry. You own it with peace of mind.

ENS pricing is rent-seeking by design

ENS pricing is

• time-based (annual renewals)
• character-based (shorter names are much more expensive)

For example, a 3-character ENS name costs $640 per year, every year.

This is perpetual rent extraction.

XNS removes both dimensions:

• no renewals, due to permanent ownership, and
• no character-based pricing.

Names such as alice.og, 0x.og, or h.og cost the same within the same namespace (for example, 0.008 ETH in the .og namespace). Prices vary by namespace, not by string length. As XNS supports a wide range of namespaces, the vast majority of users can register the name they actually want by simply choosing an appropriate namespace, rather than competing for a single scarce root.

Transferability incentivizes speculation, not use

ENS names are transferable. This:

• encourages squatting,
• creates secondary markets
• turns identity into a tradeable commodity

That is the opposite of what identity infrastructure should do.

XNS names are non-transferable. They are permanently bound to one address and unusable as speculative assets.

If you want to speculate, trade tokens.

If you want identity, register an XNS name (for instance, on x2xPay.me)

ENS does not provide a single, unambiguous name per address

ENS is fundamentally a name → address system.

Multiple ENS names can point to the same address. Reverse resolution (address → name) is optional, manual, and often unset.

As a result, there is often no clear answer to a simple question: "What is the name of this address?"

That is not identity.

XNS enforces a strict invariant:

• Each address maps to exactly one name, and
• Each name maps to exactly one address

This problem becomes even more acute as autonomous agents emerge on Ethereum. Bots, services, vaults, DAOs, and AI-driven agents are long-lived actors that interact economically on-chain. Like humans and institutions, they need a single, stable name they can use for their entire lifetime. A naming system where identifiers can expire, be reassigned, or ambiguously resolve is fundamentally incompatible with autonomous agents.

XNS is designed for this future.

ENS complexity is wildly disproportionate to the task

At its core, ENS is supposed to do one simple thing: map a human-readable string to an address.

Yet it requires:

• commit-reveal schemes
• renewal mechanics
• auction logic
• wrapper contracts
• resolver indirection
• reverse records
• numerous edge-case flows

This complexity is the cost of bolting DNS economics onto Ethereum identity. Today, ENS is a system of roughly a dozen interacting smart contracts to perform the simple string-to-address mapping, with audit costs alone running into the hundreds of thousands of dollars.

Rather than simplifying the model, ENS proposes to push the complexity even further with a dedicated "namechain", effectively adding another layer of infrastructure to support an already over-engineered system.

XNS was built with simplicity in mind. It is implemented as a single contract, making it easier to reason about and audit.

ENS creates artificial scarcity by focusing on a single namespace

ENS concentrates nearly all identity into a single namespace: .eth.

That chokepoint creates extreme scarcity pressure:

• short names become expensive
• squatting becomes rational
• commit-reveal schemes become necessary

It also forces projects into awkward workarounds. Uniswap couldn't register a first-class .uni namespace in ENS and instead had to use a *.uni.eth subdomain, which are second-class citizens by design.

XNS avoids this entirely by design.

XNS supports a wide range of first-class namespaces. Projects can register a pure namespace like .uni directly, rather than being buried under another root. If alice.og is taken, you can simply choose another namespace that fits just as well:

• alice.gm
• alice.wagmi
• alice.yolo
• alice.xns
• alice.brrr
• or, as a premium option, a bare name like alice

This gives users real choice and allows identity to be expressive rather than competitive.

ENS does not allow permissionless namespace creation

ENS namespaces are centrally allocated. New top-level namespaces must be approved and assigned through ENS governance. There is no permissionless, on-chain mechanism for anyone to create a native ENS namespace.

XNS takes the opposite approach.

In XNS, anyone can create a namespace directly on-chain:

• Public namespace: 50 ETH
• Private namespace: 10 ETH

There is no approval process and no committee deciding which namespaces may exist.

Public namespaces are more expensive because the creator earns 10% of all name registration fees in perpetuity. Private namespaces are priced lower because their owners do not earn fees; instead, they retain full control over who can register names within the namespace. This is particularly relevant for companies and institutions that want a dedicated namespace to name and manage their own assets, such as tokenized real-world assets, under a namespace they fully control (e.g. .blackrock, .sygnum).

During the first year after deployment, namespaces can be created by the XNS creator for others at no cost to bootstrap the ecosystem. If you want to own a namespace and help bootstrap adoption, reach out on X.

ENS has a value-less governance token; XNS is ETH-aligned

ENS introduced a governance token that currently has a market capitalization of roughly $250 million (at the time of writing). The token does not represent a claim on cash flows, does not accrue protocol revenue, and does not strengthen Ethereum itself. Its primary function is governance.

XNS deliberately avoids this model.

XNS has no governance token. Instead, 80% of the registration fee (paid in ETH) is permanently burned.

No token politics.
No governance theater.
No value leakage away from ETH.

Smart contract naming

ENS's expiration-based model is particularly problematic for smart contracts.

Smart contracts are immutable and long-lived by design. They cannot "remember" to renew a name, rotate keys, or respond to expiration events. As a result, assigning an ENS name to a contract is inherently fragile: if the name expires, it can be re-registered by someone else, silently breaking integrations or redirecting value.

XNS removes this entire class of failure.

Because XNS names are permanent and non-transferable, they can be safely assigned to smart contracts, protocols, multisigs, and tokens without the risk of expiration or reassignment. Once a contract is named, that association is stable for the lifetime of the contract.

This is especially critical for tokenized real-world assets (RWAs), where identifiers must remain stable.

Refer to the XNS documentation for details on naming smart contracts.

How to get an XNS name

The easiest way to get an XNS name is via x2xPay.me.

x2xPay lets you:

• Register an XNS name directly from the app
• Send crypto safely using names instead of addresses
• Request payments via a simple payment link

It's essentially GoDaddy (but with permanent names) and PayPal combined into one single application for the Ethereum blockchain.

👉 Visit x2xPay.me to get started.

Outlook: XNS as the Naming Layer of Ethereum

Ethereum needs a naming layer that is as reliable for value routing. XNS is built to be that layer.

By removing expirations, speculation incentives, governance tokens, and artificial scarcity, XNS provides a safe naming infrastructure you set once and never worry about again.

This is a prerequisite for mainstream adoption. Copy-pasting addresses is not a user experience we should be asking anyone to accept. Names should be the default.

THANK YOU FOR YOUR ATTENTION TO THIS MATTER. 🫡