Silent Payments in 2026: Taproot’s Reusable Private Address

Bitcoin’s oldest privacy leak is the humble reused address. Post one address on a website, a Nostr profile or a donation page, and every payment to it piles up in public view: anyone can add up your balance, watch your income and map your counterparties. For a decade the fixes were clumsy, generate a fresh address for every payment, hand it over out of band, or run a mixing round. In 2026 a quieter answer is shipping in real wallets, and it has a name that fits: Silent Payments.

Bitcoin trades around $80,970 on 4 September 2026, up about 5% on the day and roughly 36% below its October 2025 record of $126,080, according to CoinGecko. The market’s attention is on price, but under the hood the privacy conversation has moved from mixers to something structurally different. Silent Payments, standardized as BIP-352, lets you publish one static code that senders turn into a fresh, ordinary-looking Taproot output for every payment: no notification transaction, no coordinator, no extra fee. It belongs in the Taproot story rather than off in some privacy sidebar for one simple reason: every Silent Payment lands in a bc1p Taproot output, and the scheme only works cleanly because Taproot exists.

What Silent Payments actually are

A Silent Payment address is a static, reusable string that begins with sp1 (tsp on test networks). Unlike a normal bc1q or bc1p address, you can paste it anywhere and reuse it forever without the usual privacy cost. When someone pays you, their wallet combines its own transaction-input keys with your published code to derive a brand-new one-time address. On the blockchain the payment shows up as a standard Taproot output with no visible link back to your sp1 code, and only you can recognize and spend it. The code is roughly 117 characters, bech32m-encoded, and carries two public keys, per the BIP-352 specification authored by josibake, Ruben Somsen and Sebastian Falbesoner. In effect it turns a single address into an unlimited supply of unlinkable ones, and it removes the wallet gap-limit problem along the way, as the Bitcoin Optech topic page describes.

That fills a real hole. Today the privacy-preserving norm is to hand out a fresh address for every payment, which works for interactive commerce but breaks the moment you need one durable, postable address: a tip jar, a Nostr zap target, a printed QR code on a conference flyer, a sponsor button on a code repository. The idea traces back to the stealth-address concepts floated on the Bitcoin mailing lists a decade ago; Somsen revived it in a cleaner form in 2022, and the proposal was merged into the Bitcoin Improvement Proposals repository in 2024. Silent Payments is built for exactly that set-and-forget case, where a single address has to stay live and reusable.

Address reuse: Bitcoin’s oldest privacy leak

Address reuse is the most common way people deanonymize themselves on Bitcoin. Publish one address and three things happen at once: your running balance becomes visible to anyone, every past and future payment to it clusters together, and chain-analysis firms or curious counterparties can watch your income and infer who is paying you. Because the ledger is permanent, that exposure never expires; a donation address posted once can be studied years later. Donation drives are the sharp example. Bitcoin Magazine points to the Canadian trucker convoy episode, where a single public donation address let observers try to identify contributors through clustering, turning a political donation into a permanent public record.

Exchanges make it worse by assigning each customer a fixed deposit address, so the platform (and anyone who ever sees that address on a screenshot or a support ticket) can watch the customer’s outside activity. The usual workaround, a new address per payment, only works when you can talk to the payer first and hand them a fresh string. Public, one-to-many or recurring payments, donations, subscriptions, payroll, a standing dollar-cost-average buy, have never had a clean answer, because there is no back-and-forth in which to pass a new address each time. That is the gap Silent Payments closes: it lets a single published code behave, on-chain, like an endless stream of one-time addresses.

The reason this matters so much is that surveillance firms have turned address linking into a commodity service. Once two payments share an address, they belong to the same cluster; from there, the common-input-ownership heuristic, exchange deposit tags and timing analysis extend the map outward until a pseudonymous address carries a real-world name. Every reused address is a fixed anchor for that process. Silent Payments removes the anchor: with a fresh output per payment and no on-chain link to the published code, there is nothing stable for a clustering engine to grab onto on the receiving side.

Under the hood: ECDH, one-time outputs, no notification

