How to Implement Stealth Addresses in a New Cryptocurrency

Stealth addresses provide strong on-chain privacy by ensuring each transaction from a sender to a recipient generates a unique, one-time destination address. This breaks the fundamental linkability of public blockchains, where a single static address can be used to track all of a user's incoming payments and balance. Unlike mixing services, stealth addresses are a native protocol-level solution that doesn't require trusting third parties or batching transactions. Implementing them involves cryptographic operations for address generation, a system for publishing spending keys, and a mechanism for recipients to scan the blockchain for their funds.

The core cryptographic construction typically relies on Elliptic Curve Cryptography, such as the secp256k1 curve used by Bitcoin and Ethereum. The recipient has a static view key and spend key pair. For each transaction, the sender uses the recipient's public view key and a random nonce to generate a unique stealth meta-address and a corresponding ephemeral public key. The funds are sent to the stealth address, which only the recipient, using their private view key, can detect as belonging to them. This process ensures the sender cannot link subsequent transactions to the same recipient, and observers cannot link the stealth address to the recipient's public identity.

A critical component is the Diffie-Hellman key exchange performed on-chain. The sender uses the recipient's public view key and their own random secret to compute a shared secret. This secret is then hashed to derive the unique stealth address and the transaction key. The ephemeral public key (part of this exchange) must be published in the transaction data, often in an OP_RETURN output or a smart contract event, so the recipient can perform the reciprocal computation. Implementations must carefully manage this metadata to avoid bloating the blockchain while ensuring it is reliably accessible for scanning.

For a recipient's wallet, the implementation requires a scanning engine. This engine monitors all new transactions, retrieves the published ephemeral public keys, and performs the Diffie-Hellman computation using the recipient's private view key. If the computed stealth address matches an output in the transaction, the wallet imports the corresponding private key (derived using the recipient's spend key) to spend the funds. This process is computationally intensive, so optimization strategies like Bloom filters or key derivation caching are essential for practical client software.

Real-world protocol examples include Monero's one-time addresses, which are mandatory for all transactions, and Zcash's shielded addresses (z-addrs) which use a different zero-knowledge proof system. For a new cryptocurrency, key decisions include whether stealth addresses are optional or mandatory, how ephemeral keys are stored, and the choice between non-interactive (sender-driven) and interactive schemes. The ERC-5564 standard defines a framework for stealth addresses on Ethereum, providing a valuable reference for smart contract-based implementations.

Successful integration requires rigorous auditing of the cryptographic code and key management logic. Common pitfalls include improper random number generation for the sender's nonce, which can compromise security, and inefficient scanning algorithms that degrade user experience. By implementing stealth addresses, a protocol can offer a significant privacy upgrade, moving from pseudonymity to stronger financial confidentiality by default, without relying on external applications or services.

The primary prerequisite is a robust elliptic curve cryptography (ECC) library. Stealth addresses, as defined in standards like ERC-5564, rely on the Diffie-Hellman key exchange using the secp256k1 curve. Your blockchain's native wallet system must support generating key pairs (spending_private_key, spending_public_key), deriving shared secrets, and performing point addition on the curve. Libraries such as libsecp256k1 or @noble/curves provide these essential operations.

Your network must have a mechanism for publishing stealth metadata. This is the data a sender broadcasts to enable the recipient to discover their stealth address. At minimum, this includes the sender's ephemeral public key (ephemeralPubKey) and a view tag. The metadata can be published on-chain (e.g., in a transaction's calldata or a log), or off-chain via a relay network. You must decide on a canonical location and format for this data, as all wallets need to scan it consistently.

A critical component is the scanning engine. Every recipient must run a process that monitors the network for stealth metadata. The scanner uses the recipient's view_private_key to compute a shared secret with each ephemeralPubKey, derives potential stealth addresses, and checks the view tag for a match—a one-byte filter that reduces computational load by ~99.6%. This engine must be integrated into your node software or light client protocol.

