A Technical Guide to Stealth Addresses and On-Chain Privacy | HackerNoon

Abstract

This article examines the state of on-chain privacy, focusing on the mechanics and adoption of Stealth Addresses. We analyze the technical foundations of ERC-5564 and ERC-6538, and provide a comparative deep dive into the ecosystem’s leading solutions: Umbra, Fluidkey, and Railgun. We explore how these protocols solve the “Glass Bank Account” problem through different architectural approaches, from simple P2P payments to complex private DeFi interaction.

Introduction

A notable pain point for modern Web3 users is the lack of privacy. The architecture of blockchain is such that every transaction is recorded on a public ledger, moreover these transactions are often tied to a single, legible ENS name. This is known as the “Glass Bank Account” effect: once your profile is linked to an address, your entire financial history i.e. from your net worth to your mere subscriptions, all become an open book on-chain.

“Transparency”, which is often considered as a feature of blockchain, has become an unavoidable bug for users. We currently lack the basic financial privacy we take for granted in the traditional banking system. That’s why Vitalik Buterin identified Privacy as one of the “Three Major Transitions” in his article alongside L2 scaling and wallet security.

Until recently, our options for privacy were limited and often “high-risk.” Solutions like Tornado Cash offered powerful anonymity but came with a heavy cost:

1. Compliance Risk: Users rightfully fear their addresses being blacklisted by centralized exchanges or “tainted” by association.
2. UX Friction: The process of “shielding” and “unshielding” funds is cumbersome and tailored only to highly technical “power users.”

Stealth addresses represent a paradigm shift. They offer the privacy of a private bank account with a user experience that is intuitive and, crucially, architected to remain compliant with global AML (Anti-Money Laundering) regulations.

User Demand: Beyond the Cypherpunks

The appetite for this transition is backed by more than just theory. While comprehensive data on Web3 privacy is still emerging, recent research shows a clear and growing demand:

• The Privacy Mandate: A 2022 study by Simin Ghesmati et al., “User-perceived privacy in blockchain,” revealed that 50% of participants considered transaction privacy “very important,” citing concerns over government surveillance and the “guard” transparency created against mass adoption.
• A Core Feature: Comprehensive research published in Frontiers (surveying over 3,700 users) found that 25% of respondents view privacy as the single most important feature of blockchain technology.
• The Trust Gap: Outside the crypto bubble, a 2023 Consensys global survey of 15,000 people found that 83% prioritize data privacy, yet only 45% trust current internet services with their data.

As we move toward a future of “Privacy by Default,” we must move past the era of the “Glass Bank Account.” To do that, we need to understand the mechanism that breaks the link without breaking the chain: The Stealth Address.

Past works in blockchain privacy

Over the years, many protocols came and made their contribution in the privacy ecosystem of blockchain. Some of them revolutionised the privacy scene, famously or infamously.

The notable ones are explained below:

Monero: Privacy through Cryptography

Monero (XMR) launched in 2014, is one of the most significant privacy focused crypto projects. Monero’s blockchain provides privacy by default. Monero uses revolutionary technologies like

> Ring Signatures and RingCTs

Stealth Addresses

Bulletproofs (zero knowledge proofs)

> Dandelion++

In fact, Monero had such strong privacy that bounties were put on if someone could break Monero coins privacy. So, did it succeed as a coin? Same happened with Monero which happened to models before it, their top notch privacy dragged them down. Regulators could not verify red flags, criminals, money launders. The U.S. government banned it immediately, along with Japan and the Australian government.

Despite its robust technology, Monero struggled with the ‘Privacy Paradox’: its perfect privacy made it a target for regulators, leading to delistings that stifled its liquidity.

Zcash: Shielding via ZK Proofs

Zcash (ZEC) was an academic project (zerocash protocol) that was launched in 2016. It was another game-changing project in crypto privacy. It brings a cutting-edge zero-knowledge proof into a cryptocurrency, termed as zk-SNARKs — zero knowledge Succinct Non-Interactive ARguments of Knowledge, which allows transactions to be fully encrypted on a public chain, while still being verified. In this type of transaction, every detail of a transaction is hidden on-chain; only a cryptographic proof is generated to show that everything is valid/legal (nothing fishy happened).

Zcash uses a dual address design: n > t-address: normal bitcoin style address

z-address: shielded address using zk-SNARKs