The mechanics are simpler than they look. Your Silent Payment code is really two public keys: a scan key and a spend key. To pay you, a sender’s wallet takes the private key of one of its own transaction inputs and performs an elliptic-curve Diffie-Hellman (ECDH) handshake with your scan key. That produces a shared secret only the two parties can compute, thanks to the standard ECDH property that combining one side’s private key with the other side’s public key gives the same result either way. The wallet uses that secret to tweak your spend key into a unique output key, then pays a normal Taproot output to it. Scanning the chain with your scan key, you recompute the same shared secret from the transaction’s input keys and recognize the output as yours, a flow laid out in the BIP-352 specification.

The key move is that there is no notification transaction. The previous reusable-address standard, BIP-47 payment codes (the PayNyms popularized by Samourai Wallet), required the sender to first broadcast an on-chain notification tied to your code, which leaked the connection and cost a fee. Silent Payments replaces that notification with pure key math and pushes the work onto the recipient’s scanning, so nothing extra ever hits the chain and outside observers see only ordinary Taproot payments, as Spark’s protocol comparison lays out. There is also a labels feature: you can tag the same code to tell payment sources apart (one label for donations, another for Nostr, another for an exchange) without publishing separate addresses, and label zero is reserved for your own change so a seed backup can always recover funds.

Scan key vs spend key: privacy that suits cold storage

The split between the scan key and the spend key is one of the design’s quietly clever parts. The key that watches for incoming payments is not the key that authorizes spending. You can keep the scan key on an always-online device to detect deposits while the spend key stays in cold storage, air-gapped, never exposed just to check whether you were paid. That is watch-only monitoring without putting spending authority online, the same discipline serious custody setups already chase. It rhymes with the wider push toward hardware-enforced signing and the verify-what-you-sign habits covered in our guide to multisig best practices in 2026. The hardware wallet BitBox02 shipped Silent Payment send support in its firmware back in 2024, and wiring the scan and spend split fully into hardware signers, so a cold device can help detect and then spend these outputs, is an active piece of work across the wallet field, as Spark’s wallet tracker notes.

That separation is a real improvement over the usual watch-only setup. To monitor a normal wallet without exposing spending keys, you hand a third party or a spare device your extended public key, which lets it derive and watch every address you will ever use. A Silent Payment scan key is narrower: it reveals only that payments are arriving, and it cannot enumerate a chain of future addresses, because there is no fixed chain to enumerate. For a business tracking incoming donations or a treasury desk reconciling deposits, that is a cleaner division of labor than sharing an xpub, and it maps neatly onto the cold-signer, hot-watcher pattern that careful custody already uses.

Why Silent Payments had to be Taproot

BIP-352 requires that every Silent Payment output be a Taproot (BIP-341) output. Not SegWit version 0, not a legacy script: Taproot specifically. There are three reasons, and together they explain why this upgrade could not have existed before November 2021. The first is indistinguishability. Taproot outputs are all a single 32-byte key, so a Silent Payment blends into the growing crowd of ordinary Taproot spends instead of standing out as a special output type; the specification is explicit that using only Taproot outputs puts users in the best possible anonymity set. The second is that the math fits. Taproot’s Schnorr signatures use x-only public keys, and the tweak-a-public-key operation at the heart of Silent Payments is the same key-tweaking primitive Taproot already uses to commit to scripts, so the derived output is a valid Taproot key by construction. The third is simplicity: one output type means one code path for wallets to build and audit.

That reframes what Taproot was for. The 2021 soft fork is usually remembered for Schnorr signatures and MAST, and later for enabling the Ordinals and Runes boom that filled Bitcoin’s blocks. Silent Payments is the quieter dividend. Without Taproot’s x-only keys and uniform output format, a reusable stealth address could neither hide in the crowd nor reuse the existing tweaking machinery; it would have needed a distinctive output type that flagged every private payment as private, defeating the point. Taproot did not just make Bitcoin more expressive; it made this specific privacy upgrade practical, four years after it activated.

The scanning tax: what you pay for silence

