pull down to refresh

It means that there are currently 7 coordinators maintained by the community, but because there is an incentive to hide in the biggest crowd, one coordinator will always capture most of the liquidity. However, if that coordinator disappears, I would expect the second most popular one to take its place as the most prominent, because the liquidity would flow to it. In case that coordinator also disappears, the third one would take its place, and so on. Also, I would expect more coordinators to appear.
It is not a reinvention, the distribution mechanism contemplates the possibility of using bittorrent, the difference is that the wallet detects there is a new version because it is published in nostr and it can inform the user. In case the protocol used is http, it can also download it and verify the authenticity automatically.
No. Automatic updates is evil. I said automatic distribution, which means that Wasabi can find new releases, download them and verify them for you.
It doesn't update/install anything. It just tells you: there is a new version downloaded here. So you can install it or ignore it.
Wasabi has always been much larger than Samourai. Anyone can verify this directly from blockchain data.
This paper https://crysp.petsymposium.org/popets/2026/popets-2026-0061.pdf shows that (see Table 3):
If we use the number of fresh inputs as a proxy for popularity, you can see that during the zkSNACKs period, Wasabi usage outperformed Samourai by a wide margin. Wasabi’s fresh inputs totaled 297,238.5 BTC, while Samourai’s were only 47,309 BTC.
Kruw’s coordinator processed, in less than two years, more than Samourai did in its entire history. By November 2025—after 18 months of operation—Kruw’s coordinator had already reached 46,309 BTC in fresh inputs.
Your question is not about Wasabi but about Umbrel and how to expose the Bitcoin Node RPC. I don't know how your infrastructure is configured but if you have your node's RPC enabled and the RPC port is opened in your Umbrel then you should be able to connect to it and you could test the connection using bitcoin-cli. My suggest to ask to Umbrel team/community how to expose the RPC.
Finally, Wasabi requires compact filters from your node if you want to synchronize and operate without using any external filters' providers. That means that you have to enable the creation of compact filters in your node.
Once you install the bitcoin node and enable the rpc interface, lunch Wasabi and it will detect your node.
Wasabi was developed by a company which closed its doors last year. Since then, a tiny group of volunteers took the responsibility to continue with the project and has been focused on guaranteeing the survival of the wallet. This means changing an originally centralized, trusted, client-server architecture to a standalone, trustless piece of software with decentralized services run by volunteers. In other words, the goal is still to completely redesign Wasabi's architecture to eliminate central points of failure and protect Wasabi users and volunteers.
Even though every release highlights user-oriented features such as Silent Payments, SLIP39, support for newer hardware wallets, and similar improvements, the most important changes are structural. These changes allow others to run coordinators, backend servers, or both. It also allows Wasabi to synchronize and operate without a central server by connecting to your own node.
The next goal for the team is to shut down the backend and let others host tiny indexers that users can connect to.
If you are interested, I explain all this a bit better in the Bitcoin Talk forum thread I posted: https://bitcointalk.org/index.php?topic=5476197.msg65272894#msg65272894
I strongly recommend using Wasabi as a privacy-oriented wallet and not as a mixer.
This means that you should welcome both large chunks and smaller amounts (10k, 20k sats) because this increases your capacity to make payments privately and avoid change.
Having a variety of denominations makes it much easier to find combinations of coins for payments you need to make. Even if Wasabi can't avoid creating change for your transaction, only a tiny portion of your wallet will be known by someone else, and the labeling system (in my opinion, the most powerful tool in Wasabi) will help you avoid leaking more information to others.
Having very few coins, or in the extreme case only one coin, is a privacy nightmare. This means that whatever payment you need to make will involve a large portion of your wallet, which also means you cannot avoid change, and then your future payments will be trackable. For example, a wallet with only one coin generates a peel chain that is trivial to follow.
There are situations where consolidating can make sense, such as when coins are too small and you fear they could become unspendable or too costly to spend, but in general, it is not the best approach for privacy.
The "Wasabi is a mixer" mentality consists on sending to Wasabi, participate in many coinjoins and then consolidate everything to send it to a non-privacy-focused wallet. Do not do that.
Okay okay, if you want/need to do it then there are a couple of ways to do it to mitigate a bit these problems:
- Coinjoin to another wallet: Wasabi can send your coins in a coinjoin to another wallet. In this case it tries to use as much coins as possible (never more than ten) and send that amount to a different wallet in a set of outputs. It doesn't do a big consolidation but it at least doesn't generate much outputs
- Pay in coinjoin: It requires a few command lines but it is a super powerful tool that allows you to send money in a coinjoin where you are the one who specify the amount of the output. Here you can see a donation to El Salvador bitcoin address in a Wasabi coinjoin: https://mempool.space/tx/8c58beccc25acc763c528515b3a23bb92eeb6dc41b519ef681f76dfcc76cc19d#vout=433
Blockchain.com displays an address for a p2pk script.
> let pk = PubKey "048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fd";;
val pk: PubKey =
048b48e109f432a490522f8d0e9e833443809f65b8aa2558b94c1c15eb0fd3e24f32d58a088a2b0e5e694d05e7b981e5c9750827646eb81debc816c3c667eea5fd
> pk.GetAddress(ScriptPubKeyType.Legacy, Network.Main);;
val it: BitcoinAddress =
1Jhk2DHosaaZx1E4CbnTGcKM7FC88YHYv9
{Hash = c22eb0572ca07b9db7eff8ae5447f68d17f63535;
Network = Main;
ScriptPubKey = OP_DUP OP_HASH160 c22eb0572ca07b9db7eff8ae5447f68d17f63535 OP_EQUALVERIFY OP_CHECKSIG;
Type = PUBKEY_ADDRESS;}
Let me translate the vulnerability report here: wasabi coinjoin client implementation had a bug that made it trust on the coordinator as samourai whirlpool does. The difference is that in Wasabi is was because a bug while in whirlpool it is by design.
It is from a centralized domain. The distribution mechanism is to be prepared to do it from wherever we want in case we need to.