Silent Payments vs Stealth Addresses: Privacy Compared

Bitcoin Silent Payments vs Stealth Addresses

Both Silent Payments (BIP-352) and stealth addresses (ERC-5564) solve the same problem: letting a recipient publish a single static address while every incoming payment lands on a fresh, unlinkable on-chain address. The cryptographic core is identical: Elliptic Curve Diffie-Hellman (ECDH) between sender and recipient keys. The protocols diverge in how the sender signals the payment, how the recipient detects it, and what on-chain footprint the payment leaves behind.

This comparison covers the two current production-ready standards: Bitcoin's BIP-352 (finalized May 2024, latest revision v1.1.0 in March 2026) and Ethereum's ERC-5564 (Final status, paired with ERC-6538 for meta-address registration). It also references Bitcoin's earlier BIP-47 payment codes to show how the design has evolved.

How Key Derivation Works

Both protocols use ECDH to produce a shared secret that only sender and recipient can compute. The differences lie in what keys feed the derivation and what the output looks like on-chain.

BIP-352: Input-Anchored Derivation

A silent payment address encodes two compressed public keys: a scan key (B_scan) and a spend key (B_spend). The sender sums their input private keys, multiplies by an outpoint hash for uniqueness, and performs ECDH against B_scan. The resulting shared secret tweaks B_spend to produce a fresh P2TR output address. For multiple outputs to the same recipient, a counter k is mixed into the hash, producing distinct addresses per output.

Because the derivation uses the sender's actual input keys rather than a separate ephemeral key, no additional data needs to be published on-chain. The resulting output is indistinguishable from any other Taproot output. A third party cannot determine that a silent payment was used, or link the output back to the recipient's sp1 address.

ERC-5564: Ephemeral Key with Announcer

Ethereum stealth addresses use a different structure. The recipient publishes a stealth meta-address containing a spending public key and a viewing public key. The sender generates a fresh ephemeral keypair, performs ECDH with the recipient's viewing key, and derives a one-time address. Funds are sent directly to that address.

The sender must then call a singleton announcer contract (deployed at a deterministic address across all EVM chains) to emit an Announcement event containing the ephemeral public key, the stealth address, and metadata. Without this announcement, the recipient has no efficient way to find the payment. The first byte of the metadata is a view tag: a one-byte filter that lets recipients discard roughly 255/256 of irrelevant announcements before performing the expensive elliptic curve check.

Notification and Detection

The notification mechanism is the most consequential design difference between the two protocols. It determines scanning cost, privacy properties, and mobile wallet feasibility.

BIP-352 requires no notification at all. The payment is a standard Taproot transaction. The tradeoff: the recipient must scan every eligible transaction in every block to check for matches. This involves one ECDH computation per unique input key set per block, which scales with network transaction volume rather than with the number of payments the recipient actually receives.

ERC-5564 uses a dedicated contract that emits structured events. This gives recipients a narrow event stream to monitor instead of scanning the entire chain. View tags make the scan even cheaper: the recipient computes a partial hash and compares only one byte before proceeding to the full ECDH check. The cost is an extra on-chain transaction (and gas fee) for the sender each time they make a payment.

BIP-47 took a third approach: a one-time notification transaction that permanently linked sender and recipient payment codes on-chain. This solved detection but created a privacy leak. Silent Payments eliminated that leak entirely, at the cost of pushing detection burden onto the receiver.

Scanning Performance and Mobile Challenges

Scanning cost is the primary obstacle to broad silent payment adoption. A full node running Bitcoin Core can scan blocks as they arrive, but mobile wallets face hard constraints: limited CPU, restricted background execution (particularly on iOS), and bandwidth caps.

Current estimates put the scanning data requirement for BIP-352 at roughly 7 to 12 kilobytes per block, or approximately 30 to 50 megabytes per month. Catching up after weeks offline can require processing gigabytes of tweak data. One measurement across 255,434 blocks found total scanning data exceeding 15 GB for the complete dataset.