There is no free lunch. Because nothing tells you a payment arrived, your wallet has to find it by scanning. For every candidate Taproot output on the chain, the wallet does roughly one elliptic-curve multiplication to test whether that output was derived for you, per Spark’s analysis. Run your own full node and this is just extra processing on data you already hold. The friction is on light wallets: a phone that does not store the whole chain needs a server to feed it the per-transaction tweak data, about 33 bytes per candidate output, so it can run the ECDH check locally, as Bitcoin Optech describes. Ruben Somsen, who proposed Silent Payments in 2022, has likened the recipient’s added scanning workload to checking every signature twice instead of once, a comparison reported by Bitcoin Magazine: real, but bounded.

Version 1.1 of the specification, finalized in 2026, added a rule to keep scanning tractable, capping a single sender group at 2,323 recipient addresses in one transaction, a cap Spark’s tracker ties to version 1.1, so the worst-case cost stays predictable. There is an ergonomic limit too: to send a Silent Payment you must control the inputs you are spending, since the sender’s own input key is half of the handshake. That rules out a few flows where the payer does not hold the keys to the coins being spent, and it is why sending, not receiving, was the easier feature for most wallets to ship first.

Recovery is the other place the cost shows up. Restoring a Silent Payment wallet from a seed phrase means rescanning the chain from the wallet’s creation height to rediscover every output, rather than simply re-deriving a fixed list of addresses. Wallets soften this by recording a birthday, the block height at which the wallet first existed, so a restore only has to scan forward from there, but it is still heavier than a conventional recovery.

Fixing scanning for light wallets: indexes and BlindBit

Three broad approaches to the scanning problem have emerged, trading privacy against convenience:

• Run a full node and scan locally. The heaviest option and the most private: nobody else learns which outputs are yours.
• Use a dedicated index server. A server backed by a full node precomputes the tweak data for every eligible transaction and streams it to clients, which then run the private ECDH check themselves. The server never learns which outputs a given client claims.
• Use a Silent Payment-capable Electrum server. The route the desktop wallet Sparrow took, indexing tweak data and serving it to connected wallets.

Two implementations lead the index approach: the open-source BlindBit oracle-and-daemon suite, and Silent Payment-capable Electrum servers. The tradeoff here is an availability assumption, not a privacy or theft one: a malicious index could withhold data and make you miss a payment, but it cannot steal funds or learn your balance. Bitcoin Core itself is the missing piece. The core cryptography was merged in 2026, and a dedicated silent-payment index (which can be built even with the wallet disabled) is in review to serve exactly these light clients, but the send and receive wallet features have not shipped in a Core release yet, as the Bitcoin Core index pull request shows. Until they do, Silent Payments in Bitcoin’s reference wallet remain a work in progress even as third-party wallets race ahead.

Silent Payments vs CoinJoin, PayJoin and BIP-47

Silent Payments solves one specific problem, receiver address linkability, and it helps to be precise about what it is not. CoinJoin obscures the transaction graph by pooling many users’ coins in one transaction; PayJoin quietly breaks the assumption that all of a transaction’s inputs share a single owner; BIP-47 payment codes were the earlier reusable-address standard. These tools sit at different layers and are largely complementary rather than competing, as Spark’s comparison sets out.

The standout is the bottom row. Silent Payments is the only reusable-address scheme with no coordinator, no notification and no extra on-chain cost. CoinJoin still matters for graph privacy (Wasabi runs on third-party coordinators after zkSNACKs stopped its own service in June 2024, while JoinMarket stays fully decentralized), and PayJoin, boosted by a dedicated foundation formed in August 2025, hardens ordinary payments by muddying who owns which input. But for public, set-and-forget receiving, Silent Payments is the first serious challenger to plain hierarchical-deterministic addresses.

Which wallets support Silent Payments in 2026

Support has arrived wallet by wallet rather than in one coordinated switch. Cake Wallet was first across the line, shipping production send and receive in 2024 and doing the scanning on the device itself. Sparrow, the popular desktop wallet, added sending in late 2025 and full receiving in the spring of 2026, leaning on Silent Payment-capable Electrum servers so it does not have to scan the whole chain locally, per its release notes.