However, in the early days of Zcash, the zk-SNARKs transactions took time and computational power, which many users didn’t find adaptable. As a result, most of the transactions remain transparent. This means that the anonymity set for the Zcash users remains small, limiting the privacy effectiveness.

However, the Zcash team worked to improve the technology over time. They optimised zk-SNARK performance to a level that the proof can be generated on a smartphone, even minimising the transaction time and memory by a huge magnitude. In 2020–21, Zcash introduced Halo2, which was a major upgrade from the last time as it introduced a trustless setup to generate public parameters.

So was Zcash successful? Well, yes and no.

Zcash had its own problems, for example, unlike Monero, privacy was not imposed by default, so people never really bothered with it. It was treated as an altcoin (mostly used as transparent). Under AML laws, the South Korean government along with other governments banned ZEC coins.

Tornado Cash: A Decentralized Mixer

Emerging in 2019 as a significant evolution in blockchain privacy, Tornado Cash moved beyond standalone privacy coins to offer a decentralized mixing solution directly on Ethereum. Operating as a non-custodial smart contract, it utilized Zero-Knowledge Proofs (zk-SNARKs) to break the on-chain link between deposits and withdrawals. Users would deposit funds into standardized pools (e.g., 1 ETH or 10 ETH) and receive a “secret note,” which they later used to generate a cryptographic proof authorizing a withdrawal to a fresh address. Because the contract mixed hundreds of deposits together without a central operator, it effectively severed the transaction graph, allowing users to obscure their financial history from stalkers or public observers.

At its peak, the protocol processed approximately $16 billion in volume, serving both legitimate users seeking privacy and malicious actors exploiting its anonymity. While many used it for benign purposes like protecting personal wealth visibility, Tornado Cash became notorious as a laundering tool for high-profile cybercrimes, most notably the $620 million Ronin bridge hack by North Korea’s Lazarus Group. Analytics suggested that nearly 30% of all funds deposited were linked to illicit sources — a figure far higher than other chains like Bitcoin — which inevitably drew intense scrutiny from regulators who viewed the protocol as a haven for money laundering.

The situation reached a breaking point in August 2022 when the U.S. Treasury’s OFAC took the unprecedented step of sanctioning the smart contract addresses themselves, effectively outlawing interaction with the code for U.S. persons. This marked a historic shift where decentralized software, rather than just individuals, was targeted. The fallout was immediate: infrastructure providers blocked access, stablecoin issuers like Circle froze assets within the contracts, and a core developer was arrested in the Netherlands. Although Tornado Cash successfully demonstrated that strong, non-custodial privacy is technically possible, its collapse underscored a harsh reality: privacy tools that cannot separate legitimate users from criminals will likely face existential legal threats.

If you want to know more about the history of privacy in crypto, you should check out Sandy Peng’s fantastic resource, “The Privacy Layer”.

What is a Stealth Address?

Let’s start with a thought experiment, imagine your PO box, if someone sends a mail, it is open to the public by default. Now, imagine a “one-time-use PO box”. You give me a permanent code and I send you mail every time to a temporary PO box that only you can open. To an observer it looks like mail is sent to a random address but you have the key to open it.

Formally, stealth address is the temporary PO box that only you can open.

Creation of Stealth Address:

Users sign a message with their EOA (Externally owned account) via Metamask or other wallet extensions.

This signature creates a Stealth Meta Address which is essentially a concatenation of “Spending Public Key”(K) and “Viewing Public Key”(V) which uses EIP-3770 chain specific address format, with the addition of “st:” prefix. Following is an example:

st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464b02c0521

b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

Using EIP-5564 standard, two private keys, “Spending Private Key”(k) and “Viewing Private Key”(v) are generated, later Spending Public Key is derived from Spending Private Key. Spending Public Key is used for cryptography purposes while private one secures the account.

Private Key Node (BIP-32 compliant) is extracted from Viewing Private Key which is later used to derive something called “Ephemeral Private Key”(r), which is unique for each transaction and chainId.

This Ephemeral Private Key is derived by sender using a randomly generated number (nonce).

Sender calculates the shared secret:

S = r * V

Ephemeral key is then used to derive the stealth address (P) and stealth private key (p), assuming G as a commonly agreed generator point for elliptic curve.

P = K + G * hash(S)

p = k + hash(S)

