Wasabi 2.8.0 and the State of Bitcoin Privacy Wallets in 2026

You run a Bitcoin wallet that promises privacy. You trust it to break the link between your identity and your coins. But behind the scenes, for years, that wallet phoned home to a single server run by the wallet's developers to fetch the data it needed to function. If that server went down, or was seized, or was served a legal order, your "private" wallet would degrade into a slow,blind client.

That server is now gone. With Wasabi Wallet 2.8.0, released last week, the wallet synchronizes directly with Bitcoin's peer-to-peer network of nodes. No middleman. No central indexer to subpoena. This is the headline of a release that removes more single points of failure in one go than most wallets address in their entire roadmap.

If your privacy tool depends on a server the developer controls, your privacy is only as strong as that developer's legal jurisdiction. The fix is not better cryptography. It is removing the dependency entirely.

What Actually Changed in 2.8.0

Wasabi 2.8.0 is not a maintenance release. It is a structural one. Eight highlighted features, each of which solves a real problem for people who use Bitcoin privately. Here are the ones that matter most for a self-custody user in 2026.

Direct synchronization with the Bitcoin P2P network

Wasabi pioneered compact block filters (BIP 158) years ago — a technique that lets a wallet figure out which transactions are relevant to it without downloading the chain or revealing its addresses. Until now, Wasabi ran its own server to build and hand out those filters. That server was a single point of failure.

In 2.8.0, the wallet pulls those filters directly from ordinary Bitcoin nodes over the P2P network. The centralized filter server is gone. New users also get "wallet birthday" checkpoints, so a freshly generated wallet does not waste hours downloading ancient history it could never need.

Pay inside the coinjoin

Ordinarily, paying someone from a coinjoined wallet leaks information: how long you held your coins, how much change you have left, and the fact that you are the payer. Wasabi 2.8.0 lets you send a payment inside a coinjoin transaction itself. The receiver can no longer tell how seasoned your inputs were. Your change size stays hidden. And you can batch several payments into one transaction without revealing they came from the same person.

Sub-1 sat/vByte fees

Fees can now be set as low as 0.1 sat/vByte. On a quiet mempool, that can save up to 90% on mining fees compared to the previous floor of 1 sat/vByte. If a low-fee transaction stalls, Replace-By-Fee (RBF) is available to nudge it through. The whole stack is full-RBF by default since v2.7.0, so bumping a stuck transaction is always an option.

Payment batching, arm64 Linux, Tails and Whonix

You can now pay multiple addresses in one transaction, which economizes on block space. The privacy-OS crowd gets a real win too: Wasabi now runs natively on arm64 Linux, and installations on Tails and Whonix are automatic — no more manual Tor gymnastics.

A scripting language and a forward-compatible Tor

An experimental Scheme scripting engine is now available, making the wallet programmable and queryable by power users. The Tor Project drops network support for versions older than 0.4.9 on September 1, 2026 — Wasabi has already bumped its bundled Tor to 0.4.8.21 to stay ahead of that deadline, with forward compatibility for the jump to 0.4.9.

The Big Picture: How We Got Here

The privacy story in Wasabi does not start at 2.8.0. It is the endgame of a multi-version effort to make the wallet unkillable.

• v2.4.0 shipped Send-to-Silent-Payments — static, privately reusable addresses where observers cannot link multiple payments to the same recipient.
• v2.5.x made fee and exchange-rate providers user-configurable, so you can run with zero third-party dependencies if you choose.
• v2.6.0 "Prometheus" was the survival pivot: full-node integration reworked, SLIP-39 multi-share backups (2-of-3 seed shards) added, and a Nostr-based update manager that fetches updates without relying on GitHub staying friendly.
• v2.7.0 polished the node integration, shipped full-RBF by default, and beefed up coinjoin coordinators that run as onion services out of the box.
• v2.7.2 shipped bug fixes: hardware-wallet Silent Payments disabled where unsafe, fee floors reset to sensible values, and broadcast robustness when no estimates are available.
• v2.8.0 removes the last centralized dependency — the filter server — and layers real-world privacy wins on top.

Read the surface from version to version and the through-line is obvious: Wasabi has spent the last two years systematically deleting every reason the wallet could stop working. Server dependency gone. GitHub dependency softened with Nostr fallback. Bitcoin Core dependency removed. Tor dependency future-proofed. Each release trims another wire that could be cut.