You need a deterministic algorithm for stealth address derivation. The standard formula is: stealth_address = spending_pubKey + hash(shared_secret) * G. Here, G is the generator point. The recipient must be able to compute the corresponding stealth_private_key as: stealth_private_key = spending_private_key + hash(shared_secret). This key derivation must be flawless and standardized across all implementations on your chain.

Finally, address formats and wallet UX must be considered. Your blockchain's address system (e.g., bech32 for Bitcoin-like chains, hex for EVM) must accommodate stealth addresses. Wallets need new UI flows: senders require a field to input a recipient's spending_public_key, and recipients need a clear interface for managing discovered stealth funds and their associated private keys.

Stealth addresses enable private payments by generating a unique, one-time receiving address for each transaction, breaking the linkability of funds on a public ledger. The core cryptographic primitive is Elliptic Curve Cryptography (ECC), typically using the secp256k1 curve (as in Bitcoin and Ethereum). The system involves two key pairs: a long-term spending key (private) and view key (public/private) for the recipient, and ephemeral keys generated by the sender. The fundamental goal is to allow a sender to derive a fresh public address that only the intended recipient, using their private view key, can discover and spend from.

The implementation begins with defining the recipient's keys. Generate a cryptographically secure random scalar a as the spending private key. The corresponding spending public key is A = a*G, where G is the generator point. Next, generate a random scalar b as the view private key. The view public key is B = b*G. The recipient publishes the pair (A, B) as their stealth address metadata, often in a registry or as part of their profile. The private keys (a, b) must be kept secret, with b used for scanning and a used for spending.

When a sender wants to send funds, they generate a random ephemeral private key r. The ephemeral public key R = r*G is included in the transaction. The sender then computes the shared secret: s = Hash(r * B), where Hash is a cryptographic hash function like Keccak-256. This shared secret is used to derive the stealth address: P = A + Hash(s)*G. The sender constructs the transaction output to this public key P. Crucially, R is published, allowing the recipient to find the transaction.

The recipient scans the blockchain for new transactions containing an ephemeral key R. For each R, they compute the same shared secret using their private view key: s = Hash(b * R). Since b*R = b*(r*G) = r*(b*G) = r*B, this matches the sender's calculation. They then derive the candidate stealth public key P' = A + Hash(s)*G. If this matches an output's locking script, they have found their funds. To spend, they need the corresponding private key. This is p = a + Hash(s). They can sign transactions with p, proving ownership of the output at P without revealing a.

Integrating this into a blockchain requires protocol-level changes. You must define a new transaction format that includes the ephemeral public key R. The consensus rules must validate that R is a valid point on the curve. Outputs locked to stealth addresses P are standard Pay-to-Public-Key-Hash (P2PKH) outputs, so no change is needed for the scripting system. However, you need to implement a scanning protocol in wallet software so users can detect incoming payments using their view key. For scalability, consider using Diffie-Hellman key exchange variants or address registries to streamline the publishing of view keys.

Consider practical enhancements and trade-offs. Using dual-key stealth addresses (separate spend/view keys) is the standard for its security model. For better efficiency, some implementations like Monero use a one-time address scheme integrated with ring signatures. Always audit the cryptographic library (e.g., libsecp256k1) for side-channel resistance. The major challenge is metadata leakage; while the payment destination is hidden, the act of publishing R and the stealth metadata (A,B) can create other analytic vectors. This implementation provides strong privacy for recipients but requires sender cooperation and active blockchain scanning.

Sender-side address generation is the foundational cryptographic operation that enables stealth addresses. The process begins with the sender obtaining the recipient's public stealth meta-address, which is a tuple of two public keys: a spending public key (P_spend) and a viewing public key (P_view). This meta-address is static and can be published by the recipient, similar to a regular public address. The core innovation is that the sender uses this information, combined with a random secret, to derive a unique, one-time destination address on the blockchain that only the intended recipient can discover and spend from.

