Silent Payments

  • Name: Silent Payments
  • URL: https://silentpayments.xyz/
  • Category: Bitcoin reusable receive standard / static-address privacy protocol / wallet-scanning infrastructure
  • Tags: bitcoin-ecosystem bitcoin-standards
  • Summary: Silent Payments are a reusable-address standard, not a wallet brand. The trick is simple: let a receiver publish one static identifier while each sender still produces a fresh Taproot output with no extra notification transaction. The real burden then moves to wallet scanning, labeling, and recovery state. That makes Silent Payments useful as wallet and indexer plumbing, not as a grand privacy stack.
  • What it does:
    • Lets a Bitcoin user publish one reusable static address that can generate unique on-chain receive outputs for every sender and payment
    • Avoids address reuse and avoids separate on-chain notification transactions, so Silent Payments blend into ordinary Taproot outputs rather than advertising a special protocol footprint
    • Separates scanning and spending responsibilities through scan/spend key design in the BIP, which reduces hot-wallet exposure for receivers
    • Supports labels so a receiver can reuse one silent-payment identity while still distinguishing incoming-payment contexts internally
    • Requires receiving wallets or back ends to scan relevant blockchain activity for matching outputs, which makes wallet and indexer architecture part of the practical implementation surface
    • Has grown into an ecosystem of website docs, libraries, wallet integrations, and scanning-back-end experiments instead of remaining only a theoretical Bitcoin proposal
  • Key claims:
    • BIP-352 describes Silent Payments as a protocol for static Bitcoin payment addresses “without on-chain linkability of payments or a need for on-chain notifications,” which is the strongest single statement of what the protocol is for
    • The BIP goals explicitly include no increase in transaction size or cost, indistinguishability from ordinary bitcoin transactions, no sender-receiver interaction, and protection of both sender and receiver privacy
    • The official docs site says Silent Payments let users create a single static address for donations, tips, and repeated payments without sacrificing privacy, and repeatedly emphasizes “no server required” as a differentiator from notification-heavy or server-dependent receive flows
    • The docs also explain that each sender derives a unique one-time Taproot address from the reusable Silent Payment address, which is the clearest sign that the system is reusable-address infrastructure rather than simple static-address reuse
    • The BIP overview defines separate scan and spend keys plus labels, showing that Silent Payments are not just an address format but a deeper wallet-and-recovery model
    • The developer page says the most important implementation priority is broad send support and lists multiple Rust, TypeScript, Dart, Go, and JavaScript libraries plus several scanning-back-end efforts, which shows the project has become an ecosystem substrate rather than a one-wallet experiment
    • The wallets page tracks support across BitBox, BlueWallet, Cake Wallet, Sparrow, Wasabi, Nunchuk, and others, and explicitly distinguishes privacy-preserving scanning support, reinforcing that real deployment questions center on wallet and back-end architecture
    • BitBox’s technical explainer says Silent Payments are a BIP for a new Bitcoin address format that removes the need to manage many receive addresses while preserving privacy, but also notes important implementation constraints around input types and scanning complexity
  • Whitepaper: No separate standalone Silent Payments whitepaper or litepaper surfaced in this pass. The canonical source of truth is BIP-352, supplemented by the official docs site, wallet-support tracker, developer docs, and implementation-focused explainers; see ../../whitepapers/silent-payments-primary-sources-2026-05-03.md.
  • Sources:

Internal linkages

  • Strongest comparisons: paynym-bip47 and payjoin.
  • Keep the note on reusable receive privacy, scan burden, labels, and wallet/back-end support.

Control surface

  • The leverage sits in receiver scanning architecture, label handling, wallet recovery design, and whether send support becomes broad enough that the standard is actually usable outside a narrow wallet set.

  • Treat Silent Payments as better reusable receive plumbing, not as a full privacy-coordination system.

  • Last reviewed: 2026-06-10 UTC