Ghost_Name

GhostName: Keep the ENS name. Break the payment graph.

GhostName is an open privacy layer for ENS that gives established identities forward privacy without asking users to abandon the name and reputation they have already built.

An ENS name is useful because it connects a human-readable identity to a wallet. That same convenience creates a permanent privacy problem. When a name resolves to one static address, anyone can connect that identity to its balances, counterparties, payment history and future activity.

Blockchain history cannot be deleted. GhostName therefore focuses on the part users can still control: the next payment.

How GhostName works

The recipient generates an ERC-5564 spending key and viewing key locally in their browser, then publishes the resulting stealth meta-address as an ENS text record:

1stealth-meta-address[1]

When a sender enters the recipient’s ENS name, GhostName reads that public record and derives a fresh one-time receiving address locally.

A new cryptographically secure ephemeral key is generated for every payment, so paying the same ENS name multiple times produces different destinations:

1name.eth → 0xA
2name.eth → 0xB
3name.eth → 0xC

The ENS name remains the stable human-readable identity, but the receiving address is no longer reused.

The sender transfers funds to the derived address and publishes the corresponding ERC-5564 announcement. The recipient scans announcements using their private viewing key, recognises the payments that belong to them and derives the corresponding stealth spending key locally.

An unrelated viewing key cannot identify the payment.

The result is a complete private-receiving lifecycle:

1ENS name
2→ stealth meta-address
3→ fresh local derivation
4→ payment
5→ ERC-5564 announcement
6→ private recipient recognition
7→ spending-key recovery

Why ENS is essential

ENS is not used as decoration or simply displayed next to a wallet address.

It is the discovery and identity layer that makes the privacy mechanism usable.

Without ENS, a sender would need to obtain and verify a long stealth meta-address through another channel. With GhostName, the recipient publishes one privacy record under the ENS identity they already use. Compatible senders can then pay the human-readable name while deriving a unique destination for every transaction.

GhostName follows the emerging ENS stealth-resolution proposal and uses the stealth-meta-address[1] record convention for ERC-5564 scheme 1.

The functional relationship is:

1ENS provides identity and discovery.
2ERC-5564 provides one-time receiving addresses.
3GhostName connects them through a browser-based, gateway-free flow.

No address-generation gateway

Many stealth-payment systems rely on a hosted resolver or gateway to generate receiving addresses.

GhostName deliberately takes the strict client-side approach.

The sender’s browser reads the recipient’s public meta-address from ENS and independently generates the ephemeral randomness used to derive the destination. No GhostName server generates the address, receives the recipient’s viewing key or maintains a database of all receiving addresses.

GhostName currently has no backend.

All privacy-critical operations happen locally:

• spending and viewing key generation;
• stealth-address derivation;
• payment recognition;
• spending-key recovery;
• recovery-capsule encryption;
• sponsored sweep authorisation.

This reduces the amount of infrastructure users must trust and makes the complete implementation independently inspectable.

Privacy must survive the first spend

Receiving funds at a fresh address is only part of the problem.

A new stealth address normally holds funds but has no ETH for gas. Sending gas to it from the recipient’s public wallet would create an obvious onchain link and undo much of the privacy gained through the stealth payment.

GhostName addresses this with a sponsored EIP-7702 sweep.

After recognising a payment, the recipient uses the recovered stealth key to sign a destination-bound authorisation locally. A sponsor submits the EIP-7702 type-4 transaction and pays the gas, allowing the funds to leave the stealth address without the address first receiving gas from the recipient’s known wallet.

The full sponsored sweep has been demonstrated live on Sepolia:

1stealth payment received
2→ spending key recovered locally
3→ EIP-7702 authorisation signed
4→ sponsor submits transaction
5→ sponsor pays gas
6→ stealth address is swept

The demo executor is intentionally described as unaudited testnet code. The project does not claim production readiness for the contract.

A real, non-hard-coded demonstration

GhostName uses skrillah.eth, an ENS identity with years of history, as a read-only example of the problem.

The application resolves the real mainnet name and shows how a static ENS mapping exposes a wallet to public correlation. It does not attempt to alter, clear, transfer or delete the name.

The privacy-enabled flow uses a controlled Sepolia ENS identity.

The live demonstration includes:

