Silent Payments

  • Name: Silent Payments
  • URL: https://silentpayments.xyz/
  • Category: Bitcoin reusable payment-address protocol / privacy-preserving static receive standard / wallet-scanning infrastructure
  • Tags: bitcoin-ecosystem
  • 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 BTCPay-style infrastructure
    • 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