Silent Payments (BIP-352) Wallet Support: Who Can Send & Privately Receive in 2026
Silent Payments (BIP-352) fix one of Bitcoin’s oldest privacy leaks: address reuse. You publish a single static address that starts with sp1, and every payer derives a unique, unlinkable on-chain address for you without any interaction — no fresh address to hand out, nothing tying your payments together on-chain. It’s a genuine leap. But there’s an asymmetry that catches people out: sending to an sp1 address is easy and widely supported, while privately receiving is hard, rare, and where all the interesting engineering (and the privacy trade-offs) live. This matrix separates the two honestly across 18 wallets and libraries.
Quick answer
Silent Payments (BIP-352) give you one reusable address (sp1...) that anyone can pay without reusing an address or asking you for a fresh one — a real privacy win. But there's an asymmetry that trips people up: SENDING to an sp1 address is easy and widely supported (Sparrow, Cake, BlueWallet, Wasabi, Nunchuk, even BitBox02 as a signer), while privately RECEIVING is hard and rare. Receiving means scanning every eligible taproot output in every block to find the ones meant for you — trivial for a full node, prohibitive for a phone — so mobile wallets fetch tweak data from an indexing server that, while it never learns which coins are yours, does see your IP and queries. As of mid-2026 the honest answer is: Sparrow on desktop (pointed at your own server) is the only setup with real send-and-private-receive, Cake and Nunchuk work on mobile via their operators' indexers, and Bitcoin Core still ships nothing.
Send is solved; receive is the frontier. If you want to actually RECEIVE Silent Payments privately today, run Sparrow 2.5.0+ against your own SP-capable Electrum server, or self-host a BlindBit oracle for a mobile client — otherwise you are trusting a third party with your IP and query pattern (never with your keys or which coins are yours). Do not put meaningful funds in the proof-of-concept wallets.
yes supported partial library/experimental no not supported · receive privacy hinges on the scan method column
| Wallet / library | Type | Send | Receive | Scan method (receive) | Since |
|---|---|---|---|---|---|
| Cake Wallet | mobile | yes | yes | third-party indexer (Cake default)Client-side derivation, but the default Cake-run Electrum servers see your IP and query pattern | send + receive since 2024 (first major mobile SP wallet) |
| Receive is a catch-up scan from wallet birth height. A documented edge case (issue #2395) can miss funds — verify received SP funds carefully. (A) | |||||
| Nunchuk | mobile | yes | yes | third-party indexer (Nunchuk default)Receive relies on a specialized SP-index server, Nunchuk-operated by default; self-host option unverified | 2026 (send + receive) |
| One of the few multisig-oriented wallets with SP receive; public implementation detail is thinner than Sparrow's. (B) | |||||
| Silentium | mobile | yes | yes | third-party indexer (silentiumd)PWA light client backed by silentiumd; the server serves tweak data and never learns which UTXOs are yours, but sees block-level queries | 2024 proof of concept |
| 🔴 Explicitly a proof-of-concept reference, 'use at your own risk' — NOT for meaningful funds. (A) | |||||
| sp-client | library | yes | yes | third-party indexer (BlindBit-style)Wallet-layer Rust lib designed around tweak-oracle backends; privacy depends on the oracle you point it at | 2024 (cygnet3) |
| Handles incoming-tx parsing, owned-output management and signing; powers Dana Wallet. (A) | |||||
| Sparrow Wallet | desktop | yes | yes | third-party indexer (self-hostable)Receive needs an SP-capable Electrum server serving per-block tweak data; detection runs client-side, but the server sees your IP/queries unless you run your own or use Tor | send v2.3.0 (Oct 2025); receive v2.5.0 (May 2026, incl. air-gapped signer) |
| The most complete mainstream implementation as of mid-2026. Pair with your OWN SP-capable server for best privacy — the recommended setup. (A) | |||||
| Dana Wallet | mobile | partial | yes | third-party indexer (BlindBit oracle)BlindBit Oracle backend serves tweak data per the BIP-352 light-client spec; server learns block-level queries but not which outputs are yours | v0.1.0-alpha (2024, built on sp-client) |
| Purpose-built for RECEIVING donations (receive is the point). General spend features limited; still experimental. (B) | |||||
| BlindBit | library | no | yes | IS the indexer (self-hostable, Go)BlindBit Oracle serves per-block tweak data + BIP158-style filters per the light-client spec so clients detect payments locally without revealing which UTXOs are theirs | 2024 (setavenger) |
| The reference architecture for SP light clients. Self-hostable — the way to get private mobile receive. (A) | |||||
| go-bip352 | library | yes | partial | n/aCrypto/derivation library; scanning infra lives in the companion BlindBit Oracle project | 2024 (setavenger) |
| The Go BIP-352 implementation underpinning BlindBit. (B) | |||||
| python-bip352 (reference) | library | yes | partial | n/aReference crypto only; no chain-scanning infrastructure | shipped with the BIP (bip-0352/reference.py, 2024) |
| The canonical Python code is the in-repo reference implementation with test vectors; a separately packaged 'python-bip352' is unverified. (B) | |||||
| rust-silentpayments | library | yes | partial | n/aProvides send and receive/scan cryptography; chain access and scan strategy are the integrator's problem | active 2023-2024 (crates.io: silentpayments) |
| The de facto Rust BIP-352 crypto crate; basis for sp-client and bdk-sp. (A) | |||||
| BitBox02 | hardware | yes | no | n/aSigning device only — cannot scan; verifies SP send outputs on-device | unverified firmware version |
| Hardware wallets can only ever do the send side (BIP-375 PSBT fields) or act as an air-gapped signer for a host wallet that scans (Sparrow 2.5.0 supports this). (C) | |||||
| BlueWallet | mobile | yes | no | n/aNo receive scanning shipped, so no scan-privacy question arises | send in v6.6.8 (with full BIP-47) |
| Maintains its own TypeScript SP library with receive code, but the app has receive only as an open feature request (issue #7432). (A) | |||||
| Wasabi Wallet | desktop | yes | no | n/aSend-only; docs state Wasabi cannot generate an SP address or recognize payments to one | send in v2.4.0 |
| Community-maintained since the zkSNACKs coordinator shutdown; receive announced as planned but not shipped as of mid-2026. (A) | |||||
| Bitcoin Core | node | no | no | n/aWould be the gold standard — full-node local scanning, zero leak — once merged. Nothing shipped yet | not shipped (libsecp256k1 SP module merged; wallet PRs #28201 send / #32966 receive / #28241 index all OPEN) |
| 🔴 No released Core version has SP wallet support. The zero-leak full-node receive option does not exist in any shipped general wallet yet. (A) | |||||
| Breez | mobile | no | no | n/a | n/a |
| Lightning/Liquid (Nodeless SDK); no BIP-352 support found. (B) | |||||
| Electrum | desktop | no | no | n/a | n/a |
| Send support is still an open feature request (issue #8847); no SP in any release. (B) | |||||
| Phoenix | mobile | no | no | n/a | n/a |
| Lightning wallet (ACINQ); no on-chain SP support announced. (B) | |||||
| Zeus | mobile | no | no | n/a | n/a |
| Lightning-focused (embedded LND); no BIP-352 support found as of mid-2026. (B) | |||||
Why receiving is the hard part. A receiver cannot recognize their own payments by watching addresses — each incoming output is a fresh P2TR script derived via ECDH between the sender's input keys and the receiver's scan key, so detection requires computing a tweak for essentially every eligible taproot transaction in every block. That is trivial for a full node with an index but prohibitive for a phone, so light clients fetch precomputed per-block tweak data (~100 kB/block) from an indexing server (BlindBit Oracle, silentiumd, an SP-capable Electrum server) and often combine it with BIP158 filters. The final ownership check stays client-side. The crux: the tweak server never learns which outputs are yours, but it DOES see your IP and query pattern — so the practical privacy question for every mobile SP wallet is who runs the indexer and whether you can self-host it.
BIP-352 status. BIP-352 was merged into the bitcoin/bips repo in May 2024 (authors Josie Baker and Ruben Somsen) and is stable, with a minor spec revision (~v1.1.0) in March 2026. The libsecp256k1 bundled with Bitcoin Core has a merged silentpayments module, but no RELEASED Core version ships SP wallet functionality — the wallet-level PRs remain open. Adoption is asymmetric: many wallets can SEND to an sp1 address; full private RECEIVE is limited to Sparrow, Cake, Nunchuk and the experimental SP-native wallets.
Open data (CC BY 4.0): CSV · JSON · API: /wp-json/dc/v1/silent-payments
Send is solved; receive is the frontier
A receiver can’t just watch an address for incoming payments — with Silent Payments, each payment lands on a fresh Taproot output derived from a shared secret between your keys and the sender’s, so finding your own money means checking essentially every eligible Taproot output in every block. A full node with an index shrugs at this; a phone can’t. So light wallets download precomputed “tweak” data (roughly 100 kB per block) from an indexing server and do the final ownership math locally. The server never learns which coins are yours — but it does see your IP address and query pattern. That’s the whole privacy question for mobile Silent Payments in one sentence: who runs your indexer, and can you self-host it? On desktop, Sparrow lets you point at your own server or reach a public one over Tor; on mobile, Cake and Nunchuk work today but through their operators’ indexers by default. Bitcoin Core, which would give zero-leak full-node receiving, still ships nothing — the wallet PRs are open but unreleased.
What to actually use
For a privacy-first user in 2026 the honest recommendation is Sparrow 2.5.0+ on desktop, pointed at your own SP-capable Electrum server — real send and receive, with nothing about your scanning leaking to anyone. On mobile, Cake Wallet and Nunchuk give working send-and-receive if you accept the default-indexer exposure or self-host a BlindBit oracle, and Dana Wallet is purpose-built for receiving donations. Keep meaningful funds away from the explicit proof-of-concept wallets. Silent Payments pair naturally with the rest of a sovereign setup: see how wallets score on the broader picture in the wallet sovereignty matrix, plan who inherits those keys with the inheritance planner, and read the protocol itself in the Bitcoin BIPs reference. Privacy at the receiving end is finally real — just make sure you’re the one holding the indexer.
Related products, repair, and setup paths
- immersion cooling hub
- home immersion cooling guide
- ASIC miners for immersion planning
- ASIC cooling parts
- airflow shroud before immersion
- compare miner specs in the database
- ASIC repair support
Last reviewed July 18, 2026.
