One Multi-Namespace Registry: The Only Safe Foundation for Payments

1. Human-readable names are payment infrastructure

Blockchain addresses are designed for machines, not people.

An Ethereum address such as 0x7a3Bf2c8E91d4A6b5C0eF8a1D2b3C4d5E691F2 is difficult to remember, difficult to communicate, and difficult to verify visually. Even careful users cannot realistically inspect every character before sending funds.

That is not merely an inconvenience. It is a security problem.

Attackers exploit the fact that users struggle to distinguish one address from another. For example, they may inject lookalike addresses into a user's transaction history in the hope that the wrong address is copied later, an attack commonly known as address poisoning. Clipboard manipulation can create a similar outcome by replacing the intended destination with an attacker-controlled address.

Human-readable names offer a better interface:

• alice.x
• alice.gwei
• payments.amazon

A meaningful name is easier to recognize, share, and verify than a hexadecimal address. It can become a stable identifier associated with a person, business, wallet, or application.

For this reason, blockchain names should not be viewed only as usernames, digital identities, or collectible assets. Once they are used to receive funds, they become part of the payment infrastructure.

That distinction matters.

A web2 domain or social-media handle can change ownership without directly rerouting money. A collectible can be sold without affecting people who previously interacted with its owner. A payment identifier carries a much stronger expectation:

The same identifier should continue to mean the same recipient.

When a business tells customers to send funds to payments.amazon, customers should not need to understand which naming service issued the name, which resolver their wallet uses, whether the name can expire, or whether the underlying namespace can later be reassigned.

The payment application should produce one deterministic destination address.

The central question is therefore:

What architecture can ensure that the same human-readable payment identifier is interpreted consistently, permanently, and safely across wallets and applications?

This article argues that the only safe foundation is a single canonical smart contract registry containing multiple globally unique namespaces, with permanent namespace assignments and permanent, non-transferable names.

2. The hidden collision problem

Today, blockchain naming is fragmented across multiple independent systems.

Ethereum users may encounter ENS, XNS, GNS, WNS, and other naming protocols. More systems will likely emerge, while brands and communities may also deploy their own naming contracts.

Each system maintains its own registry and resolution logic.

At first glance, this appears healthy. Different protocols can experiment with different pricing models, ownership rules, and user experiences.

But payment identifiers are not ordinary consumer products.

Independent naming systems do not share one globally authoritative namespace root. Each protocol can interpret the same suffix independently.

For example:

alice.gwei in GNS → Address A
alice.gwei in XNS → Address B

Both records may be valid according to their respective contracts.

The visible identifier is identical:

alice.gwei

But the result depends on which resolver the wallet chooses.

One wallet may resolve .gwei through GNS. Another application may resolve it through XNS. A third may support both and ask the user to choose.

The blockchain itself does not know which one is the "real" alice.gwei.

That is fundamentally different from an Ethereum address. On the same chain, an address refers to the same account in every application. Applications may display it differently, but they do not independently choose what the address means.

A human-readable payment identifier should provide the same property.

If the meaning of alice.gwei depends on the application, it is not a globally reliable identifier. It is an application-dependent alias.

3. Exact-name impersonation

Namespace collisions create a direct impersonation risk.

Assume Alice publicly uses:

alice.gwei

through GNS, where it resolves to Address A.

An attacker notices that the same name is still available in XNS and registers it there, pointing it to Address B.

Now:

alice.gwei in GNS → Alice
alice.gwei in XNS → Attacker

A wallet that treats .gwei as a GNS namespace sends the payment to Alice. An application that resolves .gwei through XNS sends the same payment to the attacker.

The same problem may also arise without malicious intent when two unrelated users register the same name in different systems.

The architectural failure is that the payment identifier does not uniquely determine its resolution path.

A wallet may try to solve this with a warning: "Multiple naming services contain alice.gwei. Please select one."

But users may not know which service is correct. At registration, the app may have shown only alice.gwei — not which naming protocol issued it.

The system is asking users to make a protocol-level security decision that should have been settled by the naming infrastructure.

A payment identifier should not behave like a search query returning several possible recipients.

It should identify one recipient.

4. Why resolver prefixes are not the final solution

One possible solution is to include the naming protocol in the identifier:

xns:alice.gwei
gns:alice.gwei
ens:alice.eth

The prefix tells the wallet which resolver to use.

This removes ambiguity:

xns:alice.gwei → XNS → Address A
gns:alice.gwei → GNS → Address B

