Silent Payments in 2026: Which Wallets Support BIP-352 and What's Left

BIP-352 silent payments promised a static, reusable Bitcoin address that generates a fresh on-chain output for every incoming payment: no interaction, no notification transaction, no address reuse. The specification was finalized in May 2024 and has since reached version 1.1.0 (March 2026). Two years in, wallet adoption tells a split story: sending to an sp1q address is broadly supported, but privately receiving silent payments remains hard, especially on mobile. This article surveys which wallets support BIP-352 today, where the scanning bottleneck stands, and what still needs to happen before silent payments become a practical default.

Why Silent Payments Matter for Bitcoin Privacy

The core problem is address reuse. When a donation page, tip jar, or merchant checkout displays the same Bitcoin address to every payer, chain analysis firms can trivially link every incoming payment and map wallet balances. The standard fix (generate a new address per payment) requires the receiver to be online or run a server. Silent payments eliminate that requirement entirely, letting the sender derive a unique Taproot output from the receiver's static public keys using ECDH.

For a full technical walkthrough of how the protocol works, see our deep dive on silent payments. This article focuses on the adoption side: who has shipped what, and what remains unresolved.

Which Wallets Support Sending to Silent Payments?

Sending is the easier side. A wallet only needs to recognize an sp1q address, extract the receiver's scan and spend public keys, compute the ECDH shared secret from its own input keys, and construct a standard Taproot output. No scanning, no new infrastructure, no server dependency.

As of late 2026, several wallets can send to silent payment addresses:

• Cake Wallet: first mobile wallet to ship production silent payment support, with improvements through v5.4 (September 2025)
• Sparrow Wallet: desktop support with BIP 375 PSBT fields for hardware wallet compatibility
• BlueWallet: send-only support on mobile
• Nunchuk: sending support with multisig coordination
• Wasabi Wallet: integrated into its CoinJoin workflow
• BitBox02: first hardware wallet to sign silent payment transactions (firmware v9.21, October 2024)

The sender asymmetry: Sending a silent payment requires nothing beyond a standard wallet update. The computational cost is negligible: one ECDH derivation per payment. This is why send support has spread quickly while receive support lags behind.

Which Wallets Support Receiving Silent Payments?

Receiving is where the difficulty lives. A silent payment receiver cannot look up a list of known addresses against block data. Instead, the wallet must perform an elliptic-curve multiplication for every eligible transaction in every block: any transaction with at least one Taproot output and an eligible input type (P2TR, P2WPKH, P2SH-P2WPKH, or P2PKH). This scanning requirement fundamentally changes the wallet architecture.

The pattern is clear: most wallets that support silent payments can only send. Full receive support exists in only a handful of wallets, and each one handles the scanning problem differently. Cake Wallet scans on the device itself, which works but makes initial synchronization slow. Sparrow delegates scanning to a server (Frigate, an Electrum server extension with silent payment indexing), which shifts the trust model. Silentium uses the BlindBit Oracle indexer but remains experimental.

The Scanning Problem: Why Receiving Is Hard

The computational burden of silent payment scanning is the single largest barrier to adoption. Unlike a standard HD wallet that derives a batch of addresses at setup and simply checks for matches, a silent payment wallet must compute a fresh ECDH shared secret for every eligible transaction it encounters.

Full Node Scanning