1. Resolving an established ENS identity and showing its static wallet mapping.
2. Explaining that its historical blockchain activity cannot be erased.
3. Reading a real stealth-meta-address[1] record from ENS.
4. Deriving multiple fresh destinations from the same ENS name.
5. Proving that the generated addresses are different.
6. Sending a real Sepolia payment to a derived stealth address.
7. Publishing the ERC-5564 announcement.
8. Recognising the payment with the correct viewing key.
9. Showing that an unrelated viewing key recognises nothing.
10. Recovering and verifying the stealth spending key.
11. Demonstrating a sponsored EIP-7702 sweep.

Inputs can be pre-filled for presentation reliability, but addresses and cryptographic results are generated live. The implementation works with arbitrary ENS names rather than a hard-coded demo identity.

Public exposure analysis with Mobula

GhostName also uses the Mobula API to demonstrate why static ENS resolution matters.

After resolving the conventional wallet address associated with an ENS name, the application can assemble a public portfolio summary showing how much financial information can be inferred from the name-to-address relationship.

The interface shows high-level token and chain information first. Portfolio value remains behind a deliberate reveal control so private financial information is not unexpectedly displayed during a public presentation.

Mobula reinforces the central problem:

1Human-readable identity
2→ static public wallet
3→ machine-readable financial profile

GhostName reduces that direct relationship for future incoming payments.

Encrypted recovery with Swarm

Recipients need a safe way to preserve the viewing and spending material required to recover future payments.

GhostName can create a testnet recovery capsule encrypted locally using AES-256-GCM and a key derived from the user’s passphrase. The serialised capsule does not contain plaintext private keys and is suitable for storage on Swarm.

The passphrase and unencrypted keys never leave the browser.

The project also includes tooling for deploying the static application to Swarm through a Bee node and funded postage stamp.

GhostName does not claim that decentralised storage can erase information that another party has already downloaded. Recovery and access-control limitations are documented explicitly.

What GhostName protects

GhostName protects against straightforward linkage between an ENS identity and its future receiving addresses by ordinary passive blockchain observers.

It helps prevent:

• repeated recipient-address reuse;
• direct ENS-to-future-receiving-address correlation;
• reliance on a gateway to generate fresh payment addresses;
• public disclosure of the recipient’s viewing and spending secrets;
• gas-funding transactions that immediately reconnect a stealth address to a known wallet.

What GhostName does not protect

GhostName is forward recipient-address privacy, not complete transaction anonymity.

It does not hide:

• historical blockchain activity;
• ownership of the ENS name;
• the public stealth meta-address record;
• the sender’s wallet;
• ordinary ETH or ERC-20 transfer amounts;
• transaction timing;
• RPC, browser or network metadata;
• unsafe withdrawal destinations;
• information exposed by a compromised device;
• viewing or spending keys that the user leaks.

GhostName is not a mixer, does not delete history and does not claim to make transactions untraceable.

These boundaries are visible in both the application and the project documentation.

Technical implementation

GhostName is built as a browser-first TypeScript application using:

• React and Vite;
• viem for Ethereum and ENS interactions;
• maintained secp256k1 primitives from @noble/curves;
• ERC-5564 scheme 1;
• the ERC-5564 announcer singleton;
• ENS Universal Resolver support;
• EIP-7702 sponsored account execution;
• EIP-3009 authorisations for compatible ERC-20 tokens;
• Web Crypto for encrypted recovery capsules;
• Mobula for public exposure analysis;
• Swarm deployment and encrypted-storage tooling;
• Vitest for deterministic, interoperability and live-network tests.

The ERC-5564 implementation has been cross-checked against an existing stealth-address SDK and includes positive, negative, malformed-input, randomness, recognition and spending-key recovery tests.

Mainnet is read-only by default. Test writes and payments use Sepolia, while optional mainnet write support requires both an explicit build-time flag and a typed confirmation for every action.

Why GhostName is different

GhostName is not trying to become another managed privacy wallet.

Its purpose is to provide an open and verifiable privacy upgrade for an ENS identity the user already owns.

The user does not need to:

• accept a new protocol-owned username;
• move their identity onto a hosted resolver;
• share a viewing capability with GhostName;
• trust a service to generate fresh receiving addresses;
• abandon the history and reputation attached to their ENS name.

GhostName instead provides a standards-based path from an existing public identity to forward-private receiving.

The project’s core idea is simple:

Blockchains do not have a delete button. GhostName gives established identities a forward-privacy button.

Keep the ENS name. Break the payment graph.