How to Use Stealth Addresses on Ethereum (EIP-5564)

In April 2026, Vitalik Buterin's "Statelessness, Stealth, and Soul-Bound Tokens" roadmap update pushed EIP-5564 back into the spotlight: roughly 1.4 million Ethereum addresses now appear on at least one Chainalysis cluster, and the gap between "pseudonymous" and "private" has never felt wider. EIP-5564 is Ethereum's answer to that gap — a standardized way to receive ETH, ERC-20, or ERC-721 transfers at a freshly derived one-time address that an outside observer cannot link to your public ENS name or main wallet. The idea is borrowed almost verbatim from Monero, where stealth addresses have been default behavior since 2014, but adapted to fit Ethereum's account-based, EVM-native world. This guide walks you through how the standard works, how to use it with current wallet tooling, how it compares to Monero's mature implementation, and where the obvious foot-guns are. If you ultimately want to convert your private ETH into XMR for stronger guarantees, MoneroSwapper handles the no-KYC bridge — but first, let's understand what stealth addresses actually buy you on Ethereum itself.

Why Ethereum needed stealth addresses

Ethereum's default privacy story has always been awkward. Every transaction publicly ties a sender, recipient, and value to two long-lived addresses, and ENS names make those addresses human-readable on Etherscan with a single click. Once you donate to a public address, settle a tip, receive an airdrop, or accept a salary in stablecoins, the receiving address is forever linked to your on-chain history. Tornado Cash filled part of this gap until OFAC sanctioned the smart contract in August 2022 and the subsequent convictions of two of its developers in 2024 froze most legitimate consumer use.

EIP-5564 takes a different angle. Instead of pooling funds in a shared anonymity set, it lets the sender derive a brand-new, one-time recipient address that only the actual recipient can spend from — without any prior coordination, without a smart-contract mixer, and without ever sharing the recipient's main private key. The properties it provides are:

• Unlinkability: outsiders cannot tell that two stealth payments belong to the same recipient, even if the recipient's meta-address is published publicly.
• Non-interactivity: the sender needs only the recipient's published meta-address — no prior handshake, no shared symmetric key, no Tor bridge.
• Scanning-only access: a viewing key lets external services (a hot wallet, a watch-only server, a phone app) detect inbound payments without holding spending power.
• Backward compatibility: the standard works for ETH, ERC-20, ERC-721, and ERC-1155 transfers without changing any token contract on either chain.

The trade-off is that EIP-5564 does not hide transaction values, and it does not break the link between a stealth output and the eventual address it's swept into. It is not RingCT. But for everyday use — paying a freelancer, receiving an NFT drop, accepting a donation, settling a salary — it dramatically reduces what an outside observer can correlate against your public identity.

How EIP-5564 actually works

EIP-5564 — authored by Toni Wahrstätter, Matt Solomon, Ben DiFrancesco, and Gary Ghayrat and finalized as a Standards Track ERC in March 2024 — defines two artifacts: a canonical scheme for deriving stealth addresses from a recipient's published meta-address, and a singleton announcer contract that posts ephemeral public keys so recipients can find their payments without having to scan the entire chain.

The meta-address: two keys, not one

Every EIP-5564 recipient publishes a stealth meta-address of the form st:eth:0x.... It encodes two compressed secp256k1 public keys concatenated together:

• Spending public key (P): derived from a long-lived spending private key that the recipient keeps offline, ideally on a hardware wallet.
• Viewing public key (V): derived from a viewing private key the recipient can hand to watch-only software without exposing spend power.

This split is exactly the same View key and Spend key separation Monero adopted from CryptoNote in 2014. The spending key signs outgoing transfers; the viewing key lets a wallet detect inbound payments without being able to move them. That separation is what allows a Ledger or Trezor to hold the spending key while a hot wallet on your laptop runs the scanner in the background.

Deriving a one-time address

To send to a stealth meta-address, the sender executes the following protocol on the client side, with no on-chain interaction until the final step:

