Sparrow Wallet shipped Silent Payments receiving on May 21, 2026, not as a beta feature, not as a theoretical proof of concept, but as a production wallet function that works with airgapped hardware signers like Coldcard and Passport. A bugfix patch followed the next day. This is the first major desktop Bitcoin wallet to ship this combination, and it matters because it ends a tradeoff that has haunted self-custody users for two years: you could have Silent Payments privacy, or you could have cold-storage security. Now you have both.
Silent Payments (BIP-352) lets a wallet generate a unique, unlinkable on-chain address for every incoming payment without the recipient ever publishing a new address or going online. An observer watching the blockchain cannot trivially link multiple payments to the same recipient, the addresses look independent even though they all funnel to the same wallet. The problem, until now, was that SP receiving required either a connected device doing the derivation math or a compromised security model: move SP logic to a hardware signer and you had to give up airgap protection, or keep the hardware device offline and lose SP receiving entirely. Sparrow 2.5.0 solves this by letting the hardware wallet itself derive the SP address using a standardized protocol, then sign the transaction offline. The wallet also auto-selects `frigate.2140.dev` as an SP-capable Electrum server when needed, removing the friction of manual configuration.
The release came at exactly the right moment in fee conditions. At block height 950,805 (as of publication), Bitcoin network fees are hovering at 1 sat/vB across all time windows, meaning a Silent Payment notification transaction (the on-chain signal that flags a new receiving address) costs negligible sats to broadcast. Users who have been waiting for SP to mature no longer have an excuse: the infrastructure is there, the hardware wallets support it, the desktop interface is ready, and fees are trivial. Craig Raw, Sparrow's lead developer, signed the manifest on Friday, May 22 at 17:59:28 SAST using RSA key `D4D0D3202FC06849A257B38DE94618334C674B40`, a deliberate, auditable release, not a rushed patch.
The 2.5.1 patch that followed 16 hours later fixed two edge cases: an incorrect script-type selection bug in the Settings tab when loading a wallet with non-default settings, and a null-pointer exception in the transaction entry tooltip. These are the kinds of bugs that trip up users in production, and catching them within 24 hours suggests Sparrow is running tight QA on the SP implementation. This matters because Silent Payments is a young protocol, BIP-352 was standardized in March 2024, and edge cases around script types and transaction handling are exactly where integration bugs hide.
Who benefits here? Self-custody users with hardware wallets gain a practical privacy tool without compromising their security model. Hardware wallet manufacturers like Coinkite (Coldcard) and Foundation (Passport) now have a use case that drives firmware updates. Sparrow itself consolidates its position as the most privacy-conscious desktop wallet for Bitcoin users who actually run their own keys. Who does not benefit? Custodians and exchange users see no change, they never had cold storage in the first place. Developers building on top of hardware wallet protocols gain a reference implementation and a proof that the ecosystem can ship complex features end-to-end.
The open question: do other major desktop wallets follow? Wasabi, Electrum, and Bitcoin Core's GUI all have hardware wallet support. If none of them ship SP receiving in the next six months, Sparrow's first-mover advantage becomes durable. If they do, SP becomes normalized as expected functionality rather than a Sparrow-only feature. Watch the GitHub issues in competing wallet repositories for SP feature requests; that is where the market signal lives. Also watch whether the Sparrow community reports real-world SP adoption, people actually using it to receive payments privately, or whether this remains a technical achievement with minimal user uptake.