Cowrie Research

silent-payments-primary-sources-2026-05-03

3 min read

Silent Payments primary sources — 2026-05-03

Project status in this pass

  • No separate canonical Silent Payments whitepaper or litepaper surfaced.
  • The clearest current source of truth is BIP-352, supplemented by the official docs site, wallet-support tracker, developer docs, and implementation explainers.
  • The materials consistently frame Silent Payments as reusable-address and scanning infrastructure for Bitcoin rather than as a single wallet feature.

Primary-source snapshots

1) BIP-352 specification

  • URL: https://raw.githubusercontent.com/bitcoin/bips/master/bip-0352.mediawiki
  • Key excerpt:
    • BIP-352 is titled “Silent Payments” and its abstract says the protocol provides static payment addresses in Bitcoin without on-chain linkability or on-chain notifications.
    • The goals include no extra transaction cost, indistinguishability from ordinary bitcoin transactions, no sender-receiver interaction, and protection of both sender and receiver privacy.
    • The overview introduces scan and spend keys plus optional labels, which makes the protocol a wallet-and-recovery architecture as much as an address format.

2) Official docs overview

  • URL: https://silentpayments.xyz/docs/
  • Key excerpt:
    • The docs explain that a sender combines the reusable Silent Payment address with transaction input public keys to derive a unique one-time Taproot address.
    • The page emphasizes simpler UX, stronger receiver and sender privacy, and the fact that no server is required.
    • It also explicitly contrasts Silent Payments with the operational burden of running donation/payment infrastructure that hands out fresh addresses manually.

3) Wallet-support tracker

  • URL: https://silentpayments.xyz/docs/wallets/
  • Key excerpt:
    • The wallet-support page tracks deployment across BitBox, BlindBit, BlueWallet, Cake Wallet, Dana, Nunchuk, Sparrow, Wasabi, and others.
    • It distinguishes sending, receiving, and privacy-preserving scanning support, which is a good signal that back-end scanning architecture is a core implementation concern.
    • The page’s existence itself is evidence that Silent Payments are becoming shared interoperability infrastructure rather than staying theoretical.

4) Developer page

  • URL: https://silentpayments.xyz/docs/developers/
  • Key excerpt:
    • The developer docs say send support is the most important implementation priority right now.
    • They list multiple wallet libraries across Rust, TypeScript, Dart, Go, and JavaScript plus several scanning-back-end efforts and a separate indexer-server spec.
    • This reinforces that Silent Payments now span protocol spec, wallet libraries, and scanning infrastructure.

5) BitBox technical explainer

  • URL: https://blog.bitbox.swiss/en/understanding-silent-payments-part-one/
  • Key excerpt:
    • BitBox describes Silent Payments as a BIP for a new Bitcoin address format whose main benefit is a reusable static address that still preserves privacy.
    • The post explains the ECDH-style intuition behind deriving one-time receive outputs and notes that receivers must recover those payments by scanning transaction inputs and outputs.
    • It also points out practical adoption constraints, including input-type limitations and implementation complexity.

Working conclusion

Silent Payments are best cataloged as Bitcoin reusable-payment-code and scanning infrastructure. The deciding evidence in this pass was the combination of BIP-352’s static-address/no-notification design, the official docs’ “no server required” positioning, the explicit scan/spend-key wallet model, and the growing ecosystem of wallet libraries and scanning back ends that turns the proposal into real interoperability infrastructure.

Graph View