This is the most common methodology to create stealth addresses. For detailed cryptography, you can check out An Incomplete Guide To Stealth Addresses by Vitalik Buterin or the Umbra protocol.

Working of Stealth addresses:

Remember that all of this process happens entirely non-interactively, meaning that there is no direct link between sender and receiver whatsoever. Any third party observing can not create a link between the sender and the receiver.

However, to make it work in the first place, the recipient should be able to make their stealth meta address known to the sender. One way to do this is using EIP-6538: Stealth Meta-Address Registry, this uses a single central contract which registers the stealth meta-address and links it to the ENS-registered username, this helps senders to resolve the stealth address using only ENS names.

This scheme breaks the link between the sender and the recipient, affording them both privacy from the entire world knowing their business.

I hope this diagram makes the creation and workflow clearer:

Press enter or click to view the image in full size.

Stealth Address Ecosystem

While the cryptography behind stealth addresses is powerful, it is useless without good user experience (UX). Several protocols are currently racing to solve the “usability gap.”

Currently, in the crypto ecosystem, there are three major identified projects which are pushing this technology forward:

Umbra

Fluidkey

Railgun

While Umbra and Fluidkey are based on Ethereum Standards of ERC-5564 and ERC-6538, Railgun is based on zerocash protocol.

At a fundamental functional level, the difference lies in whether the protocol is designed for simple payments, daily wallet management, or complex interactions. Umbra serves as the foundational payment rail, functioning primarily as a “digital cash” system where every transaction generates a fresh, disconnected address (EOA) that the receiver must manually manage; it is built for occasional, direct P2P transfers like payroll or grants where simplicity is key. Fluidkey takes this same underlying stealth technology but wraps it in a “UX layer” using Account Abstraction and ENS, effectively aggregating those scattered addresses into a single, unified interface. This transforms stealth addresses from a cumbersome utility into a daily-driver wallet experience where privacy happens automatically in the background.

While Umbra and Fluidkey focus on transfer privacy, Railgun address the complexities of compliance and active usage. Railgun differentiates itself by enabling private action, not just private holding; it uses a UTXO model to allow users to interact directly with public DeFi applications (like swapping on Uniswap or lending on Aave) without ever exposing their original wallet, effectively acting as a private tunnel to the public blockchain economy.

Let’s look a little deeper into the protocols.

ENS and “The Offchain-Resolver”: The Ethereum Name Service (ENS) is crucial for adoption, but it paradoxically hurts privacy,alice.eth usually resolves to a single static address. However, new developments (highlighted in recent Devcon’26 presentations) utilize EIP-3668: CCIP Read — Secure off-chain data retrieval to create “Private ENS” subdomains. Instead of resolving to a fixed address, a resolver like Fluidkey’s can programmatically generate a new unique stealth address every time someone queries alice.fkey.eth. The sender thinks they are sending a name, but the protocol handles the stealth derivation in the background.

The Standard Setter: Umbra

While the mathematical foundation of stealth addresses provides the capability for privacy, Umbra is the protocol that operationalizes it into a usable application. It is effectively an implementation of EIP-5564 and EIP-6538 built by ScopeLift.

Unlike other protocols that might focus on complex compliance or DeFi pooling, Umbra focuses on the most fundamental primitive of finance: Simple Payments.

The Setup:

The user journey begins with a “Setup” phase. When a user logs into the Umbra app, they sign a message using their standard wallet (like MetaMask).

From this signature, the protocol derives two specific keys: a Spending Key and a Viewing Key. This dual key architecture is crucial because it separates the ability to see funds from the ability to move them.

The user then registers their “Stealth Meta-Address” on-chain, linking it to their public ENS name or main address. This on-chain registry is a key architectural difference compared to newer protocols like Fluidkey, which use off-chain resolvers.

The Relayer Architecture:

One of the most critical engineering challenges Umbra solves is the “Gas Problem.”

If Alice sends 100 USDC to Bob’s stealth address, that address has 0 ETH. If Bob funds it with ETH from his main wallet to pay for the withdrawal gas, he links the two addresses, destroying his privacy.

When sending ETH, funds go directly to the stealth address. Since the asset itself is gas, the receiver can easily move it.

When sending ERC-20 tokens, they are not sent directly to the stealth address. Instead, they are held by the Umbra smart contract.

To withdraw these tokens without identifying themselves, Umbra uses a Relayer Network.

