The reuse bug
Usually when crypto people talk about "privacy," they mean something dramatic—zero-knowledge proofs, mixing protocols, chain-hopping. The pitch is always the same: cryptographic wizardry that makes funds untraceable.
But here's the thing nobody wants to admit: most privacy leaks on Ethereum aren't sophisticated attacks. They're just address reuse. You post your ENS on Twitter, someone sends you a tip, and suddenly every transaction you've ever made is one Etherscan click away. The problem isn't that Ethereum lacks privacy tech—it's that the default UX makes privacy impossible.
Stealth addresses fix this. Not with mixing. Not with layer-2 magic. Just with a clever key derivation trick that's been around since the Bitcoin days but finally has a proper standard.
The core idea is almost disappointingly simple: instead of Bob publishing one address that everyone pays, Bob publishes a recipe for generating unlimited one-time addresses that only he can control. Alice uses the recipe, derives a fresh address, sends funds there, and leaves a breadcrumb so Bob can find it. Observers see "payment to some random EOA." Bob sweeps the funds at his leisure.
This is recipient unlinkability—and it turns out that's the privacy primitive most people actually need.
The envelope and the key
Bob has two keypairs: a spending key (the deriving key) and a viewing key (the scanner key). Think of the spending key as the safe combination and the viewing key as the security camera footage. Bob can give his accountant the viewing key to track inflows without letting them actually move funds. This separation matters for compliance, delegation, and not losing sleep at night.
Bob publishes both public keys as his "stealth meta-address"—a URI that looks like st:eth:0x<spendingPubKey><viewingPubKey>. That's the recipe.
When Alice wants to pay Bob, she doesn't send to some static address. Instead, she:
- Generates a random ephemeral keypair (one-time use, per payment)
- Combines her ephemeral private key with Bob's viewing public key to create a shared secret
- Uses that secret to "twist" Bob's spending public key into a brand-new stealth public key
- Derives the Ethereum address from that stealth public key
The result: a fresh EOA that has never appeared on-chain before. Alice sends funds there, and now she needs to tell Bob how to find them.
This is where the "envelope" comes in. Alice calls a singleton Announcer contract that emits an event with her ephemeral public key and some metadata. Bob monitors these events. When he sees one, he can reverse the math—using his viewing private key this time—to check if the announced address belongs to him. If it does, he derives the stealth private key and takes control.
The elegant part: Alice never learns Bob's spending private key. Bob never learns Alice's ephemeral private key. The shared secret exists only as a cryptographic artifact that both can compute independently.
The view tag tradeoff
In theory, Bob just watches the Announcer contract and checks every event. In reality, if you're scanning millions of announcements, that's a lot of expensive elliptic curve operations.
The fix is the view tag—a single byte (the first byte of the hashed shared secret) that Alice includes in her announcement. Bob can check this byte before doing the heavy math. If it doesn't match what he'd compute, he skips the event. With 256 possible byte values, Bob eliminates ~255/256 of events with a trivial comparison.
The tradeoff is real but minor. That one byte technically leaks information—the ERC notes it reduces the security margin from 128 bits to 124 bits. For context, 124 bits is still "heat death of the universe" territory for brute-force attacks. The scanning cost reduction is roughly 6×.
The bulletin board problem
ERC-5564 solves one problem that previous stealth address proposals never quite nailed: discovery.
Without a standard, every dapp would invent its own announcement mechanism. Bob would need to scan every contract, every event signature, every chain. It's the same fragmentation problem that plagued early DEXes before AMM standards emerged.
The fix is a singleton ERC5564Announcer contract deployed at the same address on every chain: 0x55649E01B5Df198D18D95b5cc5051630cfD45564. One contract, one event signature, one place to watch.
This is the "bulletin board" model. All stealth announcements go through the same doorway. Recipients (or their scanning services) can index one well-known event stream instead of every corner of the chain.
The companion standard, ERC-6538, handles the other half: where does Bob publish his stealth meta-address in the first place? It's a simple registry mapping (address, schemeId) → stealthMetaAddress. Alice can look up Bob's ENS, resolve it to an address, query the registry, and start deriving stealth addresses—all without Bob being online.
Boring infrastructure. Essential plumbing.
The metadata sidecar
When Alice announces a payment, she includes a structured blob that tells Bob (and his wallet) what's inside. For native ETH:
- Byte 1: the view tag
- Bytes 2–5:
0xeeeeeeee(sentinel for native token) - Bytes 6–25:
0xEeee...EEeE(the canonical "native ETH" placeholder address) - Bytes 26–57: the amount sent (as a 32-byte uint256)
For ERC-20s or NFTs, the structure includes the function selector and token contract address.
This isn't just cosmetic. Without metadata, stealth announcements are opaque—Bob's wallet shows "you received something at some address" with no context. With metadata, the wallet can display "1 ETH received" or "USDC transfer" like any normal transaction. The gap between "experimental privacy tool" and "thing normal people use" lives in details like this.
What stealth addresses don't do
Let's be precise about the threat model, because this is where people get confused.
Stealth addresses provide recipient unlinkability: an observer watching the chain can't connect a payment to Bob's known identity just by looking at the destination address.
They do not provide untraceability. The funds Alice sends come from her address. If Alice is known, observers can see "Alice sent 1 ETH to some random EOA." They just can't prove it's Bob on the other end.
Moreover—and this is critical—when Bob sweeps funds from the stealth address to his main wallet, the link becomes obvious. "Random EOA sends to Bob's known address" is pretty damning. Practical privacy requires Bob to either:
- Keep funds in stealth addresses and spend directly from them, or
- Use mixers/bridges to break the link when consolidating
Stealth addresses are a building block, not a complete privacy solution. They solve the "don't let my salary hit my public ENS address" problem. They don't solve "hide from a nation-state with chain analytics."
Stealth vs. everything else
People conflate stealth addresses with adjacent privacy tools. Here's the disambiguation.
Stealth addresses vs. mixers. Mixers break source-of-funds traceability—they obscure where money came from. Stealth addresses break recipient identity linkability—they obscure who money went to. These are orthogonal privacy properties. Complementary, not substitutes. And yes, partisans will keep arguing about whether stealth without mixing is "security theater." The more honest framing: it's one privacy property, not the whole set.
Stealth addresses vs. "just use a new address." On Bitcoin, handing out fresh addresses is normal workflow. On Ethereum, users can do that, but there's no standard way for someone to pay "Bob's current fresh address" without out-of-band coordination. Stealth is exactly that mechanism: a way to pay Bob's ever-changing address without asking him first.
Stealth addresses vs. shielded pools. Shielding systems (Tornado, Aztec, etc.) can hide more—amounts, transaction graphs, the works. But they add new trust surfaces, new constraints, and often, new regulatory heat. Stealth addresses are the lowest-common-denominator privacy primitive: they live inside normal wallets with minimal protocol disruption. Less powerful, more deployable. A familiar tradeoff.
The category error to avoid: expecting stealth addresses to solve problems they weren't designed for. They're address hygiene, not anonymity infrastructure. Boring scope. Clear wins.
The gas problem (and why is fixed with AA)
When Alice sends native ETH to a stealth address, Bob can spend from that address immediately—gas comes out of the ETH balance. No problem.
When Alice sends an ERC-20 or NFT, the stealth address is just an empty EOA. It has no ETH for gas. Bob needs to fund it before he can move the tokens, and that funding transaction creates a link. "Fresh address receives exactly enough ETH for gas" is a fingerprint.
Solutions exist—ERC-4337 paymasters, meta-transactions, or specialized relayers—but they're not turnkey yet. For now, native ETH transfers are the smoothest stealth address UX. Token transfers require more infrastructure.
This is why the ERC-5564 spec mentions bundling the ETH send and the announcement into a single transaction (via account abstraction or EIP-7702). The sender can prepay gas for the recipient without a second on-chain step.
The scheme registry escape hatch
One more design choice worth noting: ERC-5564 doesn't hardcode a single cryptographic scheme. Instead, it introduces a schemeId that identifies which algorithm to use.
Scheme 1 (secp256k1 + view tags) is the default and what most implementations target. But the spec explicitly leaves room for future schemes—post-quantum algorithms, different curves, alternative hash functions.
This is defensive engineering. Cryptographic standards have a way of aging poorly (see: MD5, SHA-1). By baking scheme flexibility into the announcement format, ERC-5564 avoids the "hard fork to upgrade crypto" problem. A new scheme just gets a new ID; old announcements stay parseable.
So what might the future look like?
Stealth addresses are live on mainnet. The Announcer contract exists. The registry exists. A handful of wallets—Umbra being the most mature—already support the flow.
Adoption is another matter. The UX gaps are real: most wallets don't scan announcements, don't render stealth meta-addresses, and don't help users register their keys. Until that changes, stealth addresses remain a power-user feature.
But the infrastructure is finally in place. And historically, once the plumbing exists, the products follow.
The honest assessment: stealth addresses won't give you Monero-level privacy on Ethereum. What they will give you is basic financial hygiene—the ability to receive payments without doxxing your entire transaction history. It turns out that's what most users actually want.