The generation algorithm follows a deterministic process. First, the sender generates a random 32-byte ephemeral private key (r). This is a critical secret that must not be reused. The sender then computes the corresponding ephemeral public key (R = r * G), where G is the generator point of the elliptic curve (e.g., secp256k1). This R will be published in the transaction and acts as a cryptographic hint. Next, the sender calculates a shared secret (s) using Elliptic Curve Diffie-Hellman (ECDH): s = H(r * P_view), where H is a cryptographic hash function like keccak256. This shared secret is known only to the sender and the recipient who holds the corresponding private view key.

The shared secret s is then used to derive the unique, one-time stealth public key (P_stealth) for this specific transaction. The standard derivation is P_stealth = P_spend + s * G. This new public key is hashed to form a standard blockchain address (e.g., a 20-byte Ethereum address). Funds sent to this address appear as a normal transaction to any external observer, with no visible link to the recipient's published meta-address. The ephemeral public key R is included in the transaction data or a dedicated field (like the input data in Ethereum) so the recipient can later scan for transactions intended for them.

From an implementation perspective, here is a simplified Python pseudocode example using the secp256k1 library:

pythonCopy
import secp256k1
import hashlib

def generate_stealth_address(P_spend, P_view):
    # 1. Generate ephemeral key pair
    r = secp256k1.PrivateKey()
    R = r.pubkey
    
    # 2. Compute shared secret: s = H(r * P_view)
    shared_point = r.ecdh(P_view)
    s = hashlib.sha256(shared_point).digest()
    s_int = int.from_bytes(s, 'big')
    
    # 3. Derive stealth public key: P_stealth = P_spend + s*G
    sG = secp256k1.PublicKey.from_secret(s_int)
    P_stealth = P_spend.combine(sG)
    
    # 4. Hash to create final address (e.g., Ethereum style)
    address = '0x' + hashlib.keccak256(P_stealth.serialize()[1:]).digest()[-20:].hex()
    
    return address, R

The sender then broadcasts a transaction to the derived address and publishes R.

Key security considerations for this step include the absolute necessity of randomness for the ephemeral key r. Reusing r for two different recipients would leak the link between those transactions and potentially compromise privacy. Furthermore, the system's security relies on the strength of the ECDH exchange and the hash function. Implementations must use well-audited cryptographic libraries. The published R does not reveal the stealth address relationship on its own, as the link can only be established by the party holding the corresponding private view key, completing the privacy guarantee.

The recipient's primary task is to scan the blockchain for transactions that belong to them. They do this by monitoring the announcement event emitted by the stealth address registry contract. For each announcement, they compute the stealth meta-address (spendPubKey, viewPubKey) from the ephemeral public key included in the event. Using their private view key, they can derive a shared secret: s = ecdhSharedSecret(ephemeralPubKey, viewPrivKey). From this secret, they derive the stealth address stealthAddr = generateStealthAddress(spendPubKey, s) and check if it matches the stealthAddress in the announcement. If it matches, they have found their transaction.

Once a transaction is identified, the recipient must generate the corresponding private key to spend the funds. The spending private key for the stealth address is derived using the same shared secret s. The calculation is: stealthPrivKey = spendPrivKey + s. Crucially, this derivation happens entirely off-chain; the recipient's original spendPrivKey never appears on the blockchain. The derived stealthPrivKey is a standard ECDSA private key that can be used to sign a transaction spending the UTXO at the stealthAddr. This process ensures only the intended recipient, who holds both private keys, can ever access the funds.

A critical implementation detail is handling key derivation collisions. The shared secret s must be hashed before being used in address and key generation to ensure it's a valid scalar in the elliptic curve's field. A common practice is to use s_hashed = keccak256(abi.encodePacked(s)). The stealth address is then computed as stealthAddr = address(keccak256(spendPubKey + s_hashed) * G), where G is the generator point. This standardized hashing prevents subtle security issues related to invalid curve points.