1. The recipient generates a signature authorizing the withdrawal.
2. This signature is passed to a Relayer via the withdrawTokenOnBehalf() function.
3. The Relayer submits the transaction to the blockchain and pays the gas fees.
4. In exchange, the Relayer deducts a small fee from the tokens being withdrawn.

This system allows users to withdraw funds to a completely fresh address without ever needing to hold ETH in the stealth account initially.

Scanning:

Finding a stealth payment requires scanning every Announcement event on the blockchain to see if it belongs to you. Umbra optimizes this process to make it viable for browser-based apps.

> Through clever caching, Umbra reduces the scan time to approximately 10–15 seconds for a weekly check.

> Upcoming versions will implement “View Tags”, truncated hashes that allow the scanner to quickly ignore irrelevant transactions.

> Because Umbra uses a separate Viewing Private Key, users can safely provide this key to a third-party service. This service can monitor the chain 24/7 and notify the user of incoming funds without having the cryptographic power to steal them (which requires the Spending Key).

Post-Withdrawal Hooks:

Umbra is not just for payments; it supports programmable privacy through Hooks. The protocol exposes methods like withdrawTokenAndCall(), which allows a user to withdraw funds and immediately execute an action on another contract in the same transaction.

Use Cases: A user could receive stablecoins and use a hook to atomically swap them for ETH, or withdraw funds directly into a DeFi protocol.

Mechanism: Developers can write contracts implementing the IUmbraHookReceiver interface to create custom behaviors that trigger instantly upon withdrawal.

Deployment and Spam Prevention:

Umbra’s architecture is designed to be permissionless and censorship-resistant.

Canonical Addresses: The contracts are deployed using create2, ensuring the Umbra contract address is identical across all supported networks (Mainnet, Optimism, Polygon, Arbitrum, etc.).

Spam Deterrence: On cheap networks (like Polygon or Gnosis), the contract charges a small “toll” fee. This disincentivizes attackers from flooding the network with spam transactions, which would otherwise bloat the scanning time for legitimate users.

Future Outlook: Umbra v2:

ScopeLift is currently developing Umbra v2, moving toward a modular architecture. This update aims to support a wider range of standards beyond simple ERC-20s, including ERC-1155, ERC-7621, and ERC-4337 Paymasters, effectively expanding the protocol from a payment tool into a generalized privacy layer.

Press enter or click to view image in full size

Umbra V2 Architecture

The UX Layer: Fluidkey

While Umbra optimizes for a “Digital Cash” model (simple, direct payments), Fluidkey architects privacy as a “Daily Driver” experience. It abstracts the complexity of managing dozens of stealth addresses into a single, unified interface, effectively acting as a privacy layer for your entire financial life.

It is an implementation of ERC-5564 but relies heavily on Account Abstraction (Gnosis Safe) and ENS Off-chain Resolvers to solve the UX friction.

The Setup:

The user journey begins similarly to Umbra, signing a key generation message with their wallet to derive keys but the architectural trust model is fundamentally different.

The user derives a Spending Private Key (kept locally) and a Viewing Private Key.

In Fluidkey, the user shares a specific BIP-32 Node of their Viewing Private Key (specifically m/5564’ /0’ ) with the Fluidkey server.

Due to this the user never has to “scan” the blockchain manually. The server monitors the chain 24/7, delivers instant notifications, and crucially can generate new addresses on the fly for senders without the user needing to be online.

Fluidkey (the company) has visibility into your incoming balances and transaction history. However, because they do not have the Spending Key, the system remains fully self-custodial, they cannot move your funds.

Press enter or click to view image in full size

Fluidkey ensures new funds received are not linked to your existing assets and onchain history

Architecture:

Unlike Umbra, which typically interacts with standard EOAs (Externally Owned Accounts), Fluidkey deploys a Gnosis Safe (Smart Account) for every single stealth address.

“Counterfactual Instantiation”: When you receive funds, the Safe contract does not actually exist on-chain yet. It is “counterfactually” predicted using the predictStealthSafeAddressWithClient function. The contract is only deployed the moment you decide to spend the funds.

Because every address is a Smart Account, Fluidkey enables Gas Sponsorship natively.

If you receive USDC, you don’t need ETH to move it.

A Relayer deploys the Safe and executes your transaction, taking a small fee from the token balance itself (e.g., USDC, DAI, USDT). This completely removes the risk of funding the wallet from a public source, which is a primary deanonymization vector

