# WalletWasabi: a desktop Bitcoin wallet built around CoinJoin and Tor

> Wasabi is a non-custodial desktop Bitcoin wallet in C#, MIT licensed, with CoinJoin and Tor in its topic list and a solution file split across client, backend, coordinator and daemon. The README covers building from source and little else.

**WalletWasabi/WalletWasabi** — Open-source, non-custodial, privacy preserving Bitcoin wallet for Windows, Linux, and Mac.

- Repository: https://github.com/WalletWasabi/WalletWasabi
- Website: https://wasabiwallet.io
- Stars: 2,621 · Forks: 570
- Language: C#
- License: MIT
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/walletwasabi-walletwasabi

## A solution file that names five separate applications

The first thing the repository tree tells you is that WalletWasabi is not one application. The top level lists `WalletWasabi/`, the core library, then `WalletWasabi.Client/`, `WalletWasabi.Fluent/`, `WalletWasabi.Fluent.Desktop/`, `WalletWasabi.Daemon/`, `WalletWasabi.Coordinator/` and `WalletWasabi.Backend/`. Alongside those sit `WalletWasabi.IntegrationTests/`, `WalletWasabi.Tests/`, `WalletWasabi.WindowsInstaller/` and a `WalletWasabi.Fluent.Generators/` project, plus `WalletWasabi.Documentation/` and the solution file `WalletWasabi.slnx`.

Reading that list gives you the architecture without opening a file. There is a GUI, a daemon, a coordinator, a backend and a core library, and the coordinator being a separate project is the tell that CoinJoin coordination is treated as infrastructure rather than as a feature bolted onto the wallet. The tests are split the same way, with an integration test project distinct from the unit test project.

The repository topics line up with that: bitcoin, wallet, privacy, coinjoin, wabisabi, tor and nbitcoin, alongside cross-platform and dotnet. GitHub reports the project as C#, MIT licensed, not archived, last pushed 2026-09-24, with v2.8.3 published 2026-09-14, v2.8.2 on 2026-08-29 and v2.8.1 on 2026-07-22. That is three releases in about ten weeks.

## Building from source needs Git, the .NET 10 SDK and one folder

The README gives three requirements and a three-step sequence. Get Git from git-scm.com, get the .NET 10.0 SDK from Microsoft, and optionally set `DOTNET_CLI_TELEMETRY_OPTOUT` in your terminal. Then clone, enter one subfolder and build:

```sh
git clone --depth=1 --single-branch --branch=master https://github.com/WalletWasabi/WalletWasabi.git
cd WalletWasabi/WalletWasabi.Fluent.Desktop
dotnet build
```

The shallow clone with `--depth=1` is worth noting. It fetches one commit of the `master` branch rather than the history, which suits a source build where you only want to run the current tree. The `cd` into `WalletWasabi.Fluent.Desktop` matters just as much: the solution spans eight projects, and building from the root would build the daemon and coordinator too.

After that, `dotnet run` from the same `WalletWasabi.Fluent.Desktop` folder launches the wallet, and `git pull` is the documented update path. Because the clone is shallow, that pull is a fast-forward against a single branch rather than a rebase across years of commits. The telemetry opt-out line is the only configuration in the entire build instructions, which tells you how little there is to set up.

## Two documents that govern a wallet: SECURITY.md and PGP.txt

A repository that handles private keys earns the right to carry a security policy, and this one does. `SECURITY.md` and `PGP.txt` both sit at the repository root, next to `CONTRIBUTING.md`, `NOTICE.md` and `LICENSE.md`. `BannedSymbols.txt` and `exclusion.dic` are there too, which in a wallet codebase usually means the spell checker has been told about words that must never be corrected, a small signal about how seriously the string and text handling is taken.

The build system is pinned in a way that suggests the same attention. `Directory.Packages.props` and `Directory.Build.props` sit beside `global.json`, so the .NET SDK version and the NuGet package versions are both centrally managed rather than drifting per project. `NuGet.Config` is present as well, and `deps.json`, `flake.nix` and `flake.lock` show a Nix definition alongside the .NET build, so reproducible dependency trees are a stated goal rather than an accident.

None of this is a claim that the code is safe. What it does establish is that the project takes supply chain and reproducibility seriously enough to pin a SDK version, manage packages centrally, and ship a Nix flake, which is more than most desktop wallets document at their root.

## What the README does not tell a Bitcoin user

The README is, in fairness, honest about its shape. It carries a logo, a one line description as an open-source, non-custodial, privacy-focused Bitcoin wallet for desktop, and a row of links to the website, the documentation site, a support discussion, a YouTube channel and the PGP key. Then there is a single call to action: download Wasabi, pointing at the releases page.

