What Are Stealth Addresses?

Introduction

Stealth addresses are a way to receive blockchain payments without publishing a reusable on-chain destination that lets everyone map your incoming funds. That sounds almost contradictory: blockchains are public ledgers, so how can a sender pay you without revealing that they paid you? The answer is not to hide the payment entirely, but to hide the link between the payment and your long-lived identity.

This matters because ordinary addresses are great for routing value and terrible for privacy. If you post one address on a website, profile, ENS name, or invoice, anyone can often trace every payment that arrives there and correlate those payments with each other. Even if amounts are hidden or mixed later, the recipient side of the graph can still be exposed. Stealth addresses were designed to break that visible reuse.

The central idea is simple: the recipient publishes a meta-address or a pair of public keys, and each sender uses that public information to derive a fresh one-time destination for a payment. The sender and recipient can both compute that destination, but outside observers cannot link it back to the recipient’s published identity. The chain still sees a normal-looking payment to an address; what it does not see is that many different one-time addresses all belong to the same person.

That is the compression point: a stealth address is not one address. It is a recipe for generating a different address for each payment, in a way that preserves receiver control without requiring the receiver to be online for every transaction.

What privacy problem do stealth addresses solve?

A public blockchain needs an unambiguous destination for funds. If Alice wants to pay Bob, the network needs to know where the assets should go. The naive solution is that Bob posts an address and Alice sends funds there. Functionally, this works perfectly. Privacy-wise, it creates a permanent label.

Once that label exists, a lot follows. Anyone can see how often Bob is paid, when he is paid, and often by whom. If Bob uses the same address for donations, payroll, NFT receipts, marketplace settlements, or OTC transfers, those contexts become linkable. Even if Bob later moves funds through mixers, bridges, or exchanges, the original receiving pattern may already have revealed useful information. In many cases, receiver privacy is the first thing that breaks.

Stealth addresses try to preserve the convenience of a public payment identifier while removing the visible address reuse. Bob can still publish something stable, but what he publishes is no longer the destination itself. It is input to a derivation process that creates a unique destination per payment.

This is why stealth addresses are usually discussed as a receiver-privacy mechanism. They do not, by themselves, hide the sender, hide the amount, or fully shield transaction contents. In systems like Monero, stealth addresses sit alongside other privacy mechanisms, such as ring signatures, because receiver privacy is only one part of the broader problem.

How do stealth addresses work; a simple mental model

Imagine Bob publishes a mailbox design rather than a mailbox location. Anyone who wants to send him something can build a fresh mailbox from that design and leave the package there. To everyone else, each mailbox looks unrelated. But Bob carries a secret that lets him recognize which mailboxes are his and open them.

That analogy explains the useful part: public instructions produce private destinations. It fails in one important way, though: physical mailboxes can be copied in obvious ways, while cryptographic derivation depends on a hard mathematical problem. The reason strangers cannot link the one-time addresses back to Bob is not merely that they lack a trick; it is that they lack the secret needed to derive the hidden relationship.

Most practical stealth-address systems get this property from public-key cryptography, usually elliptic-curve Diffie-Hellman. The sender combines a fresh random secret with the recipient’s published public key to produce a shared secret. The recipient, using the matching private key and the sender’s published ephemeral public key, can compute the same shared secret from the other side. That shared secret is then turned into a tweak that creates a one-time destination key.

So the mechanism has an invariant: the sender and recipient arrive at the same hidden tweak, while everyone else sees only public keys that do not reveal that tweak. Once you see that, the rest of the scheme becomes bookkeeping and efficiency engineering.

How are one‑time stealth addresses derived (EC‑Diffie‑Hellman + tweak)?

A common two-key construction separates spending from viewing. This separation matters because recognizing an incoming payment and spending it are different powers.

The recipient starts with two private keys. The first is a spending key, which ultimately controls the funds. The second is a viewing key, which lets the recipient detect whether a payment belongs to them. The corresponding public keys are published together as a stealth meta-address. In Ethereum’s ERC-5564 language, a stealth meta-address is a set of one or two public keys that can be used to compute a stealth address for a recipient.

Now suppose Alice wants to pay Bob. She generates a fresh random ephemeral private key, which we can call p_ephemeral, and derives the corresponding ephemeral public key. She then combines p_ephemeral with Bob’s viewing public key to produce a shared secret s. Because of the Diffie-Hellman property, Bob can later reproduce the same s by combining his viewing private key with Alice’s published ephemeral public key.