.

The ENS Off-chain Resolver:

Fluidkey’s “killer feature” is the ability to use a static name (like alice.fkey.eth) while receiving funds to dynamic private addresses. It achieves this using ERC-3668 (CCIP Read).

> A sender (using any standard wallet) enters username.fkey.eth or username.fkey.id .

The wallet queries the ENS registry, which redirects to Fluidkey’s Off-chain Resolver.

Fluidkey’s server (using the shared Viewing Key node) mathematically derives a fresh, unused stealth address for the recipient.

The server returns this specific address to the sender’s wallet.

The Result: The sender thinks they are sending to a static name, but the blockchain records a transfer to a unique hex address. The link between the name and the address exists only during that split-second query and is never permanently recorded on-chain.

Zero-Registry: Unlike Umbra, which requires an on-chain registry, Fluidkey’s resolver approach means there is no central contract mapping users to keys on-chain.

Address Abstraction and Management:

Managing 50 different stealth addresses is a nightmare for users. Fluidkey’s UI abstracts this away entirely.

> The interface aggregates all your Safes into one “Total Balance.” When you send funds, an algorithm automatically selects which stealth accounts (UTXO-style) to spend from to minimize gas and fragmentation.

> Users can tag specific addresses with “Labels.” This allows granular control — for example, ensuring that funds received from “Work” are never combined in a transaction with funds received from “DeFi,” preventing accidental on-chain linking.

Advanced Privacy: Hiding the Trail:

A major risk in privacy is sending funds out (e.g., to a centralized exchange), which can retroactively link the stealth address to your identity. Fluidkey integrates Houdini Swap to solve this.

> The “Hide Trail” feature routes outgoing funds through two exchanges to break the on-chain link. It allows users to exit the privacy ecosystem (e.g., sending to a fresh public wallet) without leaving a trace that connects back to their stealth address.

> Through “Near Intents,” users can also receive funds from non-EVM chains (Bitcoin, Solana, Tron, etc.). These transfers are automatically converted and deposited as USDC on Base into a fresh stealth address.

Press enter or click to view image in full size

Resilience and Recovery:

Fluidkey operates out of Switzerland, leveraging strong local data protection laws. However, to ensure the system is trustless, they provide robust recovery tools.

SARA: This is a dedicated, open-source recovery interface hosted separately.

Because the stealth derivation is pseudo-random based on standard cryptography, users can independently replay the derivation sequence to recover their addresses and funds even if Fluidkey (the company) disappears entirely. The core cryptographic functions are released as the open-source Stealth Account Kit.

> here is an excellent resource to know about the functioning of Fluidkey.

The DeFi Layer: Railgun

If Fluidkey is your “Private Bank Account,” Railgun is your “Private Trading Desk.”

While other protocols focus on simply hiding transfers between Alice and Bob, Railgun allows users to interact with any smart contract (DEXs, Lending Protocols, Yield Farms) while keeping their identity, balance, and strategy completely invisible.

It is not a separate blockchain (like Monero) but a set of smart contracts deployed directly on Ethereum, Arbitrum, BSC, and Polygon.

Architecture:

Unlike Umbra and Fluidkey, which generate standard Ethereum addresses (EOAs), Railgun effectively builds a private blockchain inside a smart contract.

Stealth meta-addresses in Railgun use the prefix of “0zk”, and like EIP-5564, is a concatenation of the public viewing key and public spending key. Railgun however uses Ed25519 keys on the BabyJubJub curve instead of ECDSA & secp256k1. In the same manner as EIP-5564, users scan over all emitted events from the Railgun contracts and use their viewing key to determine which events represent transfers to their wallet.

> Railgun abandons Ethereum’s “Account Model” for a UTXO (Unspent Transaction Output) model, similar to Zcash or Bitcoin.

When you deposit (shield) 100 USDC, the contract adds a generic “note” (UTXO) to its Merkle Tree.

Your wallet holds the private key to “unlock” and spend that specific note.

To the outside world, the Railgun contract just holds a massive pool of USDC, but no one knows which user owns which fraction of it.

Press enter or click to view image in full size

Private DeFi (Adaptors):

The primary innovation of Railgun is the ability to use public dApps anonymously. This is achieved through Relayers and Adaptors.