Several approaches have emerged to address this challenge:

• On-device scanning (used by Cake Wallet): processes full block data locally, preserving maximum privacy but consuming significant battery and bandwidth
• Server-assisted scanning (used by Nunchuk): offloads ECDH computation to a trusted server, drastically reducing client-side cost but requiring trust in the indexing service
• Cut-through indexing (Sparrow's Frigate server): a specialized Electrum-compatible server that precomputes tweaks using GPU acceleration, reportedly reducing months of catch-up scanning to under a second
• Chained commitments: a proposed verification mechanism where servers commit to each block's canonical tweak set, allowing clients to cross-check multiple servers for data completeness

Ethereum's ERC-5564 has a lighter scanning profile by design. The recipient monitors a single contract's event log rather than parsing raw blocks. The view tag pre-filter means only about 1 in 256 announcements require a full ECDH check. Mobile wallets can use standard event subscription APIs and catch up from any Ethereum node or RPC endpoint. The tradeoff is that every payment requires a separate announcement transaction, adding gas cost for the sender and creating a detectable on-chain pattern (calls to the known announcer contract address).

Wallet Support and Implementation Status

BIP-352 wallet support has grown steadily since the specification was finalized in May 2024. Sparrow Wallet added sending in v2.3.0 (October 2025) and receiving in v2.5.0 (May 2026), including support for air-gapped hardware signers. Cake Wallet shipped both sending and receiving in v4.18.0 (May 2024), using on-device scanning. Nunchuk added support with server-assisted scanning in early 2026. BlueWallet supports receiving on iOS and Android.

Bitcoin Core contains the cryptographic primitives in its bundled libsecp256k1 library (the silentpayments module), but wallet-level support has not shipped in any release as of mid-2026. Receiving support remains in a draft pull request. Related specifications BIP-374 (DLEQ proof format) and BIP-375 (PSBT integration) were merged in 2025 to enable hardware wallet compatibility.

On the Ethereum side, Umbra Cash is the most established stealth address implementation, having processed over 270,000 payments across Ethereum, Polygon, Optimism, and Arbitrum. Umbra predates ERC-5564 and uses a slightly different derivation mechanism than the standard specifies. Fluidkey and Railgun are other implementations in the ecosystem. Adoption remains niche: a 2023 academic study found that behavioral heuristics could deanonymize 48% of Umbra payments on Ethereum mainnet, highlighting that protocol-level privacy guarantees are only as strong as user practices.

For a detailed breakdown of which Bitcoin wallets support BIP-352, see our silent payment wallet comparison. For broader Bitcoin privacy tooling, see the privacy tools comparison.

Privacy Properties Compared

Both protocols provide recipient unlinkability: an observer cannot connect a payment to the recipient's published address. But the strength of that guarantee differs in practice.

BIP-352 has a structural advantage: silent payment outputs are standard Taproot outputs. There is no on-chain marker, no contract call, and no metadata field that reveals the protocol was used. The anonymity set is every Taproot transaction on Bitcoin, which grows with each block.

ERC-5564 leaves a detectable trace: the call to the announcer contract. While the stealth address itself is unlinkable, the announcement transaction reveals that a stealth payment occurred. An observer can enumerate all stealth payments by watching the announcer contract. The sender's address is also visible in the announcement call, so sender privacy depends on how the sender funded their wallet.

Both protocols share a common weakness: funding the stealth address. On Ethereum, the recipient needs ETH to pay gas when spending from the stealth address, which can re-link the address if the gas comes from a known source. Solutions like paymasters and account abstraction ( EIP-7702) can mitigate this. On Bitcoin, the recipient spends the UTXO directly, so there is no separate gas-funding step, but spending multiple silent payment UTXOs in the same transaction can allow common-input heuristic analysis.

When to Use Each Approach

Choose BIP-352 silent payments when maximum on-chain privacy matters more than mobile scanning convenience. Silent payments are best suited for: donation addresses, long-term savings addresses published on websites, and any use case where the recipient runs a full node or uses a trusted indexing service. The protocol is native to Bitcoin and requires no smart contract infrastructure.

Choose ERC-5564 stealth addresses when operating in the Ethereum ecosystem and mobile/light-client detection is a priority. The announcer contract pattern makes scanning cheaper and more accessible. The tradeoff is the visible announcement footprint and the gas overhead per payment.

For Bitcoin users who want privacy without the scanning burden, layer-2 solutions offer an alternative path. Spark enables private transfers on a Bitcoin layer 2 with built-in address rotation, avoiding the scanning problem entirely by operating off-chain. For more on how Spark's privacy model compares to on-chain approaches, see our deep dive on silent payments and Bitcoin privacy.

Frequently Asked Questions

What is the difference between silent payments and stealth addresses?

Silent payments (BIP-352) and stealth addresses (ERC-5564) both use ECDH to derive one-time addresses from a static recipient identifier. The key difference is notification: BIP-352 embeds the derivation in the sender's existing transaction inputs, leaving no on-chain trace. ERC-5564 requires the sender to call a dedicated announcer contract, which emits an event that recipients can efficiently filter. Silent payments offer stronger on-chain privacy; ERC-5564 offers easier recipient scanning.

Do silent payments require a notification transaction?

No. Unlike BIP-47 payment codes, which required a separate on-chain notification transaction, BIP-352 silent payments need no notification. The sender derives the recipient's address using their own transaction input keys and the recipient's published scan key. The payment is a standard P2TR output with no extra data.

Which wallets support Bitcoin Silent Payments?

As of mid-2026, Sparrow Wallet supports both sending and receiving (including air-gapped hardware signers). Cake Wallet supports sending and receiving with on-device scanning. Nunchuk and BlueWallet also support receiving. Bitcoin Core has the cryptographic primitives but has not shipped wallet-level support in a release. For current support status, see our silent payment wallet comparison.

Can silent payments work on mobile phones?

Yes, but with tradeoffs. On-device scanning (as Cake Wallet implements) consumes significant battery and bandwidth because the wallet must process every eligible transaction in each block. Server-assisted scanning reduces client-side cost but requires trusting the indexer to return complete data. Cut-through indexing services like Sparrow's Frigate server precompute tweak data using GPU acceleration, reducing catch-up time from hours to seconds. The BIP-352 light-client appendix remains open research.

What is a view tag in ERC-5564?

A view tag is the first byte of the metadata in an ERC-5564 announcement event. It acts as a cheap pre-filter: the recipient computes a partial hash from the ephemeral public key and their viewing key, then compares just this one byte. Since there are 256 possible values, roughly 255 out of 256 non-matching announcements are discarded before the recipient performs the full elliptic curve computation. This reduces scanning cost significantly at a negligible privacy cost.

Are silent payment outputs distinguishable from normal Bitcoin transactions?

No. BIP-352 outputs are standard Taproot (P2TR) outputs. There is no OP_RETURN, no special script structure, and no metadata that reveals the protocol was used. An outside observer sees an ordinary Taproot payment. This is a significant privacy advantage over ERC-5564, where the announcer contract call is publicly visible, and over BIP-47, where notification transactions are identifiable.

What is the scanning bandwidth for Bitcoin Silent Payments?

Current estimates put the scanning data requirement at 7 to 12 kilobytes per block, or roughly 30 to 50 megabytes per month for ongoing scanning. Catching up after extended offline periods is more expensive: one measurement across 255,434 blocks found the complete scanning feed exceeding 15 GB. Server-assisted approaches and cut-through indexing reduce this burden substantially for individual wallets.

This tool is for informational purposes only and does not constitute financial advice. Protocol specifications, wallet support, and implementation status change frequently. Scanning bandwidth figures are approximate and based on measurements available as of mid-2026. Always verify current wallet compatibility and protocol details before relying on these privacy techniques for real funds.