The shared secret itself is not usually used directly. Instead, it is hashed into s_h, and that hash is converted into a curve point or scalar tweak. Alice adds that tweak to Bob’s spending public key to derive a one-time stealth public key. In ERC-5564’s secp256k1 reference scheme, the steps are: compute s = p_ephemeral * P_view, hash to s_h = h(s), compute S_h = s_h * G, then derive P_stealth = P_spend + S_h. The resulting account or address is derived from P_stealth.

Bob later scans announcements, reconstructs the same shared secret using his viewing private key and Alice’s ephemeral public key, hashes it into the same tweak, and adds that tweak to his private spending key. That gives him the stealth private key corresponding to the one-time destination. The important symmetry is this: Alice can derive the one-time public destination, and Bob can derive the matching private key, but Alice never learns Bob’s base spending secret.

Here is the mechanism in prose, as a concrete payment narrative. Bob publishes a stealth meta-address containing his spending public key and viewing public key. Alice looks it up, generates a fresh random ephemeral keypair, and uses Bob’s viewing public key to compute a shared secret only Bob can later reproduce. She hashes that secret and uses the result to “shift” Bob’s spending public key to a fresh one-time public key. She sends the assets to the address derived from that one-time key and includes her ephemeral public key in an announcement. Bob later sees the announcement, combines the ephemeral public key with his private viewing key, gets the same shared secret, derives the same shift, and applies it to his spending private key. That is why he (and only he) can spend from the one-time address.

What changes from payment to payment is the sender’s ephemeral randomness. What stays invariant is the recipient’s base key material and the algebraic relationship that lets the recipient recover control.

Why do stealth schemes use separate view and spend keys?

At first glance, having two keys instead of one may look like needless complexity. But the separation solves a real deployment problem.

A stealth-address wallet has to inspect incoming activity to figure out which payments belong to the user. If the only secret that can do that is also the secret that spends funds, then every scanner, mobile wallet, browser extension, server indexer, or accounting tool would need full spend authority. That is an unnecessary and dangerous coupling.

A viewing key lets software detect incoming payments without granting spending power. Monero popularized this distinction at the wallet level: users have a private view key, a private spend key, and a public address, and wallet software uses the view key to identify incoming outputs. The same conceptual split appears in Ethereum-oriented designs and in ERC-5564’s definitions.

This is also why “watch-only” behavior becomes possible in stealth-address systems. A service can scan the chain and report what has arrived, while the offline or hardware-controlled spending key remains separate. That said, watch-only setups are not universally perfect. Monero’s documentation notes practical limitations, including that a watch-only wallet cannot reliably track outgoing transactions in the same way. So the key split improves security and usability in one dimension, but does not eliminate operational complexity.

How do recipients discover incoming stealth payments (announcements and scanning)?

There is a catch hidden inside the magic. If every payment goes to a fresh one-time address, how does Bob know which on-chain addresses are his?

He has to scan.

This is the core operational cost of stealth addresses. The recipient, or software acting on their behalf, must inspect some stream of candidate payments and test whether each one corresponds to the recipient’s viewing key. On chains with native stealth support, that scan may happen over transaction outputs directly. On smart-contract platforms, there is often an announcement registry or event stream that recipients monitor.