> The Intent: Alice wants to swap her shielded USDC for ETH on Uniswap.

> The Proof: She generates a Zero Knowledge Proof (zk-SNARK) locally, proving she owns the USDC and authorizing the swap.

> The Relayer: She sends this proof to a Relayer. The Relayer takes the shielded USDC, exits the privacy pool temporarily to execute the swap on Uniswap public contracts, and immediately shields the received ETH back into Alice’s private balance.

The Result: On-chain, it looks like the Railgun Contract performed a swap. Alice’s address never appears. She gets the ETH without ever exposing her identity to Uniswap.

Private Proofs of Innocence (PPOI):

Railgun solves the “Tornado Cash Problem” (where privacy tools get banned because hackers use them) using a breakthrough feature called Private Proofs of Innocence (PPOI).

PPOI allows a user to cryptographically prove that their funds are NOT from a known bad actor (e.g., the Lazarus Group or a sanctioned wallet) without revealing who they ARE.

A decentralized list of “bad actors” is maintained (based on public hacks/sanctions).

When Alice transacts, her wallet generates a ZK-proof showing: “My UTXO is part of the Railgun Merkle Tree, AND it is NOT in the set of ‘bad’ UTXOs”.

This allows compliance-heavy entities (like exchanges or institutional desks) to accept Railgun funds, knowing they are clean, without needing to KYC the sender.

Press enter or click to view image in full size

Gas Abstraction(The Relayer Network):

Railgun handles the “Gas Problem” differently than Umbra.

• Pay in Tokens: Because the Railgun contract holds the user’s funds, the protocol allows users to pay relayers directly in the token they are transacting.
• Mechanism: If Alice is swapping USDC, she signs a transaction that says, “Use 5 USDC from this swap to pay the Relayer for their gas.” The Relayer pays the ETH gas fee and keeps the 5 USDC profit. Alice never needs to hold ETH in her private wallet.

Trade-offs:

> Generating ZK-proofs and using Relayers is computationally heavy. Railgun transactions cost significantly more gas than standard transfers (often 3–4x more), making it expensive on Ethereum Mainnet but very efficient on L2s like Arbitrum or Polygon.

> The UTXO model is harder for developers to build on compared to the EOA model of Fluidkey, though SDKs are mitigating this.

Challenges and Trade-offs:

The single most immediate hurdle for stealth addresses is the “Gas Problem.” If Alice sends 100 USDC to Bob’s stealth address, that address holds no ETH. To move those funds, Bob needs ETH to pay for gas.

• If Bob sends ETH from his main public wallet to the stealth address to pay for gas, he instantaneously deanonymizes himself, publicly linking the two addresses on-chain.
• Protocols utilize EIP-4337: Account Abstraction Paymasters. This allows Bob to pay for gas using the USDC he just received. The Paymaster takes a small cut of the USDC and submits the transaction on Bob’s behalf.
• This solution works well for fungible tokens (ERC-20), but it breaks down for NFTs. Since an NFT is unique and illiquid, a Paymaster cannot accept a “fraction” of an NFT as payment for gas. Consequently, receiving an NFT privately often leaves it “stranded” unless the user risks funding the wallet externally or uses a more complex relay service.

It is a common misconception that stealth addresses “erase” transaction history like a mixer.

• In ERC-5564 implementations (unlike Railgun), the chain of transfers remains perfectly visible on the public ledger. An observer can see Address A sent funds to Address B. They just don’t know that Address B belongs to you.
• This creates a dangerous pitfall. If a user receives five different payments to five different stealth addresses and then sends them all to a single centralized exchange (or a main wallet), they have retroactively linked all those payments together.
• To maintain optimal privacy, users must avoid consolidating funds. They are forced to manage a fragmented portfolio, leaving funds in the specific stealth addresses where they arrived until they are spent. This creates significant mental and UI overhead, as a $100 purchase might need to be sourced from three separate stealth wallets.

For a user to know they have received money, their wallet must attempt to decrypt every single “Announcement” event on the blockchain to see if it matches their key.

• Checking every transaction is computationally expensive (O(n) complexity). In a high-throughput mobile environment, this can drain battery and lag the UI.
• To mitigate this, the standard introduces a View Tag — a truncated hash of the shared secret. This acts as a quick filter, allowing wallets to instantly discard 99% of transactions that aren’t relevant to them without running the full decryption logic.
• While View Tags help day to day, wallet restoration remains painful. If a user imports their seed phrase to a new device, the wallet must scan the entire history of the blockchain since the stealth contract was deployed to find old balances.