Craig Raw, Sparrow’s creator, took the server-assisted route on purpose, wiring the wallet to Silent Payment-aware Electrum servers so ordinary users get receiving without downloading the chain, a design captured in the wallet’s support matrix. The pattern across the field is the same: the cryptography is settled, and the race now is over the scanning infrastructure and the interface that make it painless on a phone.

The exchange and merchant question

The most valuable place for Silent Payments to land is exactly where address reuse is worst: exchange deposits and merchant checkout. A typical exchange assigns each customer a single static deposit address, which quietly leaks that customer’s on-chain history to the platform and to anyone who ever sees the address. One sp1 code per customer would fix that without the exchange rotating addresses or the customer copying a new string on every deposit.

So far no major exchange has adopted Silent Payments for deposits, and the reasons go past engineering. Scanning cost is one. Compliance is the other: exchanges operate under know-your-customer rules and the FATF Travel Rule, and a receiving scheme that hands them fresh, unlinkable outputs cuts against the internal address clustering they lean on for monitoring. Whether privacy-improving receiving can coexist with the surveillance duties built into modern crypto compliance is unresolved, a tension we examined in our look at whether crypto KYC and AML actually work in 2026. It is worth stressing that Silent Payments does nothing to hide the identity you already handed an exchange at signup; it protects the receiving side going forward, not the record behind you.

There is an instructive contrast on the account side. Ethereum spent 2026 pushing smart-account features across wallets and exchanges through EIP-7702, changing how accounts behave at the protocol level. Bitcoin’s improvement is narrower and more surgical: it does not touch how accounts work at all, it just fixes how a receiving address is represented so that reuse stops leaking. One reshapes the account; the other reshapes the address.

Privacy after the crackdown: Samourai, Tornado Cash and why this is different

The privacy conversation in 2026 sits in the shadow of prosecutions. In November 2025 the co-founders of Samourai Wallet, Keonne Rodriguez and William Lonergan Hill, were sentenced to four and five years in federal prison after pleading guilty to conspiring to run an unlicensed money-transmitting business. Prosecutors said Samourai’s Whirlpool CoinJoin and Ricochet services moved more than 80,000 BTC, worth around $2 billion at the time, and roughly $237 million in criminal proceeds; the two forfeited $6.3 million, as The Record and CoinDesk reported. The Tornado Cash case ran on a parallel track. The through-line the Department of Justice drew was coordination: because Samourai’s server coordinated the mixing rounds, the government argued the software was money transmission even though it never held anyone’s coins.

This is where Silent Payments sits on the other side of the line. There is no coordinator. There is no pooling of other people’s coins. No server has to touch, order or mix funds. A Silent Payment is a normal one-to-one Bitcoin payment; the only novelty is how the receiving address is derived, entirely between one sender and one receiver, with the option to run the whole thing against your own node. Privacy advocates argue that publishing software like this should never have counted as a financial service. As Coin Center research director Peter Van Valkenburgh put it, “Nobody wants the publishers of mere wallet software to be treated as if they hold the financial assets of those who use their software to hold their own assets,” adding that nobody should want the core developers of Bitcoin or Ethereum to need permission before they publish new versions of the protocol code. The group has urged prosecutors to drop the outstanding non-custodial software cases as regulation by prosecution.

None of that makes Silent Payments a legal shield, and evasion is not the point. But structurally it is hard to frame as transmission or mixing: it moves no one else’s money and relies on no coordinator. In a year whose regulatory calendar kept crypto lawyers busy well past the summer, as our rundown of the deadlines running into January laid out, that structural difference is close to the whole argument for why a privacy tool can ship into mainstream wallets now.

What Silent Payments does not do