As an interoperability mechanism, this is coherent and substantially safer than silently assigning each suffix to whichever naming service a wallet prefers.

But it solves the infrastructure problem by transferring complexity to users.

Besides looking clunky and less readable, the prefix becomes another part of the payment identifier that users must copy, share, and preserve correctly. Every registration interface, copy button, QR code, profile page, and payment request must teach users to share the fully qualified form.

If users shorten xns:alice.gwei to alice.gwei, the ambiguity immediately returns.

Resolver prefixes also do not eliminate the wallet integration burden. A wallet must still implement ENS, XNS, GNS, WNS, and every future naming protocol it wishes to support.

Each resolver may have different:

• contract interfaces
• normalization rules
• upgrade mechanisms
• ownership models
• governance structures
• security assumptions

The prefix merely tells the wallet which integration to invoke.

Resolver-qualified names are therefore useful in a fragmented ecosystem, but they do not eliminate fragmentation.

The ideal payment infrastructure should not require users to know which naming protocol interprets a recipient's name. It should provide one canonical path automatically.

5. Why a mutable global resolver directory is also unsafe

A more sophisticated proposal is to place a global directory above existing naming services.

Such a system would require a central governance body to decide which resolver is considered canonical for each namespace:

.eth    → ENS
.gwei   → GNS
.x      → XNS
.amazon → Amazon Registry

Wallets would integrate the directory, which would tell them which resolver is authoritative for each namespace.

Initially, this seems attractive. Wallets get one integration while existing naming services remain independent.

But the directory becomes dangerous if it can later change the resolver assigned to an active namespace.

Assume .amazon initially points to an XNS namespace:

.amazon → XNS

A user registers:

bob.amazon → Address A

Later, Amazon launches its own registry and asks the directory's governance body to recognize it instead:

.amazon → Amazon Registry

The original bob.amazon record still exists in XNS, but wallets no longer consult it.

A new person can register:

bob.amazon → Address B

inside Amazon's registry.

The visible identifier has not changed. Only the parent-level resolver has changed.

Funds previously intended for Address A may now be sent to Address B.

The reassignment may even appear legitimate. Amazon may have a stronger brand claim, and the new registry may be officially maintained. None of that makes the change safe for users who already relied on the original names.

A global resolver directory is safe only if namespace assignments become immutable before names can be registered beneath them, and once registrations begin, the namespace must never be redirected to another resolver.

6. Permanence must be structural

Naming systems often describe a name as permanent when the registration itself does not expire.

That is only one part of permanence.

A name may remain stored on-chain forever while its practical meaning changes because:

• the namespace is delegated to another registry
• the resolver logic is replaced
• governance gains overwrite powers
• the name becomes available again
• wallets begin following another resolution path

A safe payment identifier requires permanence across the entire structure:

name
→ namespace
→ authoritative registry
→ recipient address

Each layer must preserve identity.

The namespace must remain unique. Its authoritative resolver assignment must remain fixed. Existing names must never be recycled. Every compliant wallet must follow the same deterministic resolution process.

Protocol implementations may improve over time, but upgrades must preserve the existing name-address mappings and namespace assignments.

7. Why payment identifiers must remain permanently bound

Expiry and transferability are different mechanisms, but they create the same fundamental risk: a familiar payment identifier can begin representing another recipient.

Why payment names must never expire

Assume:

alice.x → Address A

Alice shares this name publicly. It appears in invoices, address books, websites, payment templates, accounting records, social-media posts, and old messages.

If the name expires and becomes available again, another person can register it and assign it to Address B. Old payment instructions may then route to the new registrant rather than Alice.

This risk is not theoretical. The ENS dropcatching paper found 2,633 transactions that appeared to have been intended for previous owners but were instead sent to new owners of the re-registered names.

The study also explains that an expired ENS name can continue resolving to the previous owner until somebody re-registers it and changes the destination. This can hide the risk until the resolution address suddenly changes.

Renewals therefore introduce more than an administrative obligation. They create a point at which a trusted payment identifier may return to circulation and acquire a different recipient.

Why payment names must not be tradeable

Transferability creates the same outcome without expiry.

Alice may intentionally sell the name, and the buyer may become its lawful owner. However, just as with renewals, old payment instructions and references may continue to circulate after the transfer, still pointing to the now-transferred name.

Transfers may be acceptable for collectibles or digital assets. They are not appropriate for payment identifiers.

The permanent-binding model

Under the XNS model, once:

alice.x → Address A

is registered, it remains permanently bound to Address A.

