Author: Vitalik Buterin
Translated by: DeFi Dao
Special thanks to Ben DiFrancesco, Matt Solomon, Toni Wahrstätter, and Antonio Sanso for their feedback and review.
Privacy remains one of the biggest challenges in the Ethereum ecosystem. By default, anything on a public blockchain is visible to everyone. This increasingly includes not just financial transactions, but also ENS names, POAPs, NFTs, soulbound tokens, and more. In practice, using Ethereum's full suite of applications means exposing significant parts of your life to public scrutiny and analysis.
Improving this situation is a widely recognized priority. However, discussions on privacy have largely focused on one specific use case: private transfers of ETH and mainstream ERC-20 tokens (typically self-transfers). This article explores a different category of tools that can enhance Ethereum's privacy across many other scenarios: stealth addresses.
What is a Stealth Address System?
Imagine Alice wants to send an asset to Bob. This could be cryptocurrency (like 1 ETH or 500 RAI) or an NFT. Bob wants to receive it without the world knowing. Hiding the fact that a transfer occurred might be impossible—especially for a unique NFT—but hiding the recipient's identity is more feasible. Both Alice and Bob want a simple process: Bob shares a single "address" (or registers it on ENS) that anyone can use to pay him, with no extra steps.
This differs from the privacy offered by tools like Tornado Cash. While Tornado Cash can hide transfers of mainstream fungible assets like ETH or major ERC-20 tokens (it's easiest for private self-transfers), it's less effective for obscure ERC-20 tokens and doesn't work for NFTs at all.
The standard cryptocurrency payment workflow. Our goal is to add privacy (so no one knows Bob received the asset) without changing how it works.
Stealth addresses provide exactly this. A stealth address can be generated by either Alice or Bob, but only Bob can control it. Bob generates and keeps a secret spending key, which he uses to create a stealth meta-address. He shares this meta-address with Alice (or registers it on ENS). Alice can then perform a computation on it to generate a unique stealth address that belongs to Bob. She sends the asset to this address, and Bob retains full control. Along with the transfer, Alice publishes some encrypted data on-chain (a temporary public key) to help Bob recognize the address as his.
In other words, stealth addresses give Bob the same privacy as generating a new address for every transaction, but without requiring any action on his part.
The complete stealth address workflow is shown below:
1. Bob generates his root spending key (m) and his stealth meta-address (M).
2. Bob registers M as his stealth meta-address on ENS under the name bob.eth.
3. Alice, knowing Bob is bob.eth, looks up his stealth meta-address M on ENS.
4. Alice generates a one-time-use ephemeral key (to create this specific stealth address).
5. Using an algorithm that combines her ephemeral key with Bob’s meta-address, Alice generates a stealth address. She can now send assets to this new address.
6. Alice also generates and publishes her ephemeral public key to a public registry. This can be done in the same transaction used to send assets to the stealth address.
7. To discover stealth addresses that belong to him, Bob must scan the ephemeral public key registry. He reviews all keys published since his last scan, regardless of who published them or why.
8. For each ephemeral public key, Bob attempts to combine it with his root spending key to generate a potential stealth address. He then checks if that address holds any assets. If it does, he computes the corresponding spending key and saves it.
This entire process relies on two applications of cryptographic blinding. First, we need a pair of algorithms to generate a shared secret: one uses Alice’s secret (her ephemeral key) and Bob’s public information (his meta-address), while the other uses Bob’s secret (his root spending key) and Alice’s public information (her ephemeral public key). This can be achieved in several ways; Diffie-Hellman key exchange—a cornerstone of modern cryptography—performs exactly this function.
However, a shared secret alone isn't enough. If we simply derived a private key from it, both Alice and Bob could spend from the resulting address. We could stop here and have Bob transfer funds to a new address, but that would be inefficient and would unnecessarily reduce security. Therefore, we introduce an additional key blinding mechanism. This involves a pair of algorithms that allow Bob to combine the shared secret with his root spending key, and Alice to combine it with Bob’s meta-address. This enables Alice to generate the stealth address and Bob to generate its spending key, all without creating any public link between the stealth address and Bob’s meta-address (or between one stealth address and another).
Stealth Addresses Using Elliptic Curve Cryptography
Stealth addresses using elliptic curve cryptography were first proposed by Peter Todd in 2014 for Bitcoin. The technique works as follows (assuming familiarity with basic elliptic curve cryptography; see here, here, and here for tutorials):
• Bob generates a private key m and computes his public key M = G * m, where G is the agreed-upon generator point on the elliptic curve. The encoded form of M is his stealth meta-address.
• Alice generates an ephemeral private key r and publishes the corresponding ephemeral public key R = G * r.
• Alice can compute a shared secret S = M * r, while Bob can compute the same shared secret S = m * R.
• In Bitcoin and Ethereum (including properly designed ERC-4337 accounts), addresses are typically hashes of public keys used to verify transactions. So, if you have the public key, you can derive the address. To compute the public key for the stealth address, Alice or Bob calculates P = M + G * hash(S).
• To compute the corresponding private key, Bob (and only Bob) calculates p = m + hash(S). This elegantly satisfies all our requirements—and is remarkably simple!
Today, there is even an EIP attempting to define a stealth address standard for Ethereum. It supports this method while leaving room for alternative approaches (e.g., allowing Bob to have separate spending and viewing keys, or using different cryptography for quantum resistance). You might now think stealth addresses are straightforward—the theory is solid, and adoption is just a matter of implementation. However, the real challenge lies in navigating several significant implementation details to make it truly effective.
Stealth Addresses and Paying Transaction Fees
Imagine someone sends you an NFT. To protect your privacy, they send it to a stealth address you control. Your wallet automatically detects this address by scanning the ephemeral public key on-chain. Now you can prove ownership or transfer the NFT freely. But there's a catch: the ETH balance in that stealth address is zero, so it can't pay for the transaction fee. Even ERC-4337 token paymasters won't help, as they only support fungible ERC-20 tokens. And you can't simply send ETH from your main wallet to fund it, because that would create a public link between the two addresses.
Writers often drop memes of 2017-era (or earlier) crypto scam figures to signal their experience and credibility—it shows they've been around long enough to have refined tastes and aren't easily fooled by the likes of SBF.
One "simple" solution is to use ZK-SNARKs to transfer funds for fee payment. However, this approach consumes a significant amount of gas—adding hundreds of thousands of gas units per transfer.
A more clever approach involves trusting specialized transaction aggregators (known as "searchers" in MEV terminology). These aggregators let users buy a batch of "tickets" upfront to pay for on-chain transaction fees. When a user needs to spend an NFT from an empty stealth address, they provide one of these tickets to the aggregator, encoded using Chaumian blinding—a protocol originally designed for centralized privacy-preserving e-cash in the 1980s and 1990s. The searcher accepts the "ticket" and repeatedly includes the transaction for free in their bundles until it lands in a block. Since the amounts are small and tickets can only be used to pay fees, the trust and regulatory concerns are far lower than those associated with implementing a full-fledged centralized privacy-preserving e-cash system.
Stealth Addresses and Separating Spending and Viewing Keys
Suppose Bob doesn't want a single master "root spending key" for all operations. Instead, he prefers separate root spending and viewing keys. The viewing key can see all of Bob's stealth addresses but cannot spend from them.
In the elliptic curve world, this can be solved with a straightforward cryptographic trick:
• Bob’s meta-address M now takes the form (K, V), encoded as G * k and G * v, where k is the spending key and v is the viewing key.
• The shared secret is now S = V * r = v * R, where r remains Alice’s ephemeral key and R remains Alice’s published ephemeral public key.
• The stealth address’s public key is P = K + G * hash(S), and its private key is p = k + hash(S).
Note that the first cryptographic step (generating the shared secret) uses the viewing key, while the second step (the parallel algorithm Alice and Bob use to generate the stealth address and its private key) uses the root spending key.
This setup has many use cases. For example, if Bob wants to receive POAPs, he can give his POAP wallet (or even a less secure web interface) his viewing key to scan the chain and view all his POAPs—without granting that interface the ability to spend them.
Stealth Addresses and Easier Scanning
To make scanning all ephemeral public keys easier, one technique is to add a view tag to each one. In the mechanism described above, this can be implemented by making the view tag a single byte of the shared secret—for example, the x-coordinate of S mod 256, or the first byte of hash(S).
This way, Bob only needs to perform one elliptic curve multiplication per ephemeral public key to compute the shared secret. He only needs to perform the more complex computation required to generate and verify the full address for about 1/256 of the ephemeral public keys.
Stealth Addresses and Post-Quantum Security
The scheme above relies on elliptic curves, which are excellent—but unfortunately vulnerable to quantum computers. If quantum computers become a practical threat, we'll need to migrate to post-quantum algorithms. Two natural candidates are elliptic curve isogenies and lattices.
Isogeny-based cryptography offers a fundamentally different mathematical approach built on elliptic curves. Its linear properties allow for cryptographic techniques similar to those mentioned earlier, but with a clever twist: it avoids creating the cyclic groups that are vulnerable to quantum computer-based discrete logarithm attacks.
The main drawback of isogeny-based cryptography is its highly complex underlying mathematics, which carries the risk that potential attacks could be hidden within this complexity. Last year, several isogeny-based protocols were broken, though others remain secure. Its key advantages are relatively small key sizes and the ability to directly adapt many existing elliptic-curve-based methods.
3-isogenies in CSIDH. Source: here.
Lattice-based cryptography represents another fundamentally different structure. It relies on mathematics that is significantly simpler than elliptic-curve isogenies and enables some exceptionally powerful capabilities, such as fully homomorphic encryption (FHE). Stealth address schemes can be built on top of lattices, although designing optimal lattice-based schemes remains an open challenge. A typical trade-off is larger key sizes.
Fully homomorphic encryption—an application of lattice cryptography. FHE can also assist stealth address protocols in another way: it allows Bob to outsource the computation of checking for assets at his stealth addresses across the entire chain, without revealing his view key.
A third approach constructs stealth address schemes from generic black-box primitives—basic cryptographic components used for other purposes. The shared-secret generation portion maps directly to key exchange, a core component of public-key encryption systems. The harder part is designing parallel algorithms that allow Alice to generate only stealth addresses (not spending keys), while Bob generates the corresponding spending keys.
Unfortunately, stealth addresses cannot be built using components simpler than those required for public-key encryption. A simple proof exists: one can construct a public-key encryption system from a stealth address scheme. If Alice wants to encrypt a message for Bob, she can send N transactions—each either to one of Bob’s stealth addresses or to one of her own—and Bob reads the message by observing which transactions he receives. This matters because mathematical proofs show public-key encryption cannot be built from hashes alone, whereas zero-knowledge proofs can. Therefore, stealth addresses also cannot be implemented using hashes alone.
Here is one approach that uses relatively simple ingredients: zero-knowledge proofs composed of hashes and (key-hiding) public-key encryption. Bob’s meta-address includes a public encryption key plus a hash h = hash(x); his spending key consists of the corresponding decryption key plus x. To create a stealth address, Alice generates a value c and publishes it, encrypted for Bob's readability, as her ephemeral public key. The address itself is an ERC-4337 account whose code validates transactions by requiring a zero-knowledge proof demonstrating ownership of both x and c such that k = hash(hash(x), c) (where k is the account’s code). Knowing x and c, Bob can reconstruct the address and its code himself.
The encryption of c reveals no information about c to anyone else—including Bob—and k is a hash, which leaks almost no information about c. The wallet code itself contains only k, while c remains private. This means k cannot be traced back to h.
However, this requires a STARK, and STARKs are large. In the end, I believe the post-quantum Ethereum ecosystem will likely involve many applications using numerous STARKs. Therefore, I advocate for aggregation protocols—like the one described here, which combine all these STARKs into a single recursive STARK—to save space.
Stealth Addresses, Social Recovery, and Multi-L2 Wallets
For a long time, I have advocated for social recovery wallets: multi-signature wallets where keys are distributed among institutions, your other devices, and trusted friends. A majority of these keys can restore access to your account if you lose your primary private key.
However, social recovery wallets do not integrate well with stealth addresses. If you need to recover your account (i.e., change the private key controlling it), you must also update the account validation logic across all N of your stealth wallets. This requires N transactions, incurring high costs in fees, convenience, and privacy.
Similar concerns apply to how social recovery interacts with multiple Layer 2 protocols. If you have accounts on Optimism, Arbitrum, Starknet, Scroll, and Polygon—and potentially dozens of parallel instances within some of these rollups for scalability, each with its own account—changing your keys could become a logistical nightmare.
Updating keys across numerous accounts and chains is a massive undertaking.
One option is to simply accept that recovery is a rare event, and that its high cost and complexity are tolerable. You could, for instance, use automated software to gradually move assets to new stealth addresses over a two-week period, reducing the risk of time-based analysis. But this is an imperfect workaround. Another approach is to privately share the root key with guardians instead of using smart contracts for recovery. However, this removes your ability to revoke a guardian’s access, creating long-term security risks.
A more advanced solution involves zero-knowledge proofs (ZKPs). Take the ZKP-based scheme mentioned earlier, but adjust the logic: instead of storing k = hash(hash(x), c) directly, the account holds a hidden on-chain commitment to k’s location. To spend from that account, you’d need to provide a zero-knowledge proof that (i) you know the on-chain location matching that commitment, (ii) the object at that location contains some value k (which remains hidden), and (iii) you possess values x and c such that k = hash(hash(x), c).
This allows many accounts—even across multiple Layer 2 protocols—to be controlled by a single k value stored somewhere (on the base chain or a Layer 2). Changing that one value transfers ownership of all linked accounts, without ever revealing the connections between them.
Conclusion
Basic stealth addresses could be implemented relatively quickly today and would greatly enhance practical privacy for Ethereum users. They do require wallets to add support, but I believe wallets should already be moving toward more native multi-address models—generating a new address for each application you use—for broader privacy reasons anyway.
That said, stealth addresses do introduce long-term usability trade-offs, particularly around social recovery. For now, we might accept these limitations—for example, by acknowledging that social recovery could mean sacrificing some privacy or enduring a two-week delay while recovery transactions are slowly broadcast across assets (a process potentially handled by third-party services). In the long run, these challenges are solvable, but it’s clear that a mature stealth address ecosystem will rely heavily on zero-knowledge proofs.