Bitcoin Silent Payments (BIP-352) solve a specific problem: you publish one unchanging address to receive money, but each payment lands on a different on-chain address. Outside observers cannot link those payments to you. This address starts with sp1 and can be placed on a website, social media, or donation page and reused indefinitely. You do not need to generate a new address every time someone pays you.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
But this convenience comes at a cost: the receiver must actively scan the blockchain to discover payments. Payments do not land on an address you already know. The wallet needs to check candidate transactions in blocks, derive possible outputs using its own private keys, and determine which one is meant for you. Sending is relatively simple — paste an sp1 address into the send screen, just like a normal address.
Receiving: Scanning Is Required, but You Can Control the Cost
The receiver needs to enable scanning. In Cake Wallet, for example, go to Settings → Privacy → Silent Payments and enable "Set Silent Payments always scanning." The wallet checks candidate transactions block by block. While scanning, an amber dot appears next to the chain label on the main screen to show that scanning is in progress.
Scanning uses battery and mobile data. If you rarely receive Silent Payments, you can leave always-on scanning off and enable it manually only when you expect a payment. Payments are not lost; they simply will not appear in your wallet until you scan.
One key limitation: scanning requires an Electrum server that supports tweak data. If the custom node you are connected to cannot provide the data needed for scanning, Cake Wallet falls back to its own server at electrs.cakewallet.com:50001. If you run your own node for privacy, you need to confirm that your electrs build supports the Silent Payments tweak index. Otherwise, your scanning traffic goes through Cake Wallet's infrastructure.
Sparrow Wallet has a more mature receiving path. It gets tweak data by connecting to an Electrum server that supports SP, such as the public server frigate.2140.dev. Client-side detection is done locally, but the server can see your IP address and query patterns. The most private setup is to run your own Frigate instance so that scanning queries do not pass through any third party.
Backup: Beyond the Seed Phrase, There Are Special Keys
Recovering a Silent Payments wallet involves one more layer than a normal wallet. Your seed phrase can still restore the entire wallet, including the Silent Payments scan and spend keys. But in Cake Wallet, keys are displayed separately by coin — under the Bitcoin tab there is a separate "Silent Payments (Bitcoin)" tab that contains the Silent Payments scan private key and spend public key information.
When backing up, you need to write down the contents of all tabs, not just the main seed phrase. If you only import the seed phrase during recovery, some wallets may not automatically restore Silent Payments scanning ability. You need to confirm whether the restored wallet has the sp() descriptor or an equivalent key import method.
BIP-392 defines the output script descriptor format sp() for Silent Payments. It supports backup using spscan (scan key only, watch-only) or spspend (scan and spend keys, full wallet). If your wallet supports exporting descriptors, exporting and saving this string is a more reliable backup method than handwriting keys. The derivation path is m/352'/0'/0'. Do not change it.
Sending: Simple, but There Are Risks with Collaborative Transactions
Sending Silent Payments does not require learning new steps. Paste an sp1 address and the wallet handles it automatically. Most mainstream wallets already support sending — Sparrow, Cake Wallet, BlueWallet, Wasabi, Nunchuk, and BitBox02 can all do it.
But Silent Payments in collaborative transactions such as CoinJoin have known issues. In August 2026, a hardware wallet vendor disclosed that a malicious host could lock Silent Payments funds to an unintended address in a collaborative transaction, and recovery would only be possible with the attacker's cooperation. This failure class is why BIP-375 requires mandatory DLEQ proof verification. If you send Silent Payments through a collaborative transaction, confirm that the wallet implements BIP-375 verification.
The Reality of Hardware Wallets
BitBox02 supports sending to sp1 addresses, but it cannot independently receive Silent Payments — a hardware device cannot continuously scan blocks. To receive, you need to pair BitBox02 with a software wallet such as Sparrow. The software wallet handles scanning, and the hardware device handles signing.
Practical Advice
If you just want to receive donations or regular payments, Cake Wallet on mobile is the fastest way to start. Enable always-on scanning and accept the trade-off that scanning traffic goes through Cake Wallet's servers, or confirm that the node you connect to supports the tweak index.
If you have higher privacy requirements, Sparrow desktop with your own Frigate server is currently the most complete setup. The trade-off is that you need to maintain an index server, but in return your scanning queries do not pass through any third party.
If you only use a hardware wallet, the receiving path for Silent Payments is still incomplete. Sending can be done through BitBox02, but receiving requires an additional software layer. At this stage, the concept of using a hardware wallet for Silent Payments "cold storage" does not really hold, because payment detection depends on an internet-connected device.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