1. Generate a fresh, random ephemeral private key r and compute its public key R = r·G, where G is the secp256k1 generator.
2. Compute a shared secret S = r·V via standard ECDH against the recipient's viewing public key.
3. Hash the shared secret: s = keccak256(S).
4. Derive the stealth public key P_stealth = P + s·G.
5. Take the Ethereum address of P_stealth. This becomes the one-time recipient.
6. Send funds to that one-time address and call the Announcer contract with the ephemeral public key R, the view-tag byte, and a scheme identifier.

The recipient — or, more precisely, a scanning service holding the viewing key — sees the announcement, recomputes s = keccak256(v·R) (where v is the viewing private key), derives the same P_stealth, and finds the funds parked at the corresponding Ethereum address. Only the holder of the spending private key can then sign a transaction from that address: the per-output spending private key is p_stealth = p_spend + s.

The view-tag optimization

Naively, every recipient would have to derive P_stealth for every announcement on chain — millions of operations per day at scale. EIP-5564 includes a single-byte view-tag in each announcement: the first byte of keccak256(S). Scanners can discard 255 of every 256 announcements after a single byte comparison, so a typical recipient processes only about 0.4% of announcements in full. This puts EIP-5564 scanning costs in the same ballpark as Monero's view-key scanning after Monero 0.18 added the optional view-tag in 2022. The trick itself was originally documented by Zcash researchers in 2021 and has since become a standard pattern in stealth-address designs.

EIP-5564 vs Monero stealth addresses

Because Ethereum users frequently ask whether EIP-5564 makes Monero redundant, it's worth lining up the two designs explicitly. They share the same mathematical core but differ enormously in what the broader protocol hides — and in whether privacy is an opt-in feature or a baseline guarantee.

Property	EIP-5564 (Ethereum)	Monero (CryptoNote + RingCT)
One-time recipient address	Yes (per payment)	Yes (per output)
Sender anonymity	No — sender address is public	Yes — hidden by CLSAG ring signature
Amount hiding	No — visible in transfer logs	Yes — Pedersen commitments + Bulletproofs
Default usage	Opt-in per transaction	Mandatory for every output
View-key scanning	Yes (EIP-5564 viewing key)	Yes (Monero View key)
Network-level privacy	None standardized	Dandelion++ broadcast
Future hard-fork plans	None scheduled	FCMP++ / Seraphis Jamtis (in progress)
Anonymity-set size	All EIP-5564 announcements (~hundreds/day)	Entire UTXO set (post-FCMP++)

The short version: EIP-5564 hides who is being paid, while Monero additionally hides who is paying and how much they are paying. If your threat model is "casual on-chain surveillance" and you already live in the Ethereum ecosystem, EIP-5564 is a meaningful improvement on the status quo. If your threat model includes professional chain analytics with full graph clustering — or if you need fungibility on the receiving side — Monero remains structurally stronger because every output looks identical at the protocol layer.

Step-by-step: receiving and spending stealth payments

This walkthrough assumes you're using Umbra (umbra.cash) or the Fluidkey wallet, the two production-grade EIP-5564 implementations on Ethereum mainnet as of mid-2026. The flow is essentially identical on Base, Optimism, and Arbitrum, all of which deploy the same Announcer singleton at the canonical address. If you're testing the protocol, do it on Sepolia first — gas is free and the same SDK works.

