Silent Payment Wallet Support: Which Wallets Support BIP 352?

BIP 352 Silent Payment Wallet Compatibility

Silent Payments (BIP 352) let Bitcoin users publish a single reusable address that generates a unique on-chain output for every payment received. Unlike standard addresses, where reusing a single address links all incoming transactions together, silent payment addresses produce no visible connection between payments on the blockchain. The tradeoff: receivers must scan every new block to detect incoming funds, which makes wallet implementation significantly more complex than traditional address types.

The BIP was merged into the bitcoin/bips repository in May 2024 and reached v1.1.0 in March 2026. Wallet adoption has been gradual because of the scanning overhead involved. The following table shows which wallets currently support sending to or receiving at sp1 addresses.

For background on how address reuse degrades privacy and why reusable addresses matter, see our address reuse risks guide and the Silent Payments deep dive.

How Silent Payments Work

A silent payment address encodes two public keys: a scan key and a spend key, both derived via BIP 32 hardened derivation at m/352'/coin_type'/account'/0'/0 (spend) and m/352'/coin_type'/account'/1'/0 (scan). The resulting address uses bech32m encoding with the sp1 prefix and contains 66 bytes of data (two compressed 33-byte public keys).

When sending, the wallet takes the sender's input private keys, performs an ECDH (Elliptic Curve Diffie-Hellman) computation against the recipient's scan public key, and derives a unique Taproot output for the payment. No two payments to the same silent payment address produce the same on-chain output, and there is no on-chain link between the silent payment address and any of its derived outputs.

The receiver must scan every eligible transaction in each new block by performing the reverse ECDH calculation using their scan private key against the summed input public keys of each transaction. This scanning cost is the primary barrier to adoption: a full node can handle it, but light clients need alternative approaches that remain an active area of research.

Wallet Implementation Details

Cake Wallet

Cake Wallet was the first wallet to ship production silent payment support, bringing the feature out of beta in v4.18.0 (May 2024) with subsequent improvements through v5.4 (September 2025). It runs on iOS, Android, Windows, Linux, and macOS. Scanning is performed entirely on-device to preserve privacy: the wallet downloads and processes blocks locally rather than delegating detection to a server.

The tradeoff is performance. Users have reported sync times exceeding an hour for roughly 3,000 blocks, with high CPU and battery usage on mobile devices. The scanning process has been known to stall, requiring users to toggle the Silent Payments option to resume. The Cake Wallet team has addressed stability issues across multiple releases, but on-device scanning remains resource-intensive by nature.

Sparrow Wallet

Sparrow takes a different architectural approach. Sending to sp1 addresses arrived in v2.3.0 (October 2025), with hardware wallet send support following in v2.4.0. Full receiving support shipped in v2.5.0 (May 2026), introducing a dedicated "Single Signature SP" Taproot-only wallet type.

Rather than scanning blocks locally, Sparrow connects to an SP-capable Electrum server that indexes silent payment tweak data. A public server at frigate.2140.dev ships with the wallet. This approach dramatically reduces bandwidth and compute on the client side. Sparrow also supports air-gapped hardware wallet signing for SP wallets, making it the most complete desktop implementation. Craig Raw, Sparrow's developer, also authored BIP 392 (silent payment output script descriptors), proposed in March 2026.

BitBox02

BitBox02 was the first hardware wallet to support silent payments, shipping send-only capability in firmware v9.21 alongside BitBox App v4.45 (the "Lugano update," October 2024). The companion app independently verifies that the BitBox02 correctly derived the silent payment output, adding an anti-klepto-style check to the signing process.

Receiving is not supported because hardware wallets cannot perform continuous block scanning. However, users can pair a BitBox02 with a software wallet like Sparrow that handles the receiving side, using the hardware device only for signing outgoing transactions.

Silentium

Silentium is a proof-of-concept progressive web app that demonstrates light client scanning for silent payments. It connects to silentiumd, an indexing server that digests blocks and serves tweak data to clients. The server never sees user keys and cannot determine which UTXOs belong to which user, preserving the privacy guarantees of BIP 352. This architecture reduces bandwidth to roughly 33 bytes of tweak data per eligible transaction output, compared to downloading full blocks.

Silentium is explicitly labeled as experimental and not recommended for significant funds. It serves primarily as a reference implementation for the light client scanning approach that wallets like Sparrow have since adopted in production.

Bitcoin Core

