How to Implement Stealth Addresses for Payouts

Stealth addresses provide a method for sending assets to a recipient without publicly linking the payment to their primary wallet address. This is achieved by generating a unique, one-time destination address for each transaction, derived from shared secrets between the sender and receiver. Unlike standard Ethereum or Bitcoin transactions, where the recipient's address is visible on-chain, stealth address payouts enhance privacy by breaking the linkability of payments. This is crucial for applications requiring confidentiality, such as payroll disbursements, private grants, or whitelisted airdrops where you don't want to expose recipient balances or relationships.

The core mechanism relies on elliptic curve cryptography (ECC), specifically the secp256k1 curve used by Ethereum. The protocol involves two main parties: the sender (or payer) and the receiver. The receiver has a static spending private key and a corresponding viewing public key. To initiate a private payment, the sender uses the receiver's viewing public key and a random nonce to generate a unique stealth meta-address and a one-time ephemeral public key. The actual funds are sent to the stealth address, which only the intended receiver can derive and control using their private keys and the ephemeral public key published on-chain.

A basic implementation involves several cryptographic steps. First, the receiver generates their key pair: a spending key sk_spend and a viewing key vk_view. Their stealth meta-address is a combination of the public keys P_spend and P_view. When sending funds, the sender generates a random 256-bit nonce r and computes the shared secret S = r * P_view. They then derive the stealth address stealth_pubkey = P_spend + hash(S) * G. The sender publishes the ephemeral public key R = r * G (where G is the generator point) in the transaction, often as a log or calldata. The receiver scans the chain for such R values, recomputes the shared secret S = vk_view * R, and derives the same stealth address and its corresponding private key to claim the funds.

For developers, integrating this requires careful on-chain and off-chain components. On-chain, a smart contract or a modified payment router must handle the logic to accept the ephemeral public key R and direct funds to the computed stealth address. Off-chain, a watcher service or client-side software is needed for recipients to scan new blocks, compute potential stealth addresses, and detect incoming payments. Libraries like starkbank/ecdsa for cryptographic operations and ethers.js for blockchain interaction are essential. A critical consideration is gas efficiency; publishing R and potentially performing on-chain computations can increase transaction costs compared to a simple transfer.

Several existing projects and standards can serve as a foundation. The ERC-5564: Stealth Addresses standard defines interfaces for generating stealth addresses and announcing them on-chain. ZK-based systems like Aztec or Tornado Cash use different privacy primitives but share the goal of transaction obfuscation. When implementing, you must also manage key storage securely—the receiver's viewing key must be kept safe but accessible for scanning, while the spending key requires the highest security. Furthermore, consider the user experience; automating the scanning and claiming process is vital for adoption.

In practice, stealth address payouts are powerful but introduce complexity. They are best suited for use cases where privacy is a non-negotiable requirement and where users are technically adept or assisted by a smooth wallet interface. Future developments in account abstraction and privacy-preserving L2s may integrate these mechanisms more seamlessly. For now, implementing them requires a solid grasp of elliptic curve math, secure off-chain infrastructure, and a clear understanding of the privacy-utility trade-offs involved in on-chain systems.

Stealth addresses enable private payments by generating a unique, one-time receiving address for each transaction, shielding the recipient's primary wallet balance and history. For implementing payouts, you'll need a foundational understanding of elliptic curve cryptography (ECC) and the Diffie-Hellman key exchange. The core workflow involves a sender using a recipient's public spending key and viewing key to derive a unique stealth address, while only the recipient can detect and spend from it using their private keys. This is distinct from mixers or zk-SNARKs, as it provides privacy at the address level without requiring a shared pool of funds.

Before writing code, set up your development environment. You will need Node.js (v18+) and a package manager like npm or yarn. Initialize a new project and install essential libraries: ethers.js or viem for blockchain interaction, and a cryptographic library such as noble-curves for secure elliptic curve operations. For testing, configure a local development network using Hardhat, Foundry, or Anvil. Ensure you have access to a funded testnet wallet (e.g., on Sepolia) for deploying contracts and sending test transactions.