It helps to set expectations, because Silent Payments is not a mixer and not a cure-all. It hides the link between your public code and your on-chain outputs; it does not obscure amounts, and it does not break the transaction graph once the coins are in your hands. If you buy Bitcoin on a KYC exchange and withdraw to a Silent Payment address, the exchange still knows it paid you. The sender always learns the one-time address (they created it) and the amount they sent, though they cannot correlate that with your other income. And spending received coins carelessly, for instance sweeping many Silent Payment outputs into a single transaction, can re-link them, so ordinary coin-control discipline still matters. Treat it as fixing the receiving leak, not as anonymity, and pair it with graph-level tools when the threat model demands more.

Network privacy is a separate layer too. If a light wallet fetches tweak data from someone else’s index over a bare internet connection, that server learns your IP address and the fact that you are a Silent Payments user, even though it cannot tell which outputs are yours. Running your own node, or routing requests over Tor, closes that gap. And the sender’s setup matters as much as yours: if their wallet leaks metadata or reuses its own inputs carelessly, your privacy gains on the receiving side can be undercut from the other end. Silent Payments raises the floor; it does not replace good habits on either side of the payment.

Bitcoin Core, Lightning and the road ahead

The next year is about plumbing, not cryptography. Getting send and receive into a Bitcoin Core release, and shipping the silent-payment index, would give every downstream wallet a trustworthy scanning backend and would likely speed adoption, which is why the index pull request is watched closely. Hardware wallets need to move from send-only to full scan and spend integration. And there is early work on marrying Silent Payments with Lightning and with the wider set of Taproot-native building blocks that also underpin Bitcoin’s rollup and tokenization experiments, the same base layer whose Layer 2 ecosystem spent 2026 thinning out to the projects with real demand.

Lightning is the most interesting frontier. Simple Taproot Channels reached production on Lightning during 2026, giving the network the same x-only key format Silent Payments rely on, and the two features share a Taproot foundation that makes eventual integration feel natural rather than forced. Pairing a static, private on-chain receiving code with cheap off-chain settlement would give merchants and creators a single reusable identifier that works whether a customer pays on-chain or over Lightning. None of that is finished, but the pieces are converging on the same base layer.

The strategic read is that Silent Payments is the rare Bitcoin privacy improvement that needs no soft fork, no new opcode, no coordinator and no legal surface resembling the cases now in court. It rides entirely on address derivation and on Taproot outputs that already exist. If the scanning experience gets good enough on phones, the reusable sp1 code could become as ordinary as bc1q became after SegWit: not a privacy tool you opt into, just how a public Bitcoin address works.

Frequently Asked Questions

What is a Silent Payment address and how is it different from a normal Bitcoin address?

A Silent Payment address is a static, reusable code that starts with sp1. Unlike a normal bc1q or bc1p address, you can post it publicly and reuse it forever without linking your payments together. Each time someone pays it, their wallet derives a fresh one-time Taproot output, so on the blockchain there is no visible connection back to your sp1 code.

Do Silent Payments cost extra in fees?

No. A Silent Payment settles as an ordinary Taproot output, the same size and fee as a normal payment, and unlike the older BIP-47 payment codes there is no on-chain notification transaction. The cost is computational: your wallet scans the chain to find payments, which is cheap on a full node and handled by an index server for light wallets.

Which wallets support Silent Payments in 2026?

Cake Wallet, Sparrow, Silentium and Nunchuk support both sending and receiving, while BitBox02, Wasabi and Electrum support sending. Bitcoin Core has merged the underlying cryptography but has not shipped the send and receive wallet features in a release yet.

Are Silent Payments legal after the Samourai and Tornado Cash cases?

Silent Payments is a way to receive ordinary payments privately; it is not a mixer and has no coordinator, which was the feature prosecutors focused on in the Samourai case. Using it is not illegal, and it does not remove your exchange KYC or tax obligations.

Do Silent Payments make Bitcoin anonymous?

No. They fix address reuse, the receiving-side leak, so a public code cannot be linked to your on-chain coins. They do not hide amounts, do not break the transaction graph, and do not erase the identity a KYC exchange already has; they are one privacy layer, complementary to CoinJoin and PayJoin.

By Marcus Okafor, Senior Editor, HOGE Wire.