BIP392: Silent Payment Descriptors Enable Wallet Interoperability | Bitcoin Index

Silent payments are elegant in theory: publish one address, receive unlimited payments, no address reuse, no sender-receiver interaction, perfect privacy. In practice? They needed one more piece to work across wallets.

BIP392, merged March 5th, delivers that piece. It defines sp(), a new output script descriptor specifically for silent payments. This isn’t flashy protocol work. It’s the unsexy infrastructure that makes things actually usable.

Without a standard descriptor format, every wallet implementing BIP352 silent payments would invent its own backup scheme. Users would be locked into single wallets. Recovery across implementations would be a nightmare. BIP392 prevents that fragmentation before it starts.

The Problem: Standards Prevent Chaos

BIP352, finalized in 2023, specified silent payments completely. The cryptography works. Early wallets like Cake Wallet already support it. But there was a gap: no standard way to represent silent payment keys in wallet backups.

Wallet descriptors, standardized in BIP380, solve this for traditional output types. A descriptor like wpkh([fingerprint/84h/0h/0h]xpub.../0/*) tells any compatible wallet exactly what scripts to generate and how to derive keys. You can export that string, import it into a different wallet, and everything just works.

Silent payments need the same treatment. Without it, you get:

Fragmented backups - Every wallet invents a custom format
No interoperability - Can’t move between wallets without re-generating addresses
Watch-only complexity - No clean separation between scanning keys and spending keys
Recovery headaches - Lose your wallet, lose your format documentation, lose your funds

BIP392 fixes this by extending the descriptor framework with a new top-level expression: sp().

The Solution: sp() Descriptors

BIP392 introduces two new key expression types, both encoded using Bech32m:

spscan encodes a scan private key and spend public key. This is for watch-only wallets that can detect payments but not spend them. Perfect for scanning on a networked device while keeping spending keys in cold storage.

Format: spscan1q... (mainnet) or tspscan1q... (testnets)

spspend encodes both scan and spend private keys. This is a full wallet that can scan the blockchain and spend detected outputs.

Format: spspend1q... (mainnet) or tspspend1q... (testnets)

Both represent silent payment version 0. When combined with sender input public keys (as defined in BIP352), they produce standard P2TR taproot outputs. On-chain, these are indistinguishable from any other taproot output. Privacy preserved.

Descriptor Forms

Single-argument form takes an spscan or spspend encoded key:

sp(spscan1q...)
sp([deadbeef/352h/0h/0h]spscan1q...)  // with key origin
sp(spspend1q...)

Two-argument form separates scan and spend keys:

sp(WIF_scan_key, compressed_pubkey_spend)
sp([deadbeef/352h/0h/0h]xprv.../0h, xpub.../0h)
sp(WIF_scan_key, musig(pubkey1, pubkey2))  // MuSig2 spend key

The first argument must be a private scan key (WIF or xprv). The second can be any BIP380-compatible key expression, including musig() for MuSig2 aggregate keys (defined in BIP390).

That last example is interesting: silent payments with multisig spending. You publish a single static silent payment address, receive unique outputs, and require multiple signatures to spend. Privacy and security in one package.

What This Enables

Interoperability across wallets. Export your sp() descriptor from Sparrow, import it into Bitcoin Core, and both wallets see the same outputs. No custom formats, no conversion tools, no guesswork.

Clean watch-only separation. Scan for payments on your networked desktop with spscan keys. Keep spspend keys on a hardware wallet. This is how people already use Bitcoin Core with cold storage. BIP392 brings that workflow to silent payments.

Future-proofing. The descriptor framework is extensible. When silent payments v1 arrives (if it ever does), the format can accommodate it. Wallets that already parse descriptors get a head start on implementation.

Standardized backups. Write down your descriptor. That’s your backup. Same as any other descriptor-based wallet. No special instructions, no vendor lock-in.

Who Built This

Craig Raw, developer of Sparrow Wallet, authored BIP392. Sparrow is known for standards compliance and transparency. It’s the wallet developers use when they want to see exactly what’s happening under the hood.

Raw proposed the initial draft on the Bitcoin-Dev mailing list in early January 2026. The original proposal included optional BIRTHDAY and LABEL arguments directly in the descriptor. Community feedback pushed those out into a separate descriptor annotations proposal, keeping the core sp() expression focused on output scripts only.

The BIP was assigned number 392 on February 6th and merged March 5th at 16:02:52 UTC.

Status and What’s Next

BIP392 is currently Draft status. It requires BIP341 (Taproot), BIP350 (Bech32m), BIP352 (Silent Payments), and BIP380 (Descriptors). All of those are already deployed or finalized.

No reference implementation or test vectors yet. Those are listed as TBD in the BIP header, which is normal for newly merged drafts.

Wallet adoption will take time. Several wallets already support BIP352 silent payments (Cake Wallet, Silentium) or are considering it (BlueWallet). Sparrow has an open bounty for sending support. Adding sp() descriptor support to wallets that already handle descriptors should be straightforward. The hard part is implementing BIP352 scanning. BIP392 just standardizes how you represent the keys.

One open question: light client support. BIP352 requires scanning the blockchain to detect payments. That’s heavy for mobile wallets. Light client solutions for silent payment scanning remain “an area of open research.” BIP392 doesn’t solve that. It just makes sure that when you do scan, you can back up and restore your wallet in a standard way.

Why This Matters

Silent payments were already possible. BIP352 is complete. Wallets can implement them today. But without descriptor standardization, every implementation would diverge. Users would be stuck. Developers would reinvent wheels.

BIP392 is the kind of work that doesn’t make headlines but prevents disasters. It’s the difference between “this cool thing exists” and “this cool thing actually works in the real world.”

Standards are boring. Fragmentation is expensive. This BIP picks boring.