Stealth Address

The core function of a stealth address is to prevent on-chain linkability. For every payment, the sender generates a unique, one-time public address derived from the recipient's public stealth meta-address. This means multiple payments to the same recipient appear as unrelated transactions to different addresses on the blockchain, obscuring the recipient's total balance and transaction graph.

Stealth addresses rely on a dual-key system derived from Elliptic Curve Cryptography (typically secp256k1). A recipient has:

• A spend private key to authorize spending from generated addresses.
• A view private key to scan the blockchain for incoming payments. The sender uses the recipient's public stealth meta-address (containing two public keys) to perform the one-time address generation, ensuring only the intended recipient can find and spend the funds.

To receive a stealth payment, a user must first publish or share their stealth meta-address. This is a static identifier, often encoded as a single string (e.g., starting with 0x00 in some implementations), which contains the two public keys needed for the dual-key system. Unlike a regular address, the meta-address itself never receives funds; it is only used as the input to generate the unique, one-time destination addresses.

A critical component is the stealth meta-address announcement. For the recipient to discover their funds, the sender must publish a small piece of cryptographic data (an ephemeral public key or stealth address metadata) to the blockchain. The recipient's wallet scans these announcements using their view key to compute which one-time addresses belong to them. Without this public announcement, the recipient cannot find the transaction.

Implementation can occur at different layers:

• Protocol-Level: Built directly into a blockchain's consensus rules (e.g., Monero's use of one-time addresses). All transactions are private by default.
• Application-Level: Implemented via smart contracts or SDKs on transparent chains like Ethereum (e.g., ERC-5564). Privacy is an opt-in feature for users. This distinction affects adoption, gas costs, and the privacy set (the group of users whose transactions are mixed).

Stealth addresses are often one component of a larger privacy stack. They are highly complementary to:

• Confidential Transactions: Hides the transaction amount.
• ZK-SNARKs / ZK-STARKs: Can prove the correctness of a stealth address operation without revealing links.
• Mixing / CoinJoin: Breaks linkability between transactions, while stealth addresses break linkability to the recipient. Used together, they provide strong, multi-layered privacy.

The Cardano ecosystem is exploring stealth address standards through Cardano Improvement Proposals (CIPs). Proposed designs leverage the chain's extended UTXO (eUTXO) model and native asset support.

• Focus on single-use addresses derived from a master public key and a nonce.
• Aims for light-client compatibility, allowing wallets to scan for incoming transactions efficiently.
• Discussions center on integrating with Hydra for scalability and off-chain announcement layers.

The view key is a critical security component that allows a recipient to scan for incoming payments. Its compromise reveals all past and future transactions associated with the stealth address. Unlike a traditional private key, which secures funds, the view key's sole purpose is to break privacy, creating a unique attack vector. Custody models are complex, as the view key must be accessible to wallet software for scanning but kept secure from adversaries.

Stealth addresses protect on-chain linkability but do not conceal transaction metadata. Observers can still analyze:

• Timing: When a stealth transaction is broadcast.
• Amount: The value being transferred.
• Network-Level Data: IP addresses during broadcast (unless using a mixer or VPN).
• Ephemeral Key Reuse: If a sender accidentally reuses an ephemeral private key, it can link multiple stealth addresses back to the original sender's public key.

Recipients must constantly scan the blockchain to discover funds sent to their stealth addresses, which requires significant computational resources. This creates practical limitations:

• Resource Intensity: Light clients or mobile wallets may struggle with the scanning load.
• Delayed Discovery: Funds are not instantly visible; discovery depends on scan frequency.
• Centralization Pressure: To avoid local scanning, users may rely on third-party indexer services, which could become privacy bottlenecks and points of failure.

Stealth addresses are not natively supported by most blockchain protocols or smart contract platforms, leading to fragmentation and integration challenges.

• Smart Contract Limitations: Most EVM-based contracts cannot send to or interact with stealth addresses directly.
• Wallet & Exchange Support: Broad adoption requires integration by custodians, exchanges, and wallet providers, which has been slow.
• Fragmented Standards: Multiple implementations (e.g., Monero, Zcash Sapling, ERC-5564) exist, creating compatibility issues across ecosystems.

Most stealth address schemes rely on standard elliptic curve cryptography (e.g., secp256k1). A sufficiently powerful quantum computer running Shor's algorithm could break the underlying Discrete Logarithm Problem (DLP), compromising both funds and privacy. While this is a long-term threat shared by most cryptocurrencies, it is particularly acute for stealth addresses because compromising the spend key reveals funds and compromising the view key reveals all historical transaction graphs.

The enhanced privacy provided by stealth addresses conflicts with regulatory frameworks like Travel Rule (FATF Recommendation 16) and Anti-Money Laundering (AML) directives, which require VASPs to identify transaction origins and destinations. This creates significant adoption barriers:

• Exchange Delistings: Assets with strong privacy features face delisting from regulated exchanges.
• Proof-of-Funds Challenges: Users may find it difficult to provide auditable proof of funds for loans or compliance without revealing their view key.
• Design Tensions: Future implementations may need to incorporate regulatory-compliant privacy, which is a complex cryptographic and design challenge.

A key management pattern used in stealth address systems to separate auditing from spending authority.

• View Key: A private key that allows a user (or auditor) to scan the blockchain and identify incoming transactions to their stealth addresses, but not spend the funds.
• Spend Key: The master private key required to authorize transactions and spend funds from the generated stealth addresses. This separation enhances privacy and enables selective transparency.

A standardized protocol, notably used by Monero, for generating stealth addresses. It involves two key pairs per user:

• A public view key and private view key for scanning.
• A public spend key and private spend key for spending. The sender uses the recipient's public keys to compute a one-time public key (the stealth address) and an ephemeral public key (published on-chain). The recipient uses their private view key and the ephemeral key to scan for and derive the corresponding private key for the funds.

A one-time public key generated by the sender and included in the transaction data on-chain. It acts as a critical piece of cryptographic material that allows the intended recipient—and only the intended recipient—to link the stealth address output to their master private keys. Anyone else sees it as random data. It is essential for the recipient's scanning process to discover their funds.

Alternative privacy solutions with a different threat model. While stealth addresses hide the link between a recipient's identity and a specific transaction, privacy pools (or mixers) break the on-chain link between transactions by pooling and shuffling funds from many users. Stealth addresses are a recipient-side technology, whereas mixers often require active sender participation and a trusted setup or cryptographic proof (like a zk-SNARK).

A broader cryptographic primitive used for privacy and scaling. While stealth addresses use ECC, more advanced systems may employ zk-SNARKs or zk-STARKs to prove the validity of a transaction (e.g., a stealth address spend) without revealing the sender, recipient, or amount. ZKPs can provide stronger anonymity sets and hide transaction amounts, which basic stealth addresses do not inherently do.