The cryptographic setup revolves around the secp256k1 curve, used by Ethereum and Bitcoin. You must generate or manage two key pairs for each recipient: a spending key pair (public/private) for authorizing transfers from the stealth address, and a viewing key pair for detecting incoming payments. The sender uses the recipient's public spending key (P_spend) and a random ephemeral private key (r) to compute a shared secret and the final stealth address stealth_address = hash(shared_secret) * G + P_spend. The recipient scans blocks using their private viewing key to find transactions destined for them.

For on-chain payouts, you typically deploy a Stealth Address Registry contract. This contract stores users' public spending and viewing keys in a mapping, allowing senders to fetch them. A basic Payout Distributor contract can then automate bulk payments. The distributor function would, for each recipient, fetch their public keys from the registry, perform the stealth address derivation off-chain, and initiate a transfer to the computed address. All cryptographic operations must be done off-chain to avoid excessive gas costs; only the final stealth_address and transaction are submitted on-chain.

Here is a simplified JavaScript example using noble-curves to derive a stealth address for a payout:

javascriptCopy
import { secp256k1 } from '@noble/curves/secp256k1';
import { sha256 } from '@noble/hashes/sha256';

function generateStealthAddress(recipientPubSpend, ephemeralPrivKey) {
  // Compute shared secret: S = r * P_spend
  const sharedSecret = secp256k1.getSharedSecret(ephemeralPrivKey, recipientPubSpend);
  // Hash the shared secret
  const h = sha256(sharedSecret);
  // Convert hash to a private key point: H = h * G
  const H = secp256k1.ProjectivePoint.fromPrivateKey(h);
  // Convert recipient's public key to a point
  const P_spend_point = secp256k1.ProjectivePoint.fromHex(recipientPubSpend);
  // Stealth address public key: P_stealth = H + P_spend
  const P_stealth = H.add(P_spend_point);
  return P_stealth.toHex(false); // Uncompressed public key
}

The recipient would use their private viewing key to scan for the corresponding ephemeralPubKey (r*G) published by the sender to reverse this process.

Critical considerations for production include managing key storage securely, implementing efficient blockchain scanning for recipients (using services like The Graph or OpenZeppelin Defender for automation), and handling gas overhead for multiple stealth transactions. Always audit your cryptographic implementation and consider existing standards like ERC-5564 for interoperability. Test thoroughly on a testnet with various scenarios before deploying a mainnet payout system to ensure privacy and reliability.

Stealth addresses enable private transactions on public blockchains. The core idea is that a sender can generate a unique, one-time destination address for a recipient using only the recipient's public view key and spend key. This address appears unrelated to the recipient's published stealth address meta-address on-chain, breaking the linkability between transactions. This is crucial for use cases like payroll, grants, or airdrops where recipient privacy must be preserved. The recipient can then scan the blockchain with their private view key to find funds sent to them and spend them with their private spend key.

The implementation relies on elliptic curve cryptography, typically on the secp256k1 curve used by Ethereum and Bitcoin. The recipient generates a key pair: a public spend key P_s and a public view key P_v. These are combined into a single stealth meta-address (e.g., st:0x02...). To send funds, the sender uses this meta-address and a random secret r to compute a shared secret s = r * P_v. From s, they derive a one-time ephemeral public key R = r * G (which is published) and the stealth address P_stealth = P_s + hash(s) * G. Funds are sent to P_stealth.

On the recipient's side, they monitor new transactions for published ephemeral keys R. For each R, they compute the same shared secret using their private view key p_v: s = p_v * R. They then check if the stealth address P_s + hash(s) * G has received funds. If it matches, they can derive the corresponding private key for that stealth address: p_stealth = p_s + hash(s). This allows them to sign a transaction to spend the funds. Libraries like @noble/curves provide the necessary cryptographic primitives.