For practical integration, wallets need a background scanning service. This service listens for new blocks, fetches Announcement logs, and performs the scanning derivation for each. Found transactions must be indexed with their metadata (ephemeral public key, stealth address) and the derived private key must be securely stored, often in an encrypted keystore. The ERC-5564 specification provides a standard interface for these announcements, enabling interoperability between different wallet implementations.

Finally, spending the funds is identical to spending from any other Externally Owned Account (EOA). The user's wallet constructs a standard transaction (e.g., ETH transfer or token approval) using the derived stealthPrivKey to sign it. From the network's perspective, this is a normal transaction from stealthAddr. This design preserves privacy-forward UX; the recipient interacts with their familiar wallet interface, while the complex stealth address mechanics are handled automatically in the background.

Integrating stealth addresses requires changes at the consensus layer and transaction validation logic. The core addition is a new transaction type, often called a STEALTH_TX, which embeds the necessary cryptographic components for the recipient. This transaction must be a standard, broadcastable object in your node's mempool and must be validated according to new rules. The primary validation steps for a node are: verifying the ephemeralPublicKey is on the curve, ensuring the viewTag is correctly derived, and confirming the transaction output commitments are valid. Failure in any check should result in the transaction being rejected, just like any other invalid tx.

The most critical protocol change is how unspent transaction outputs (UTXOs) are identified and spent. In a UTXO model, a stealth output is not directly linked to the recipient's public address in the blockchain's state. Instead, the recipient's wallet must scan every new block, using their private view key to compute the shared secret and check the viewTag for each potential output. If a match is found, the wallet uses its spend key to derive the unique, one-time private key for that output, allowing it to construct a valid spending signature later. Your node's blockchain indexer must support efficient scanning for these stealth components to enable performant wallets.

For a practical example, consider implementing the STEALTH_TX structure in a Rust-based chain. You would define a new variant in your transaction enum and implement the Verifiable trait. The verification function would parse the stealth metadata, perform the elliptic curve Diffie-Hellman (ECDH) calculation between the ephemeral public key and a placeholder, and validate the resulting hash against the provided commitments. Resources like the Zcash protocol specification for Sapling addresses or Monero's research lab provide concrete models for these cryptographic constructions and consensus rules.