1. Generate your stealth meta-address. Connect a wallet that holds your main signing key. Umbra and Fluidkey both derive your spending and viewing private keys deterministically from a signature over a fixed message — so you never need a separate Mnemonic seed, and you can recover access from any device that holds your main key.
2. Publish or share the meta-address. The output string looks like st:eth:0x03ab...c1de. You can register it against your ENS name (the resolver field stealth-meta-address is standardized in ERC-5564 and supported by the ENS public resolver) or just share the string out-of-band over Signal, email, or a payment-request page. Once published, anyone can pay you without further coordination.
3. Receive a payment. The sender derives a one-time address client-side and posts an announcement to the Announcer contract. Your wallet scans new announcements roughly every block, filters them by view-tag, and surfaces matching deposits in its UI within ~12 seconds of confirmation on mainnet (or ~2 seconds on most L2s).
4. Fund gas at the stealth address. Because each stealth output sits at a unique address with no existing ETH balance, spending requires gas. Wallets handle this in one of three ways: a sponsored meta-transaction via Gelato or Pimlico, a "pull" pattern where the receiver burns a small fraction of the inbound amount as gas, or a relayer the wallet bundles natively. Whatever you do, do not fund the gas from a doxxed wallet — that immediately links the output.
5. Spend or sweep. Sign the spend with your derived spending key. If you sweep multiple stealth outputs into one consolidated address, you immediately link them, so consolidate only when that linkage is acceptable. Otherwise, route through Railgun, into a fresh CEX deposit address, or — for full fungibility — convert to XMR via MoneroSwapper and receive at a brand-new Monero Subaddress.

Rule of thumb: a stealth output is only as private as the address you eventually sweep it into. Treat the sweep destination as the real privacy decision, not the stealth address itself.

Wallets and tooling in 2026

The EIP-5564 implementation landscape has consolidated in the eighteen months since the standard was finalized. As of mid-2026, the production-grade options are:

• Umbra Protocol: the reference implementation. Open-source frontend, deployed on Ethereum mainnet, Optimism, Arbitrum, Polygon PoS, Base, and Gnosis Chain. Supports ETH, any ERC-20, and ERC-721. Maintained by ScopeLift, audited by Trail of Bits in 2023.
• Fluidkey: a consumer-focused stealth wallet with iOS and Android apps, a Safe-account architecture, and integrated meta-transaction sponsoring so recipients never need to pre-fund a stealth address with ETH for gas. Raised a $1.8M seed round in November 2024, processed over $40M in stealth payments by end of 2025.
• Labyrinth: combines EIP-5564 stealth addresses with an Ethereum L2 mixer for amount-and-sender hiding. Closer to a full privacy stack, but still requires partial trust in the L2 operator and inherits its censorship policy.
• StealthSwap: a Uniswap-style frontend that lets you swap into a stealth address atomically. Useful for receiving the proceeds of a DEX trade without revealing your destination wallet to the executing relayer.
• Daimo Pay (Stealth mode): the newest entrant, added in February 2026. Targeted at recurring payments like payroll and subscriptions where automated stealth-address generation is the real win.

For developers, the canonical Announcer contract is deployed at 0x55649E01B5Df198D18D95b5cc5051630cfD45564 across all EVM chains that mirror Ethereum's address space — note the deliberate "5564" suffix matching the EIP number, a small but useful auditability tell. The reference SDK @scopelift/stealth-address-sdk handles meta-address parsing, ephemeral key generation, announcement encoding, and scanner-side view-tag filtering. Integrating it into an existing dApp takes roughly an afternoon for an experienced Solidity team.

Threat-model limits you should plan for

EIP-5564 is a real improvement, but a few categories of attacks remain. None of these are bugs in the standard — they're consequences of running a privacy upgrade on top of a transparent base layer, where the mempool, the block, and the receipts are still globally visible.

• Sender exposure: the sending address is still public. If you send from your main ENS address, the recipient is the only thing that's hidden, and a chain analyst can still build a graph of "who paid stealth addresses, when, and how much."
• Amount correlation: a 4.173 ETH stealth payment immediately followed by a 4.173 ETH transfer somewhere else strongly suggests linkage. Round numbers and outlier amounts are especially leaky.
• Timing correlation: stealth announcements are public; if you scan and sweep within the same minute, surveillance tools can narrow down which announcement was yours by simple time-window correlation.
• Sweep-side metadata: sweeping into Binance or Coinbase ties the stealth output to a KYC'd identity at the exchange's compliance vendor. Sweep into Railgun, an L2 mixer, or convert to XMR if you actually need to break the trail.
• Gas funding leak: if you fund the gas at a stealth address from a doxxed wallet, you've just labeled the output for any observer. Always use a relayer or self-funded sweep.
• Cross-chain MEV: some bridge relayers log the stealth address on their indexer side. Treat any bridge as a potential deanonymization surface and prefer atomic swap routes when possible.