On a full node, scanning the chain from genesis currently takes roughly 8 to 12 hours on reference hardware. Wallet birthday optimization helps: users recovering an existing wallet only need to scan blocks after their wallet creation date. For ongoing use (scanning new blocks as they arrive), the overhead is manageable. The secp256k1 silentpayments module (merged via PR #1765) implements full-node scanning with optimized batch verification.

Light Client Scanning

For light clients, the problem is worse. A light wallet lacks the full block data and needs another source for the 33-byte tweaked input public key per eligible transaction. The BIP's own estimates put this at 7 to 12 kilobytes per block, or roughly 30 to 50 megabytes per month (based on 2024 Taproot adoption rates). As Taproot adoption grows, these numbers rise with it.

The deeper problem is not bandwidth but trust. If a mobile wallet fetches tweak data from a third-party server, that server could selectively omit transactions, hiding payments from the receiver. The BIP itself calls light client support "an area of open research."

The scan key tradeoff: BIP-352 separates the scan key (which detects payments) from the spend key (which authorizes spending). A receiver can delegate scanning to a server by sharing only the scan key: the server detects payments but cannot steal funds. The cost is that the server learns which transactions belong to the user, degrading privacy to roughly the level of an Electrum server.

Proposed Solutions for Light Client Scanning

Several approaches aim to make silent payment scanning viable without running a full node.

Transaction Cut-Through

Cut-through lets clients skip historical transactions where all Taproot outputs have already been spent. Empirical data shows approximately 75% of eligible transactions have their non-dust Taproot outputs fully spent within 150 blocks. For a wallet scanning from its birthday rather than genesis, cut-through dramatically reduces the working set: the client only needs tweak data for transactions with unspent outputs.

BlindBit Oracle

The BlindBit project maintains a light client specification where indexers serve tweak data without learning which UTXOs belong to which client. The architecture uses a Go-based indexing server (BlindBit Oracle) that processes blocks and serves the minimal data a light client needs to perform its own ECDH checks. Clients include BlindBit Desktop, Dana Wallet, and BDK with Kyoto. The protocol is still pre-draft (v0.1 as of the latest published specification).

BIP 158 Compact Block Filters

A hybrid approach combines silent payment scanning with BIP 158 compact block filters. The client computes candidate output scriptPubKeys from tweak data, checks them against the filter, and downloads the full block only on a match. This minimizes bandwidth but still requires someone to serve tweak data: the trust problem remains.

Bitcoin Core Index

An open Bitcoin Core PR #28241 proposes a dedicated silent payments index that a Core node could serve to connected light wallets. If merged, this would provide a production-grade, self-hostable data source for mobile wallets: the same trust model as running your own Electrum server, but built into Core itself.

BIP-352 v1.1.0: Addressing Adversarial Scanning Cost

The March 2026 revision introduced a per-group recipient limit (K_max) to mitigate a quadratic scanning cost attack. In earlier versions, an adversary could craft a transaction paying many silent payment recipients, forcing each recipient's wallet to perform O(n) ECDH computations where n is the number of Taproot outputs. With many such transactions, the total cost became quadratic.

The K_max limit caps the number of silent payment outputs a wallet will attempt to detect per transaction per input group, bounding the worst-case scanning cost. Wallets implementing v1.1.0 can reject adversarial transactions early, before completing the expensive ECDH loop.

Silent Payments vs. Ethereum Stealth Addresses

Ethereum's ERC-5564 defines a stealth address scheme with the same cryptographic foundation (ECDH between sender and recipient). The implementations diverge significantly in notification, scanning, and address handling.

Ethereum's event-based model makes scanning cheaper for light clients: the announcer contract's events are indexable through standard RPC calls, and view tags let wallets eliminate 255 out of 256 candidates without a full ECDH computation. Bitcoin's model avoids any on-chain notification, which is better for privacy but harder for implementation.

The UX Gap: From Address to Received Funds

Even where wallets technically support silent payments, the user experience gap between generating an sp1q address and actually seeing received funds is significant.

Address Length

A silent payment address encodes 66 bytes of payload (two compressed public keys plus a version byte), resulting in approximately 117 characters after Bech32m encoding. For comparison, a standard Taproot address is 62 characters. This makes silent payment addresses impractical to copy manually and pushes adoption toward QR codes and clipboard sharing. The combination with BIP 353 (DNS-based payment instructions) could help: users would share a human-readable name that resolves to the full sp1q address via DNSSEC.

Sync Delays

A wallet scanning on-device (like Cake Wallet) may take minutes to hours for initial synchronization, depending on how far back the wallet birthday is. New blocks arrive every 10 minutes on average, and each must be scanned before the wallet reflects new incoming payments. For users expecting the instant feedback of a regular Bitcoin wallet, this delay is jarring.

Wallet Recovery

Recovering a silent payment wallet from a seed phrase requires rescanning the chain from the wallet birthday. Unlike standard derivation-path recovery with gap limit detection, there is no shortcut: every eligible transaction must be checked. This means recovery time scales with how long the wallet has existed and how many Taproot transactions have occurred since then.

Hardware Wallet Integration

Hardware wallets like the BitBox02 can sign silent payment transactions (sending), but the scanning problem prevents them from handling receiving independently. The BIP 375 PSBT specification helps by defining how software wallets coordinate with hardware signing devices, including DLEQ proof fields that verify each signer computed their ECDH share honestly. But receiving still requires a software component that performs the scanning.

Bitcoin Core: The Missing Piece

Bitcoin Core's built-in wallet does not yet support silent payments in any released version. The cryptographic foundation is in place: the secp256k1 silentpayments module has been merged (limited to full-node scanning). Wallet-level integration is tracked across several open PRs:

• #28122: core BIP-352 primitives
• #28201: wallet sending support
• #32966: wallet receiving with GUI
• #28241: silent payments index for light wallet support

Bitcoin Core's eventual support matters disproportionately. As the reference implementation, its adoption signals that silent payments are a first-class feature rather than a niche experiment. A Core node running the silent payments index could also serve as infrastructure for mobile wallets: a self-hostable, trustworthy source of tweak data.

Formal Security Analysis

A 2026 IACR paper provides the first formal security analysis of BIP-352. The authors note that the deployed specification shipped in major wallets without a formal security proof, and that 2026 has brought several disclosures: a worst-case scanning cost attack (addressed by v1.1.0's K_max limit), a hardware wallet funds-locking vulnerability, and an omitted-payment bug affecting light clients relying on third-party tweak data. The paper covers unlinkability, CoinJoin compatibility, and the label system, but notes that light client scanning remains formally unanalyzed.

Privacy Beyond On-Chain: Off-Chain Alternatives

Silent payments address a problem specific to on-chain Bitcoin: how to receive payments to a static identifier without creating linkable UTXO outputs. The scanning cost is inherent to this approach, because the receiver must check every transaction to find theirs.

Off-chain protocols sidestep this problem entirely. Spark transfers update the cryptographic key that authorizes spending an existing on-chain UTXO, without creating new outputs or broadcasting transactions. There is no address to reuse because transfers happen through the operator network's FROST threshold signing process. The two approaches are complementary: silent payments improve on-chain privacy for scenarios that require base-layer settlement (large values, long-term cold storage), while Layer 2 transfers avoid the scanning problem by keeping payments off-chain.

For a broader view of how silent payments fit alongside PayJoin, CoinJoin, and Layer 2 privacy, see the 2026 Bitcoin privacy landscape overview.

What Needs to Happen Next

Silent payments have a complete specification, a growing sender ecosystem, and early receiver implementations. But several things need to converge before they become a practical default for privacy-conscious Bitcoin users:

• Bitcoin Core wallet support needs to ship, both for direct use and as infrastructure for light wallets
• A production-ready light client protocol must be standardized, not just proposed
• More hardware wallets need to support PSBT-based silent payment signing (currently only BitBox02)
• BIP 353 DNS-based address resolution needs adoption to mitigate the long address problem
• The anonymity set must grow: the more wallets that send and receive silent payments, the harder it becomes for observers to identify which Taproot outputs are silent payments versus regular transactions

The protocol is sound. The tooling is catching up. The question is whether scanning costs and UX friction slow adoption enough for the privacy window to close before silent payments reach critical mass.

If you're building a wallet that needs private Bitcoin receiving today, explore the Spark SDK for off-chain transfers with inherent privacy and no scanning overhead, or try General Bread to see how a Spark-powered wallet handles private payments in practice. For a deeper comparison of on-chain privacy tools, see the silent payment wallet comparison tool.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.