Node software must expose new RPC endpoints or indexing services for wallet compatibility. At a minimum, wallets need a way to fetch all transaction outputs with stealth metadata from recent blocks, as scanning the raw blockchain is inefficient. A dedicated getstealthtxouts RPC that accepts a scanPublicKey (derived from the user's view key) and returns potential matches significantly improves user experience. Furthermore, your node's block explorer backend should be updated to recognize and perhaps partially decode stealth transactions, while still preserving recipient privacy, to maintain network transparency for observers.

Finally, rigorous testing and audit of the implementation is non-negotiable. Create extensive unit tests for the cryptographic primitives (key derivation, ECDH, view tag generation) and integration tests that simulate full transaction cycles: generation, broadcast, validation, block inclusion, and wallet scanning/spending. Consider the edge cases, such as transaction malleability, fee calculation for the new tx type, and handling during chain reorganizations. A flawed implementation can lead to permanent loss of funds or privacy leaks, making this phase as critical as the cryptographic design itself.

The core cryptographic challenge is selecting a secure and efficient algorithm. The Elliptic Curve Diffie-Hellman (ECDH) protocol, typically using the secp256k1 curve (common in Bitcoin and Ethereum), is the standard. You must generate a spending key pair (sk_spend, P_spend) and a viewing key pair (sk_view, P_view) for each user. The stealth address for a transaction is a one-time public key derived by the sender using the recipient's public P_spend and a random nonce. The recipient scans the blockchain using their sk_view to find transactions intended for them, then uses their sk_spend to derive the corresponding one-time private key for spending.

Integrating this into the transaction model is complex. The sender must include the stealth metadata—the ephemeral public key (R) used in the ECDH derivation—in the transaction. This can be placed in an OP_RETURN output, a new transaction field, or a witness structure. The recipient's client must run a scanning process, checking every new transaction's metadata against their viewing key to detect incoming funds. This requires efficient key derivation and scanning logic to avoid performance bottlenecks, especially for light clients or wallets with many addresses.

On-chain privacy must be balanced with regulatory and usability concerns. While stealth addresses hide the link between a recipient's master public key and their transaction history, they do not conceal transaction amounts or the sender's identity by default. For full privacy, implementation is often paired with confidential transactions (like Pedersen Commitments) or zk-SNARKs. Furthermore, you must decide if the protocol will support dual-key stealth addresses by default or as an optional feature, as this impacts wallet compatibility and the user experience for less technical users.

Key management and wallet architecture present significant hurdles. Users must securely back up both their spending and viewing private keys. Loss of the sk_view key means losing the ability to find received funds, while loss of sk_spend means losing the ability to spend. Wallets need new UI flows for generating and sharing a stealth address meta-address (often the concatenation of P_spend and P_view), and for the background scanning process. Implementing key derivation according to standards like ERC-5564 (for EVM chains) can aid interoperability.

Finally, network and consensus rules must adapt. Miners/validators need to accept transactions with stealth metadata without being able to decipher them. The protocol must define rules to prevent bloating the chain state with unspent outputs from undiscovered stealth addresses (UTXO model) or ensure smart contracts can handle stealth address logic (account model). Thorough auditing of the cryptographic implementation and extensive testing on a testnet are non-negotiable steps before mainnet launch to prevent catastrophic fund loss.

To implement stealth addresses, you must decide on your system's architecture. A common approach is to use a viewing key and spending key model, where the viewing key is derived from the sender's ephemeral public key and the receiver's stealth meta-address. This allows an indexer or the receiver's wallet to scan the blockchain for incoming transactions without revealing the link to their public identity. The spending key, derived separately, is required to authorize the spending of funds from the stealth address. This separation is critical for privacy and security.

Your implementation will need several key functions. You must generate stealth meta-addresses for users, create stealth_address and ephemeral_pubkey fields for transactions, and build a scanning module. Here is a simplified Python pseudocode structure using the SECP256k1 curve:

pythonCopy
# Sender: Generate stealth address for receiver
ephemeral_privkey = random_scalar()
ephemeral_pubkey = G * ephemeral_privkey
shared_secret = hash(receiver_spend_pubkey * ephemeral_privkey)
stealth_pubkey = receiver_spend_pubkey + G * hash(shared_secret | 0)
# Transaction includes (stealth_pubkey, ephemeral_pubkey)

The receiver scans by computing the same shared secret using their private spend key and the published ephemeral_pubkey to see if it matches a transaction output.

For a production system, consider integrating with existing standards and infrastructure. The ERC-5564: Stealth Addresses specification provides a framework for Ethereum and EVM-compatible chains, defining standard interfaces for stealth meta-addresses and announcements. You can also leverage existing privacy-focused libraries like the zkBob suite or Tornado Cash's circuits for enhanced anonymity sets. Building a reliable announcement registry—a smart contract or a decentralized service like The Graph for indexing stealth transaction events—is essential for usability.

Next, rigorously test your implementation. Start with unit tests for the core cryptographic operations, ensuring key derivation and stealth address generation are deterministic and secure. Proceed to integration tests that simulate the full flow: a sender funding a stealth address, an indexer scanning the chain, and the receiver detecting and spending the funds. Use testnets like Goerli or Sepolia extensively. Security audits are non-negotiable; engage specialized firms to review the cryptography, smart contracts, and potential gas optimization vulnerabilities before any mainnet deployment.

The future of stealth addresses involves scaling and interoperability. Research batch processing to allow a user to scan for multiple transactions efficiently, and consider cross-chain stealth addresses using protocols like IBC or LayerZero. As the ecosystem matures, contributing to and adopting open standards will reduce fragmentation and improve user experience. Your implementation is a step toward a more private blockchain future where financial transactions are confidential by default, not as an added feature.