Where the Wider Wallet Field Stands

Wasabi is not alone in the privacy-wallet lane. To judge the release honestly, you have to know the competition.

• Sparrow Wallet is the desktop power-user favorite. It supports Whirlpool-style coinjoins, hardware wallet integration, BIP-47 payment codes, and lets you point at your own node. Where Wasabi differentiates is its self-contained coinjoin coordinator and now its serverless filter architecture. Sparrow leans on you to bring the backend; Wasabi brings one less part than it used to.
• Hardware wallets — Coldcard, Trezor Safe 5, BitBox02 — hold the keys, they do not coinjoin. Since v2.3.0.0 Wasabi has supported both Trezor Safe 5 and Coldcard Q via HWI 3.1.0, and 2.7.2 carefully disabled Silent Payments for hardware wallets where the spec was not yet safe to honor. The honest split: hardware secures your seed, Wasabi and Sparrow do the privacy choreography on top.
• Silent Payments are now shared vocabulary across the field. Wasabi gained Send support in v2.4.0. Other wallets are following. Interoperable, observer-unlinkable static addresses are becoming a baseline expectation, not a differentiator.
• SLIP-39 Shamir backups arrived in Wasabi 2.6.0 and became the default first option in 2.8.0 — letting you split your seed into shares so no single shard compromises your funds. Trezor pioneered this; Wasabi adopting it as the default nudges the rest of the desktop-wallet world to follow.

What sets Wasabi apart in 2026 is not any single feature. It is that it is now the only privacy-focused desktop wallet that can run end-to-end with no trusted server, no bundled Bitcoin Core, manual Tor for privacy-OS users, and a coinjoin coordinator that ships as a default onion service. That is a meaningful reduction in trust surface.

Worth noting: BIP-47 payment codes and reusable addresses are still maturing across wallets, and you should not assume privacy just because a feature exists. Verify that a coinjoin wallet's coordinator logs are ephemeral, that you can point it at your own node, and that the wallet does not phone home for fees or exchange rates unless you opt in.

Honest Limits of This Release

This is a genuinely important release, but it is not magic. Real trade-offs remain:

• Coinjoins still cost. Pay-in-coinjoin improves privacy per byte, but coinjoin rounds still pay coordinator fees. On full mempools, these add up.
• Adoption risk. Pay-in-coinjoin only yields anonymity when enough other people are paying into the same round. If rounds are sparse, the privacy gain is symbolic.
• Silent Payments still send-only. Wasabi can send to them but receiving to a Silent Payment address is not yet in the client. Sending works; receiving is a future feature.
• Hardware-wallet caveats. Silent Payments on hardware wallets are disabled in v2.7.2 because the device-side spec was not ready. If you need full privacy today, the gap between the hot-wallet and hardware-wallet experiences is real.
• Coordinators can still be tugged. Decentralized onion coordinators are good, but a hostile or compromised coordinator can still degrade rounds. Run your own coordinator on a pruned node if your threat model demands it.

What To Do Next

If you self-custody Bitcoin and care about privacy, version 2.8.0 is worth the upgrade for the serverless filters alone. Here is the sane path:

• Verify the download. Wasabi uses reproducible builds — check the SHA256SUMS against the release page and verify the .asc signature with the Wasabi signing key before installing. This is non-negotiable for a wallet.
• Point it at your own node if you run one. RPC connectivity has been solid since v2.7.0 and now supports onion-service RPC, so the wallet can route everything through Tor.
• Try SLIP-39 backups if your wallet supports it. A 2-of-3 seed split held in geographically separate locations survives both fire and a single-source leak. It is now the default in 2.8.0.
• Test pay-in-coinjoin on signet before relying on it on mainnet. Signet is now the supported test network in 2.8.0 specifically because testnet3/4 are unstable. Use signet coins to confirm your flow works.

If your privacy setup has grown beyond a single desktop wallet — multi-wallet custody, corporate treasury flows, or cold/hot split architectures — a release like this is the right moment for a privacy audit. Coinjoin strategy, coordinator choice, and coin selection policy all interact, and a fresh upgrade is the cheapest time to revisit them.

Sources: Wasabi Wallet release notes (GitHub) · Wasabi Wallet official site · Related reading: Why Your Next Hardware Wallet Needs a QWERTY Keyboard