For a practical payout system, you need an off-chain component. The payer's backend would generate the stealth address for each recipient, initiate the transaction, and optionally emit an off-chain notification with the ephemeral public key R. The recipient's wallet must run a scanning service to detect incoming payments. The ERC-5564: Stealth Addresses standard proposes a common interface for this, defining events like StealthKeyChanged and functions for key generation to improve interoperability across wallets and protocols.

Key security considerations include the necessity of secure random number generation for the sender's r and the secure storage of the recipient's private keys. If r is reused or predictable, the shared secret can be compromised. Furthermore, while stealth addresses hide the recipient, they do not hide transaction amounts or the sender, which may require complementary privacy solutions like zk-SNARKs or coin mixers for full anonymity.

Every participant in a stealth address system requires two key pairs: a spending key pair and a viewing key pair. The spending key, typically an Ethereum private key, is used to authorize transactions and must be kept absolutely secret. The viewing key is used to scan the blockchain for incoming transactions intended for the user's stealth addresses. This separation of concerns is critical for both security and privacy, as it allows users to delegate scanning duties without exposing their ability to spend funds.

The core of stealth address generation relies on elliptic curve cryptography, specifically the secp256k1 curve used by Ethereum. The user's stealth meta-address is derived from these keys and is publicly shared. It is computed as a combination of the user's public spending key (spendPubKey) and public viewing key (viewPubKey). This meta-address is not an on-chain account but a compact, portable identifier that payers use to generate unique, one-time deposit addresses for the recipient.

Here is a simplified conceptual example of key generation using the ethers library:

javascriptCopy
import { ethers } from 'ethers';
// Generate random wallets for spending and viewing keys
const spendingWallet = ethers.Wallet.createRandom();
const viewingWallet = ethers.Wallet.createRandom();

const stealthMetaAddress = {
  spendPubKey: spendingWallet.publicKey,
  viewPubKey: viewingWallet.publicKey
};
// The stealthMetaAddress object is what you share publicly.

In practice, protocols like ERC-5564 define a standard ABI-encoded format for this meta-address to ensure interoperability across different wallets and applications.

The security model hinges on the Diffie-Hellman key exchange. When a payer wants to send funds, they use the recipient's public stealth meta-address and a random secret to compute a shared secret. This shared secret deterministically generates a unique stealth address for that specific transaction. Only the recipient, who holds the corresponding private viewing key, can compute the same shared secret, discover the new address, and derive its private key using their private spending key.

The core of stealth address generation is an elliptic curve Diffie-Hellman (ECDH) key exchange. The sender, Alice, uses the recipient's published stealth meta-address (e.g., 0x123... + 0x456...) and a randomly generated, one-time secret called the ephemeralPrivateKey. She performs scalar multiplication on the elliptic curve: sharedSecret = ephemeralPrivateKey * spendingPublicKey. This sharedSecret is a secret point known only to Alice, but which Bob can later derive using his corresponding private key. The randomness of the ephemeralPrivateKey ensures each payment generates a unique sharedSecret and, consequently, a unique stealth address.

Next, this sharedSecret is hashed to create a deterministic stealth address private key. A common method, as outlined in ERC-5564, uses Keccak256: stealthPrivateKey = keccak256(sharedSecret || 0x00). The 0x00 is a version byte for future compatibility. The corresponding stealth public address is then derived from this private key. For Ethereum, this means computing stealthPublicKey = stealthPrivateKey * G (where G is the generator point) and then converting that public key to a standard 20-byte Ethereum address via the last 20 bytes of keccak256(stealthPublicKey).

Crucially, the sender must also generate a view tag. This is a single byte derived from the sharedSecret (e.g., the first byte of keccak256(sharedSecret || 0x01)). Its purpose is optimization: instead of scanning all transactions, a recipient's wallet can quickly filter for transactions where the view tag matches a precomputed value, drastically reducing computational load. The final output of this step is a tuple containing the derived stealthAddress and the ephemeralPublicKey (ephemeralPrivateKey * G), which must be published so the recipient can perform their side of the computation.

Here is a simplified Python pseudocode example using the secp256k1 curve:

pythonCopy
import hashlib
from secp256k1 import PrivateKey, PublicKey