Despite being the reference implementation for Bitcoin Core, wallet-level silent payment support has not shipped in any release as of mid-2026. The cryptographic primitives exist in the bundled libsecp256k1 library (PR #1765 added a silentpayments module), and multiple wallet PRs are open: #28201 (sending), #32966 (receiving), and #28241 (an SP index for light wallet support). Development is tracked under issue #28536, but the PRs require rebasing and no release timeline has been announced.

Silent Payments vs BIP 47 PayNyms

Before BIP 352, BIP 47 (reusable payment codes, branded as "PayNyms" by Samourai Wallet) was the primary approach to reusable Bitcoin addresses. Both solve the same problem: allowing a receiver to publish one static identifier that generates unique addresses per payment. They take fundamentally different approaches to the interaction model.

BIP 47's notification transaction is the key weakness: it creates a visible on-chain link between sender and receiver that chain analysis can exploit. BIP 352 eliminates this leak entirely, but shifts the cost to the receiver, who must perform computationally expensive scanning. For a broader view of Bitcoin privacy techniques, see our privacy tools comparison.

Scanning Performance and Light Client Challenges

The scanning problem is the central obstacle to silent payment adoption. A receiver running a full node can scan blocks locally with acceptable performance: the ECDH computation costs roughly one elliptic curve multiplication per eligible transaction per block. But for mobile wallets and light clients, downloading and processing every block is impractical.

Existing compact block filters (BIP 157/158) do not contain the data needed for silent payment scanning. Several approaches are being explored:

• SP-capable Electrum servers index tweak data and serve it to connected wallets (Sparrow's approach)
• Dedicated indexers like silentiumd digest blocks and serve per-transaction tweak data (~33 bytes per eligible output)
• The BlindBit project maintains a light client specification for BIP 352 that defines how indexers can serve tweak data without learning which UTXOs belong to which client
• BIP 352 v1.1.0 (March 2026) introduced a per-group recipient limit of 2,323 addresses to mitigate quadratic scanning behavior in adversarial transactions

All light client approaches introduce a trust assumption: the indexer could withhold data, preventing the receiver from seeing payments. A full node remains the only way to achieve the full privacy and reliability guarantees of the protocol.

PSBT and Hardware Wallet Support

Two companion BIPs extend PSBT (Partially Signed Bitcoin Transactions) to support silent payments:

• BIP 375 (merged January 2025): defines PSBTv2 fields and role responsibilities for deriving silent payment output scripts during the signing process
• BIP 376 (proposed April 2026): specifies how to include tweak data for spending silent payment outputs, enabling hardware wallets to sign SP transactions via PSBTs

These BIPs are critical for multisig and hardware wallet workflows. Without PSBT support, constructing a silent payment transaction requires access to raw private keys, which conflicts with the security model of cold storage and air-gapped signing setups. Sparrow v2.5.0's support for air-gapped hardware wallet signers in SP wallets is a direct result of BIP 375's standardization.

Privacy Benefits and Limitations

Silent payments address the address reuse problem without requiring any interaction between sender and receiver. A recipient publishes one sp1 address (on a website, social profile, or donation page) and every sender independently derives a fresh P2TR output. No two payments are linkable on-chain, and the silent payment address itself never appears in any transaction.

However, silent payments do not protect against all common input heuristic analysis. The sender's inputs remain visible, and if the sender reuses addresses or consolidates UTXOs carelessly, the sender's side of the transaction can still be analyzed. Silent payments are most effective when combined with good coin control practices and complementary techniques like CoinJoin or PayJoin.

For a complete overview of the Bitcoin privacy landscape, see our Bitcoin privacy landscape research.

Choosing a Silent Payment Wallet

The right wallet depends on whether you need to send, receive, or both, and what tradeoffs you can accept:

• To receive silent payments on desktop with the best feature set, use Sparrow Wallet with an SP-capable Electrum server
• To receive on mobile with maximum privacy (no server trust), use Cake Wallet, accepting slower sync times and higher battery usage
• To send from a hardware wallet, use BitBox02 with the BitBox App for verified SP output derivation
• To experiment with light client scanning, try Silentium as a proof-of-concept (not for significant funds)
• To combine SP sending with CoinJoin, Wasabi Wallet supports sending to sp1 addresses alongside its privacy features

Note: Silent payment support is still maturing. Bitcoin Core has not yet shipped wallet-level support, and light client scanning remains an area of active research. Expect the ecosystem to evolve significantly over the next year.

Frequently Asked Questions

What is a Bitcoin silent payment address?

A silent payment address is a reusable Bitcoin address (prefixed sp1) defined by BIP 352. It encodes two public keys (scan and spend) that allow any sender to derive a unique Taproot output for the recipient. The recipient's address never appears on-chain, and no two payments produce the same output address, preventing address reuse without requiring the sender and receiver to interact before the payment.

Which wallets can send to silent payment addresses?

As of mid-2026, Cake Wallet, Sparrow Wallet, Nunchuk, Silentium, BitBox02 (hardware), and Wasabi Wallet all support sending to sp1 addresses. Sending is significantly easier to implement than receiving because it requires only a single ECDH computation per transaction, with no ongoing scanning.

Why is receiving silent payments so resource-intensive?

To detect incoming silent payments, the receiver must perform an elliptic curve Diffie-Hellman computation against every eligible transaction in every new block. Unlike traditional addresses where a wallet can check a simple filter, silent payment detection requires cryptographic work proportional to the number of transactions on the network. This is why full node scanning, SP-capable servers, or dedicated indexers are necessary.

How do silent payments compare to BIP 47 payment codes?

Both solve the reusable address problem, but BIP 47 requires a visible notification transaction before the first payment, which creates an on-chain link between sender and receiver. BIP 352 eliminates this notification entirely, providing stronger privacy at the cost of higher receiver-side computation. BIP 47 adoption has also stalled following the Samourai Wallet shutdown in 2024.

Can I use silent payments with a hardware wallet?

For sending: yes. BitBox02 supports sending to sp1 addresses, and Sparrow Wallet supports air-gapped hardware wallet signing for SP transactions via PSBTv2 (BIP 375). For receiving: hardware wallets cannot perform continuous block scanning, so they cannot detect incoming silent payments on their own. You would pair a hardware signer with a software wallet like Sparrow that handles scanning.

Does Bitcoin Core support silent payments?

Not yet. The cryptographic primitives exist in Bitcoin Core's bundled libsecp256k1 library, and multiple wallet PRs are open (for sending, receiving, and an SP index). However, none have been merged into a release as of mid-2026. Development is tracked under GitHub issue #28536.

Are silent payments compatible with Lightning Network?

Silent payments operate at the on-chain layer and are not directly usable for Lightning channel funding or invoice payments. However, a silent payment address could be used to receive on-chain funds that are then moved into a Lightning channel or onto a layer-2 network like Spark for fast, low-cost transfers.

This tool is for informational purposes only and does not constitute financial advice. Wallet support data is based on publicly available release notes and documentation as of mid-2026. Implementation status changes frequently: always verify current support directly with wallet developers before relying on any specific feature.