The underlying wallet may be compromised or lost, but the naming protocol itself does not create a mechanism through which the same identifier can later represent another person.

A lost name is unfortunate, but safer than a reassigned identity.

The distinction should be explicit:

A tradeable name is an asset. A non-transferable name can function as a permanent payment identifier.

For a human-readable name to remain safe as a payment instruction, it must neither expire nor change recipients through transfer.

8. Why governance cannot correct active namespaces later

A canonical registry still faces a difficult question:

Who should receive a namespace such as .amazon, .apple, or .uniswap?

A permissionless system may use a simple first-come, first-served rule. A governed system may review brand claims or introduce a challenge period.

There is no perfect registration model.

But one safety rule is non-negotiable:

Any dispute must be resolved before names can be registered beneath the namespace.

A safe, governed lifecycle could look like this:

namespace proposed
→ optional challenge period
→ namespace finalized
→ registrations opened
→ resolver assignment becomes permanent

Once child registrations begin, governance must lose the power to change the namespace's resolver assignment.

This may lead to commercially inconvenient outcomes. A brand that fails to secure its preferred namespace may need to use another one.

That is still safer than allowing governance to redefine payment identifiers after users have begun relying on them.

A naming system can survive an imperfect namespace registration.

It cannot safely survive silent reinterpretation of active names.

9. The canonical multi-namespace model

The safer architecture is one canonical smart contract registry containing all namespaces.

Within that system:

alice.x
alice.gwei
alice.pepe
payments.amazon

all exist under one root.

Each namespace can exist only once.

There cannot be two .gwei namespaces inside the registry. There cannot be one .amazon interpreted by one wallet and another .amazon interpreted by a different application.

Every conforming wallet queries the same contract and receives the same answer.

alice.gwei
→ canonical registry
→ .gwei namespace
→ alice record
→ recipient address

Adding a new namespace does not require another wallet integration. It creates another branch inside the registry wallets already support.

This is the key architectural advantage of XNS.

XNS is not merely a collection of permanent names. It is a canonical multi-namespace root in which all names share the same core safety guarantees:

• permanent registration
• non-transferability
• one deterministic resolution path
• no namespace duplication inside the system
• no dependence on renewal
• no ability for namespace controllers to reclaim issued names

Namespaces may differ in registration and issuance rules.

A public namespace may allow anyone to register an available name. A private brand namespace may allow only the namespace controller to issue names.

But once registered, every name receives the same permanent, non-transferable binding.

The namespace rules answer:

Who may issue the name?

The protocol-level safety model answers:

Can the name later expire, be sold, revoked, or reassigned?

XNS allows flexibility in the first question while giving one strict answer to the second.

10. One smart contract registry can serve many EVM chains

The XNS contract on Ethereum acts as a shared naming database across EVM-compatible chains.

Suppose:

alice.x → 0x1234...abcd

is recorded in the canonical XNS contract on Ethereum.

A wallet can read that mapping and use the address for a payment on Ethereum, Base, Arbitrum, Optimism, Polygon, Gnosis Chain, or another EVM network.

The registry answers:

Which address is permanently associated with this name?

The wallet separately determines:

On which EVM chain should the payment be executed?

For example:

Recipient: alice.x
Resolved address: 0x1234...abcd
Payment chain: Base
Asset: USDC

The name is resolved through the canonical Ethereum registry while the payment occurs on Base.

This avoids deploying separate naming systems on every EVM chain.

Separate deployments would recreate fragmentation:

alice.x on Ethereum → Address A
alice.x on Base     → Address B
alice.x on Arbitrum → Address C

Users would again need additional context to interpret the name safely.

One canonical deployment creates one identity layer shared across many EVM execution environments.

11. Conclusion

Human-readable names become payment infrastructure once users rely on them to receive funds.

That requires one basic guarantee:

The same identifier must resolve to the same recipient in every conforming wallet.

Competing naming systems cannot provide that guarantee. They can issue identical names under identical suffixes, leaving wallets to choose which resolver is legitimate. Prefixes can disambiguate the result, but they preserve the fragmented model and shift complexity to users. A mutable global directory is also unsafe if it can later redirect an active namespace.

The safer architecture is one canonical multi-namespace registry with permanent resolver assignments and permanent, non-transferable names.

That is the model XNS demonstrates: one shared root, many namespaces, one deterministic resolution path, and no mechanism through which an existing payment identifier can later be reassigned to someone else.

Without a canonical root, human-readable names remain wallet-dependent aliases.

With one, they can become predictable and secure payment identifiers.