def derive_stealth_address(recipient_spending_pubkey, ephemeral_privkey):
    # ECDH: shared secret point
    shared_secret_point = ephemeral_privkey.ecdh(recipient_spending_pubkey)
    
    # Hash to get stealth private key seed
    shared_secret_bytes = shared_secret_point.serialize()
    stealth_privkey_seed = hashlib.sha3_256(shared_secret_bytes + b'\x00').digest()
    stealth_privkey = PrivateKey(privkey=stealth_privkey_seed)
    
    # Derive the stealth Ethereum address
    stealth_pubkey = stealth_privkey.pubkey
    stealth_address = '0x' + hashlib.sha3_256(stealth_pubkey.serialize()[1:]).digest()[-20:].hex()
    
    # Generate view tag
    view_tag = hashlib.sha3_256(shared_secret_bytes + b'\x01').digest()[0]
    
    return stealth_address, view_tag, ephemeral_privkey.pubkey

In practice, protocols like ZKBob or Umbra implement variations of this scheme. The security relies on the strength of the elliptic curve and the randomness of the ephemeralPrivateKey. If this key is reused or predictable, the sharedSecret becomes predictable, breaking the unlinkability guarantee. Therefore, secure random number generation is non-negotiable. The output stealth address is a standard Ethereum address, allowing funds to be sent to it via any regular transaction, smart contract, or bridge, making it compatible with existing infrastructure.

The core of the payout system is the settlement contract, a smart contract that holds funds and executes transfers to stealth addresses. Your application's backend must interact with this contract to initiate payments. This involves two primary actions: depositing funds into the contract's escrow and submitting a stealth transaction with the necessary cryptographic parameters. For Ethereum-based systems, this is typically done using a library like Ethers.js or Web3.py, calling functions like deposit() and submitTransaction().

To submit a transaction, you must construct the payload defined by the protocol's StealthTx struct. This includes the ephemeralPubKey (a one-time public key), the hashed stealthAddress, and the viewTag. The viewTag is a critical 1-byte value derived from the shared secret; it allows the recipient to efficiently scan for transactions intended for them without revealing their identity on-chain. Your code must generate these values using the same cryptographic operations (like SECP256k1 elliptic curve multiplication) used when the stealth address was initially created.

A secure integration requires handling private keys carefully. The spending private key must never be exposed on the backend server. Instead, use a transaction relayer or a signer service (like a hardware security module or a managed service such as OpenZeppelin Defender) to sign the settlement contract calls. This separates the key management from the application logic. Always estimate gas and handle potential reverts, as settlement contracts often include checks for valid stealth parameters and sufficient escrow balance.

