Stealth Addresses

Enable unlinkable transfers on a transparent chain by deriving a one-time destination address per transaction using a Diffie-Hellman shared secret between sender and receiver keys. Observers see a transfer to a fresh address; only the recipient can detect and spend the funds.

Works best when

  • Sender and receiver want to hide the link between their public identities on a transparent chain.
  • Counterparty unlinkability matters more than amount confidentiality.
  • Wallets or directory services can publish and manage view-key material for recipients.

Avoid when

  • Strong amount confidentiality is required; use a shielded pool or confidential token instead.
  • The deployment requires scoped regulator access by default; stealth addresses only support voluntary disclosure.

I2I vs I2U — context differences

Institution to institution

I2I

Between institutions, recipients can maintain directory entries that publish view keys. Disclosure to regulators happens by the recipient voluntarily sharing the private view key for a time window or a specific stealth address.

Institution to end user

I2U

For end users, self-relaying from the stealth address is necessary to preserve unlinkability; otherwise the gas-paying address re-links the stealth address to a known identity. CR drops to low when relayers are mandatory and centralised, which is often the case before account-abstraction paymasters are routinely available.

Post-quantum exposure

Risk · high
Vector
Elliptic-curve Diffie-Hellman underpins the shared-secret derivation and is broken by a CRQC. HNDL risk is acute: address linkages recorded now are retroactively compromised once a quantum adversary can recover view keys.
Mitigation
Post-quantum key-encapsulation such as ML-KEM for the shared-secret step, combined with oblivious message retrieval as an off-chain scanning aid. See Post-Quantum Threats.

Components

  • Stealth keypair held by the recipient: a view key used to scan the chain and a spend key used to control funds.
  • Ephemeral sender key generated per transaction; combined with the recipient view key to produce a shared secret.
  • Derivation function that converts the shared secret into a stealth address and an optional view tag for fast scanning.
  • Optional registry or directory that publishes recipient view keys so senders can discover them.
  • Wallet or account-abstraction stack that can fund and operate the stealth address without re-linking it to the recipient's primary address.

Protocol

  1. user The recipient publishes a public view key via a directory or shares it with the sender directly.
  2. user The sender generates an ephemeral key and computes the Diffie-Hellman shared secret with the recipient view key.
  3. user The sender derives the one-time stealth address from the shared secret and transfers tokens to it.
  4. user The recipient scans new transactions using the private view key and detects transfers destined to their stealth addresses.
  5. user The recipient uses the spend key to authorise spending from the stealth address when needed.
  6. auditor The recipient can optionally share the private view key with an auditor for a specific scope or time window.

Guarantees & threat model

Guarantees:

  • On-chain observers do not see a direct link between sender and recipient identities.
  • The recipient can scan and spend without the sender needing further interaction.
  • Retrospective disclosure is possible by voluntarily sharing the view key with a specific auditor.

Threat model:

  • The hardness of elliptic-curve Diffie-Hellman; key compromise reveals all past and future stealth addresses derived from the same view key.
  • Wallet implementation correctness in handling view and spend keys and in funding the stealth address without re-linking it.
  • Metadata at the network layer (RPC provider logs, relayer identity, IP addresses) and repeated address reuse by the recipient are out of scope.
  • Amount and token type are visible on-chain by design.

Trade-offs

  • Amount leakage: transfer values remain visible and can expose competitive information.
  • Scanning cost: recipients must scan all transactions, or use view tags and prefiltering to reduce load.
  • Funding the stealth address to cover gas can re-link the stealth address to a known source unless account abstraction or dedicated gas-payer flows are in place.
  • Interoperability depends on EIP-5564 adoption across wallets and on registry availability.
  • Regulator workflows require voluntary view-key sharing; there is no scoped access path by default.

Example

An institution owes a counterparty tokenised stablecoin. The recipient publishes a public view key in its directory entry. The sender derives a stealth address using the shared secret and transfers the stablecoin to that address. On-chain, the transfer looks like a payment to a fresh address. The recipient's wallet detects the funds via the private view key, then moves them to a custodian wallet. For audit, the recipient can later disclose the view key to a regulator for the relevant window.

See also

Open-source implementations