FAQ

Does EIP-5564 make my Ethereum transactions fully private?

No. EIP-5564 hides the recipient of a payment — specifically, it breaks the link between your published address (or ENS name) and the address that actually receives the funds. It does not hide the sender's address, the transferred amount, or the timing. For a full fungibility guarantee where amounts, senders, and recipients are all hidden by protocol, you still need a chain like Monero, where every transaction uses ring signatures and amount commitments by default. Many users treat EIP-5564 as a "first hop" for receiving and then convert to XMR for storage and onward spending.

Do I need to share my private keys with a wallet provider to use stealth addresses?

No, but you do need to share your viewing private key with whatever software scans for incoming payments. The viewing key only grants the ability to detect payments, not to spend them. The spending private key — the one that can move funds — can remain on a hardware wallet or in cold storage. This is the same architecture Monero uses: a watch-only wallet on an always-on server using the view key, and a cold wallet for signing transactions with the spend key.

Why is EIP-5564 sometimes called "Vitalik's stealth proposal"?

Because Vitalik Buterin published the original draft in a blog post titled "An incomplete guide to stealth addresses" in January 2023, which kicked off the formal standardization that became EIP-5564. The cryptography itself is much older — Nicolas van Saberhagen's CryptoNote whitepaper introduced one-time addresses in 2013, and Monero shipped them in 2014. Vitalik's post deserves credit for popularizing the design within Ethereum and making it politically viable as an opt-in standard rather than a hard-fork change.

Can I use stealth addresses on Layer 2s like Base or Arbitrum?

Yes. The canonical EIP-5564 Announcer contract is deployed at the same address on every major EVM L2, including Base, Optimism, Arbitrum One, Polygon PoS, and Gnosis Chain. Umbra and Fluidkey both support cross-rollup stealth payments. Fees on L2 stealth payments are typically under $0.05 in 2026, which makes scanning costs negligible for end users and removes one of the biggest friction points the standard had on mainnet in 2024.

How does scanning cost compare to running a Monero wallet?

Roughly comparable, thanks to the shared view-tag optimization. A typical EIP-5564 scanner reads 1 byte of every announcement and only computes the full elliptic-curve derivation for the ~0.4% that pass the view-tag filter. Monero added the same trick in 2022; both ecosystems independently borrowed the idea from earlier Zcash research. On commodity hardware, a year of stealth announcements on Ethereum mainnet scans in a few seconds, which is faster than a fresh Monero wallet sync.

What happens if I lose my viewing key but still have my spending key?

You'd lose the ability to easily find your inbound payments, but not the ability to spend them once found. You could brute-force scan by deriving every possible stealth address from every announcement using your spending key alone, which is extremely expensive but feasible. In practice, both keys are derived deterministically from your main wallet signature in Umbra and Fluidkey, so you can re-derive the viewing key any time you reconnect the source wallet.

Conclusion

EIP-5564 is the most pragmatic privacy upgrade Ethereum has shipped since the Tornado Cash era — a real cryptographic primitive, not a marketing label, and one that maps cleanly onto the View key and Spend key separation Monero proved at scale a decade earlier. For payments, donations, salaries, and NFT drops, it removes the single most damaging surveillance signal on Ethereum: the persistent identity of the receiving address. It does not, however, hide senders or amounts, and the moment you consolidate stealth outputs into a transparent address you give back most of the privacy gain you just earned. The right mental model is "stealth addresses are a privacy primitive, not a privacy product." If your goal is full fungibility — outputs that look identical at the protocol layer, amounts that aren't visible, senders that aren't traceable — the cleanest workflow is to receive at a stealth address, then route through MoneroSwapper for a no-KYC ETH-to-XMR conversion landed at a fresh Monero Subaddress. From there, ring signatures, Bulletproofs, and Dandelion++ broadcast take care of the rest, and your on-chain footprint stops where the stealth address ended.