To solve the scanning issue, protocols like Fluidkey offer a pragmatic tradeoff: outsourcing the work.

• Users can share their Viewing Private Key (but not their Spending Key) with a centralized server. This server scans the chain 24/7 and sends a push notification when funds arrive.
• This requires trust. While the server cannot steal your funds, it can see everything you receive. The user is effectively trading absolute privacy for the convenience of instant notifications and mobile usability.

> Modern security relies on Guardians (e.g., “If I lose my key, 3 friends can help me recover it”). This is difficult to implement with stealth addresses because the user doesn’t just have one account — they have a tree of derived keys. recovering the “Root” doesn’t automatically recover the history of every ephemeral address without complex state tracking.

> ERC-5564 is optimized for transfers. Trying to use a stealth address to interact with a complex dApp (like voting in a DAO or staking) requires significant custom engineering. Since the stealth address has no history or reputation, it often cannot participate in systems that require proof of past activity.

Conclusion

We are witnessing a fundamental maturation in how value moves on-chain. We began with a system where transparency was absolute, and privacy was non-existent. We then moved through the era of “Privacy by Obfuscation” with tools like Tornado Cash, which proved the demand for anonymity but failed the test of regulatory durability.

Today, we are entering the era of Privacy by Architecture. As explored through the mechanisms of Umbra, Fluidkey, and Railgun, Stealth Addresses offer a path forward that protects user dignity without breaking the chain’s integrity. They allow the ledger to remain public while keeping the participants private.

While Stealth Addresses solve the “linkability” problem, the infrastructure layer is evolving to support even deeper, programmable privacy. Several emerging technologies are poised to redefine the landscape:

• EIP-7503: Zero-Knowledge Wormholes **introduces a native privacy primitive to Ethereum. It allows users to “burn” ETH on one side of the chain and cryptographically prove they burned it to “mint” clean ETH on a fresh address. This offers plausible deniability to an observer, it simply looks like a user burned funds, effectively severing the transaction graph at the protocol level.
• Aztec Network is privacy-first L2 that goes beyond simple transfers to enable private smart contracts. Aztec uses a UTXO-style model and a custom language called Noir to allow fully private, programmable transactions. However, this comes with a tradeoff, it lacks native EVM compatibility, requiring developers to rewrite dApps specifically for its private environment.
• Scroll’s Cloak A new framework designed for “auditable privacy”. Unlike systems that aim for total opacity, Cloak uses a permissioned sequencer and Zero Knowledge proofs to hide transaction data from the public while ensuring it remains verifiable. It introduces Selective Disclosure, allowing institutions or users to reveal transaction details to auditors (for compliance) without exposing them to the world.
• Payy is a recent project which represents the shift toward “onchain consumer banking” via a vertically integrated stack combining stablecoins, fiat ramps, and payment cards on a custom L2. Unlike standard EVM chains, Payy uses handwritten ZK circuits to shield all transaction details. Its most distinct feature is its approach to compliance: while services like cards require KYC, this identity data is cryptographically unlinked from onchain activity. This ensures that even if the provider verifies a user’s identity, the network’s public records cannot associate that identity with the user’s anonymous on-chain account.

Ultimately, the technology is only as good as its interface. Vitalik Buterin has argued that privacy cannot remain a niche feature for “power users”, it must become the default setting for the average person.

Users should not need to manage seven different wallets for different levels of privacy. The future is a single “Daily Driver” wallet where a user sees a “Private Balance” and a “Private Send” button alongside their normal funds.

Real adoption will arrive when privacy is invisible. It will happen when a freelancer can receive a salary in USDC, a company can pay a vendor, and a user can buy coffee, all without broadcasting their net worth to the network. As we transition from the “Glass Bank Account” to the Invisible Ledger, privacy will no longer be viewed as a tool for secrecy, but as a prerequisite for freedom.

Overall, I am pretty biased to Stealth Address systems in Privacy. A massive shoutout to all the teams who have worked and researched on stealth addresses. I think we are heading in the right direction, and the progress we have made is pretty impressive.

I hope many other privacy frameworks that are under development come out for good and elevate the privacy experience in Ethereum and overall blockchain.