For developers, the integration flow is: 1) Generate stealth address metadata off-chain, 2) Encode the StealthTx data, 3) Have a secure signer approve the contract interaction, and 4) Broadcast the transaction. Testing is essential; use a forked mainnet or a testnet deployment of the settlement contract (like those provided by the Ethereum Foundation's stealth address efforts) to validate the entire flow before going live.

Consider gas optimization and user experience. While the recipient's privacy is paramount, the sender pays the gas for the settlement transaction. Using a gas-efficient contract design and possibly leveraging layer-2 solutions or batched transactions can reduce costs. Furthermore, your application should provide transaction hashes and a way for recipients to query the status of their stealth payments, perhaps through an indexed database of viewTag matches.

After a sender broadcasts a stealth transaction, the intended recipient must discover it. This is done by scanning the blockchain for Announcement events emitted by the stealth address registry contract. The recipient's client software, typically a wallet, iterates through recent blocks, checking each event against their private spending key. This process is computationally efficient, as the recipient only needs to perform a simple elliptic curve multiplication for each announcement to see if it corresponds to their key.

The core scanning logic involves deriving a shared secret s for each announcement. Using the ephemeralPubKey from the event and their private spending key spendPrivKey, the recipient calculates s = spendPrivKey * ephemeralPubKey. From this secret, they derive the stealth meta-address stealthAddress and check if it matches the one in the event. A match means the transaction is for them. They then use s to generate the private key for the one-time stealth address: stealthPrivKey = s + spendPrivKey. This key is used to sign the claim transaction.

Here is a simplified TypeScript example using ethers.js and the @noble/curves library for scanning:

typescriptCopy
async function scanForAnnouncements(provider, registryAddress, spendPrivKey) {
  const registry = new ethers.Contract(registryAddress, ABI, provider);
  const filter = registry.filters.Announcement();
  const events = await registry.queryFilter(filter, -5000); // Last ~5000 blocks

  for (const event of events) {
    const { ephemeralPubKey, stealthAddress } = event.args;
    // Calculate shared secret s = spendPrivKey * ephemeralPubKey
    const s = secp256k1.getSharedSecret(spendPrivKey, ephemeralPubKey);
    // Derive the stealth address from s
    const derivedStealthAddr = deriveStealthAddress(s, ephemeralPubKey);
    
    if (derivedStealthAddr === stealthAddress) {
      // Found! Derive the private key for the stealth address
      const stealthPrivKey = secp256k1.utils.mod(
        secp256k1.utils.bytesToNumberBE(s) + secp256k1.utils.bytesToNumberBE(spendPrivKey),
        secp256k1.CURVE.n
      );
      return { stealthAddress, stealthPrivKey };
    }
  }
  return null;
}

Once the private key for the stealth address is derived, the recipient can claim the funds. This involves creating a standard transaction from the stealth address, signing it with the derived stealthPrivKey, and broadcasting it to the network. The funds are now under the recipient's control. For ETH, this is a simple transfer. For ERC-20 tokens, the recipient must call the transfer function on the token contract. It is critical that this claiming transaction is broadcast before anyone else who might also be scanning the chain, as the stealth address private key is deterministic from public data.

To optimize user experience, wallets should implement background scanning. This can be done via indexer services like The Graph for historical queries or by subscribing to new blocks via a provider's WebSocket connection. For production systems, consider using a viewing key architecture, where a separate, less sensitive key is used for scanning, while the spending key remains in cold storage. This separation enhances security by limiting exposure of the main private key.

Key considerations for implementation include gas costs for the claim transaction, which the recipient must pay, and privacy trade-offs. While the stealth address itself is private, the claiming transaction links it to the recipient's final address on-chain. Using a fresh address or a mixer for the final withdrawal can help preserve privacy. Always audit the derived key logic against the specific stealth address standard you are implementing, such as ERC-5564.

To implement stealth addresses for payouts, start by integrating a library like the EIP-5564 reference implementation or a production-ready SDK such as ZeroDev's Kernel with ERC-4337. Your architecture must handle two main flows: sender-side stealth address generation and receiver-side scanning. The sender's system uses the recipient's spendingPublicKey and a random nonce to derive a unique, one-time deposit address off-chain, then sends funds to it. The recipient's wallet must continuously scan the blockchain, using their viewingPrivateKey to detect incoming transactions to their stealth addresses.

For developers, key technical decisions include choosing a key derivation method (like the SECP256k1 Elliptic Curve in EIP-5564), managing gas sponsorship for the recipient's claiming transaction, and implementing efficient scanning logic. Use an indexer or a service like Chainscore to monitor for stealth meta-transactions. A basic sending function in Solidity might accept a stealth address, while off-chain JavaScript code handles the stealth address generation using ethers.js and a library like @noble/curves. Always audit the integration for the key management of viewing and spending keys.

The ecosystem is rapidly evolving. Monitor adoption of EIP-5564: Stealth Addresses for a universal standard, and ERC-5568: Announcement Registry for a decentralized way to broadcast stealth address data. For scalable privacy, consider combining stealth addresses with ZK-SNARKs (e.g., Aztec) or confidential transactions. Next steps include testing on a testnet like Sepolia, exploring privacy-preserving payroll use cases, and contributing to open-source implementations. The goal is to move from transparent, reusable addresses to a default model of on-chain privacy for transactions.