Ethereum’s ERC-5564 standard makes this explicit. It specifies a singleton [ERC5564Announcer](https://eips.ethereum.org/EIPS/eip-5564) contract that emits Announcement events containing the scheme identifier, the stealth address, the caller, an ephemeral public key, and metadata. Wallets and parsers listen to that stream to discover possible incoming payments. The standard even fixes a canonical deployed announcer address via deterministic deployment so clients know where to listen.

This design reveals a deeper truth about stealth addresses: they replace public address reuse with private recipient-side matching. The privacy gain comes from moving the linking work from chain observers to the intended recipient.

That move is powerful, but it creates a resource asymmetry. Anyone can publish announcements; recipients bear the cost of checking them. This is why the ERC explicitly notes spam and denial-of-service concerns. Anti-spam measures such as tolls, staking, or parser-level filtering are not enforced by the standard; they are left to off-chain infrastructure and service policy.

What are view tags and how do they affect scanning speed and privacy?

Scanning every announcement naively can be expensive because elliptic-curve operations are not free, especially on constrained devices. That is where view tags come in.

A view tag is a short value, often one byte, derived from the shared secret. The sender includes it in the announcement metadata. When the recipient scans announcements, they first compute enough of the shared secret to check whether the tag matches. If it does not, they can skip the more expensive remaining work. In ERC-5564’s secp256k1 scheme, a 1-byte view tag lets recipients reject about 255/256 non-matching announcements early, and the standard says this reduces parsing time by around 6x.

This is a classic privacy-performance tradeoff. The tag leaks one byte of information about the shared secret. ERC-5564 states that this reduces the effective security margin from 128 bits to 124 bits in the reference design. For many practical settings, that is a good trade: a tiny amount of cryptographic leakage in exchange for a large usability improvement. But it is still a trade, not a free optimization.

This is a good example of what in stealth-address systems is fundamental and what is conventional. The fundamental part is the hidden shared-secret derivation that lets sender and recipient agree on a one-time key. The view tag is a convention layered on top to make scanning practical at scale.

How does ERC‑5564 standardize stealth addresses on Ethereum?

The underlying idea of stealth addresses is older and broader than any one chain. Bitcoin discussions, Monero’s production design, and multiple research variants all explore the same receiver-privacy pattern. What ERC-5564 adds is not the invention of stealth addresses, but a common Ethereum-facing interface and event model.

That matters because smart-contract ecosystems need coordination. If every wallet uses a different key format, different announcement event, and different derivation interface, then senders, wallets, registries, and parsers do not interoperate. ERC-5564 defines a schemeId mechanism so multiple stealth schemes can coexist, while standardizing a concrete secp256k1 scheme as schemeId = 1. It also specifies the required function interfaces, including generateStealthAddress, checkStealthAddress, and computeStealthKey, so implementations can align on semantics.

ERC-6538 complements this by standardizing a singleton on-chain registry for stealth meta-addresses. The registry stores and retrieves a user’s stealth meta-address and supports delegated registration using EIP-712 or EIP-1271 signatures. Mechanically, this solves the discovery problem: a sender can look up the recipient’s public stealth metadata without relying on ad hoc conventions.

But the registry introduces its own privacy tension. It improves interoperability by publishing a canonical mapping from some on-chain identity to a stealth meta-address. That is useful. It also creates a durable public association that consumers must think carefully about. The registry standard itself emphasizes interoperability, not a full analysis of the linkability implications of publishing that mapping.

What privacy guarantees do stealth addresses provide; and where do they fall short?

The strongest intuition to keep in mind is that stealth addresses hide recipient linkage, not necessarily everything else.

They do a very specific job well: they stop observers from seeing repeated payments to the same visible destination. In a system like Monero, this is part of why a user can publish one address while all incoming payments appear on-chain as unrelated one-time outputs. In Ethereum systems like Umbra or the ERC-5564 model, they let someone receive tokens or other assets at fresh addresses that are not obviously tied to their public identity.

But many things can still reveal the relationship later. If the recipient consolidates funds into a known public wallet, they may undo much of the privacy. If the recipient always withdraws through a distinctive route, timing and behavior may narrow the anonymity set. If observers already have a short list of likely recipients, the fact that a stealth address exists does not magically produce a large crowd to hide in.

This is not hypothetical. Research evaluating Umbra on Ethereum and several L2 networks reported that for a substantial share of payments, heuristics could identify the likely recipient, with measured deanonymization rates differing across networks. Those results depend on the authors’ heuristics, so they are not the same thing as a cryptographic break. But they show an important reality: cryptographic unlinkability at receipt time does not guarantee robust end-to-end anonymity in actual user behavior.

That distinction is easy to miss. A stealth-address scheme may be mathematically sound while the surrounding workflow leaks enough structure to make recipients guessable.

What operational challenges do stealth addresses create (fees, recovery, hygiene)?

The biggest non-cryptographic difficulty on account-based smart-contract chains is often fees. A stealth address that receives an NFT or obscure token may have no native gas token, so the recipient cannot easily move the asset. Any mechanism that tops up the address with gas can create visible links. More advanced solutions, including zero-knowledge-assisted routing or specialized relayers, can help, but they raise cost, trust, or implementation complexity.

Key management is another source of friction. A stealth-address system effectively creates many controlled destinations from a root secret structure. That is elegant until a user wants social recovery, key rotation, or clean migration across wallets and rollups. Rotating ordinary addresses is conceptually simple; rotating a stealth identity without creating new linkability or losing discoverability is harder.

And then there is simple user hygiene. Umbra’s own documentation is careful on this point: it is not a mixer and not a full shielding system. It gives receiver privacy under a narrower threat model. If users withdraw to known public addresses or reveal ownership through ENS, repeated operational patterns, or side channels, the theoretical anonymity set collapses quickly.

So when people ask whether stealth addresses “work,” the honest answer is: cryptographically, often yes; operationally, it depends on the whole payment lifecycle.

What implementation risks and audit findings should you watch for with stealth addresses?

Because stealth addresses rely on delicate cryptography, implementation details matter enormously. This is not a domain where “roughly right” is good enough.

The Least Authority audit of umbra-js is instructive here. It found that the implementation originally used only 128 bits of randomness in a way that translated to roughly 64 bits of security for stealth-address derivation, which was judged insufficient. It also found missing validation for uncompressed public keys, exposing invalid-curve attack risk, and noted dependency-level concerns around biased private key generation. These are not philosophical caveats; they are examples of how privacy and security claims depend on correct point validation, sound randomness, and careful dependency hygiene.

There is also a broader software-environment issue. The same audit notes that JavaScript environments are poor places to promise ideal secret handling: memory is hard to control, swapping may expose secrets, and constant-time behavior is limited. Stealth addresses may be conceptually elegant, but if the client leaks key material or uses compromised dependencies, the whole privacy model can fail.

That lesson is broader than Ethereum. Any chain-specific implementation inherits the ordinary risks of wallet software, SDKs, and supply chains. Privacy mechanisms do not float above software reality.

How do stealth addresses work across different blockchains (Monero, Ethereum, others)?

Stealth addresses are not tied to one blockchain architecture. The core requirement is a public-key mechanism strong enough to let sender and recipient derive a shared secret non-interactively.

Monero is the clearest production example of the concept embedded deeply into a chain’s transaction model: senders generate one-time addresses for recipients, recipients use view and spend keys, and wallet software handles the complexity behind the scenes. Ethereum-oriented systems such as Umbra and ERC-5564 adapt the idea to account-based smart-contract environments by introducing registries and announcement events.

Other privacy systems solve adjacent problems differently. Secret Network’s SNIP-20 model, for example, uses private smart-contract state and viewing keys rather than the same one-time-address pattern described here. That contrast is helpful because it shows what is essential to stealth addresses and what is not. The essential piece is per-payment derivation of unique recipient destinations from public metadata plus private recovery. If a system instead hides balances and counterparties through encrypted contract state, it may deliver receiver privacy without literally using stealth addresses.

So stealth addresses are best understood as one member of a larger family of privacy designs, particularly suited to the problem of receiving without visible address reuse.

Conclusion

A stealth address is best thought of as a public recipe for private one-time destinations. The recipient publishes metadata, not a reusable receiving address. Each sender combines that metadata with fresh randomness to derive a new destination that only the recipient can recognize and spend from.

That solves a narrow but important problem: on a public ledger, it prevents your incoming payments from all landing on one obvious, linkable address. The cost is that someone has to scan for those payments, infrastructure has to announce them, and users must avoid undoing the privacy later through consolidation, withdrawals, or poor operational habits.

So the memorable version is this: stealth addresses do not make a payment invisible; they make the recipient relationship non-obvious. When implemented carefully and used well, that is a meaningful privacy gain. When the surrounding workflow leaks, the cryptography alone is not enough.

What should you understand before using stealth addresses?

Understand what stealth addresses actually protect and where they leave gaps, then use Cube Exchange’s normal deposit and transfer flows to validate the end‑to‑end behavior before moving large value. Run a small, instrumented transfer on Cube: fund your account with the native gas token you’ll need, initiate the stealth transfer or announcement, and confirm the recipient can detect and spend the one‑time address.

1. Check discovery method: look up the recipient’s published stealth meta‑address or registry entry (ERC‑6538) and confirm whether an announcer/announcement or on‑chain registry lookup is required and which schemeId they use.
2. Confirm gas and movability: verify whether the one‑time address will have native gas to move received tokens; if not, plan a small gas top‑up or coordinate a relayer and ensure you deposit the native token on Cube to cover that top‑up.
3. Perform a small test transfer via Cube: send a low‑value payment to the recipient’s stealth meta‑address (including the ephemeral announcement), then confirm the recipient detected the announcement, derived the one‑time key, and successfully spent or moved the test funds.
4. Agree post‑receipt hygiene: coordinate a consolidation and withdrawal policy with the recipient (avoid immediate consolidation to known public wallets), and if you are the recipient, securely back up view and spending keys so you can recover stealth‑derived addresses.