What is absent is everything a user would want before depositing money. There is no statement of which Bitcoin implementations are supported, no description of how the coin mixing is scheduled, no account recovery discussion, no explanation of what data the coordinator or backend hold, and no fee model. The project does carry a `WalletWasabi.Documentation/` directory, so the answers exist somewhere in the tree, but they are not on the page a reader reaches from the repository.

The coordinator and backend projects are the part to think hardest about. A wallet that mixes transactions needs someone to coordinate rounds, and running that as a separate service means your privacy properties depend on a component outside the wallet process. Whether the coordinator is operated by the project or by you is not answered in the README, and for a privacy tool that is not a detail to gloss over. Check the documentation site and the release notes for v2.8.3 before forming a view.

## Where Wasabi sits against the other desktop wallets

The comparison worth making is not against custodial services, where the trust models differ so much that the choice is not really a judgement call. It is against other self-custodial desktop wallets, and on one axis Wasabi is unusual: CoinJoin and Tor are topics in the repository, so privacy is implemented in the product rather than deferred to a plugin or a manual page.

That has a cost. A wallet that mixes by default changes what a transaction looks like, which changes confirmation behaviour, which changes how you should think about replacement fees and what happens when a mixing round is interrupted. Anyone used to a wallet that simply builds and broadcasts a transaction will have a learning curve here that a wallet without a mixing layer does not impose.

The other axis is reach. The description says Windows, Linux and Mac, and the tree has a `WalletWasabi.WindowsInstaller/` project, so Windows has first class packaging while the other two platforms are served by the Fluent desktop project and whatever the release page provides. There is no Android or iOS project in the tree. If you need a phone wallet, this repository is not it, and no amount of privacy focus changes that.

## Following the Fluent projects and the generator

Two details in the tree explain why the release cadence looks the way it does. `WalletWasabi.Fluent.Generators/` is a source generator project, which in a C# desktop app usually means repetitive UI definition work is generated at compile time rather than hand written, and `WalletWasabi.Fluent/` sits next to `WalletWasabi.Fluent.Desktop/` as the host for that UI. When a change lands in the generator, it lands everywhere the Fluent surface is used at once, which is the sort of coupling that makes small releases safe and large ones risky.

`WalletWasabi.IntegrationTests/` next to `WalletWasabi.Tests/` is the other one. A split between fast unit tests and slower integration tests is normal, but in a wallet it usually implies tests that start real services, and the coordinator and backend projects give them something to start.

Taken together with the push date of 2026-09-24 and v2.8.3 on 2026-09-14, the picture is a project with active work on a mature desktop codebase and a documentation split across a separate `WalletWasabi.Documentation/` project and an external site. For an evaluation, the practical sequence is short: read the releases page for what changed in v2.8.x, check the documentation site for the coordinator question, and only then decide whether the privacy features justify the extra operational surface.

## Conclusion

WalletWasabi is a defensible choice for a desktop user who wants coin mixing as a default rather than an add-on, and a poor fit for someone who needs a mobile wallet or a hardware signer workflow that the repository does not describe. GitHub reports the last push on 2026-09-24 with v2.8.3 released 2026-09-14, so the desktop line is actively worked. Start from the official binaries rather than a source build, and read the documentation site before trusting the client with a balance you cannot replace.

## FAQ

### How safe is a Wasabi wallet?

Wasabi is described as open-source, non-custodial and privacy-focused, with the code, the licence and the security policy all public in the repository, and the MIT licence lets anyone audit it. It also runs a coordinator and a backend as separate projects, so parts of the privacy story live outside the wallet process. The README does not describe key recovery, so that question belongs to the documentation site rather than the repository page.

### Which platforms does WalletWasabi build for?

The description names Windows, Linux and Mac for the desktop wallet, and the source build steps target the `WalletWasabi.Fluent.Desktop` project with the .NET 10.0 SDK. The tree contains a `WalletWasabi.WindowsInstaller/` project but no Android or iOS project, so mobile is not covered here.

### What does the CoinJoin coordinator do in this repository?

Coin mixing is a repository topic and `WalletWasabi.Coordinator/` is a separate project in the solution, alongside the client, daemon, backend and core library. The README does not say who operates a coordinator or what data it holds, so treat that as a question for the documentation site before relying on the mixing behaviour.

## Sources

- [License: MIT](https://github.com/WalletWasabi/WalletWasabi/blob/master/LICENSE)
- [Project website](https://wasabiwallet.io)
- [README](https://github.com/WalletWasabi/WalletWasabi/blob/master/README.md)
- [Releases](https://github.com/WalletWasabi/WalletWasabi/releases)
- [WalletWasabi/WalletWasabi on GitHub](https://github.com/WalletWasabi/WalletWasabi)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/walletwasabi-walletwasabi