Cashu Wallets — Final Scoring & Ranking

A sovereignty-first, Bitcoin/FOSS/privacy-maximalist evaluation (anti-capture / anti–Synthetic-Stack emphasis) across five Cashu ecosystem wallet surfaces. Primary protocol references: cashu.space, docs.cashu.space, and the Cashu NUTs spec (cashubtc.github.io/nuts).
As-of: 2026-02-28
Scale: 0–100 per criterion
Composite: weighted / 100

Method

Lens
This scoring reflects an intentionally strict lens: Bitcoin-only, free/open software, privacy-first operation, and resistance to capture vectors (app stores, hosted APIs, centralized identity providers, browser telemetry surfaces, and forced update channels).
Scope
Wallet surfaces evaluated: Cashu Nutshell (CLI), CDK CLI wallet, Harbor, Cashu.me, Minibits.
Composite score
Weighted sum of criteria scores (weights sum to 100%).
Formula
Composite = Σ (weightᵢ × scoreᵢ) / 100
Interpretation note
Differences of ~1–2 points can be treated as noise; the main signal is the tiering produced by substrate choices (CLI vs desktop vs web vs mobile) and by explicit capture hooks (OIDC/Keycloak, hosted npubcash APIs, app-store distribution, OTA update pipelines).

Criteria & Weights

Weights are fixed; sub-factors below are explicitly included where relevant. Core protocol background: The Cashu Protocol and the Cashu NUTs spec (NUTs index).

Criterion Weight Meaning (strict lens) Key sub-factors explicitly considered
C1 — Bitcoin / Ecash Purity 10% BTC-native ecash focus; avoidance of altcoins and synthetic abstractions. Protocol fidelity; “units”/UI abstractions (e.g., USD/EUR units) when documented (see Cashu.me release notes and CDK CLI features).
C2 — FOSS & Stack Purity 15% License openness; auditability; ease of forking; avoidance of proprietary runtimes. Build chain (cargo vs npm vs mobile toolchains); dependency heaviness; self-build feasibility (see Cashu.me build instructions).
C3 — Privacy & Metadata Surface 25% Realistic metadata leakage and attack surface in typical use. Tor enforcement vs optional; browser substrate; mobile OS + app-store telemetry; hosted domains; third-party services like npubcash (see CDK CLI docs).
C4 — Sovereign Deployability & Operator Control 15% Ability to run as infrastructure: headless operation, scripting, automation. CLI/daemon availability; self-host mint compatibility; API surfaces; multi-mint management; local-only storage (see Nutshell and CDK repos).
C5 — Anti-Capture / Anti-Synthetic Dependencies 15% Resistance to choke points and capture: app stores, hosted APIs, centralized identity providers. OIDC/Keycloak hooks (NUT-21); npubcash hosted API defaults; OTA update pipelines; domain dependence (Cashu.me hosted instance).
C6 — Composability & Automation 10% Integrability into larger stacks: APIs, CLI ergonomics, library reuse. CDK as a dev kit; Nutshell CLI + mint; presence/absence of external control surfaces in GUI wallets.
C7 — Maturity & Ecosystem Resilience 10% Release history, caution flags, ecosystem adoption, maintenance continuity. Explicit “early development / use with caution” warnings; major releases (Harbor v1.0.0); grants (OpenSats wave 16).
Primary protocol / capture-hook references (embedded into scoring)

Final Ranking

Composite scores are calculated with weights shown above. Each project name links to its primary upstream repository or site.

Rank Project Composite C1 C2 C3 C4 C5 C6 C7
1 Nutshell (CLI) 95.4 100979498929791
2 CDK CLI 94.3 100999197909987
3 Harbor 93.6 98969790968588
4 Cashu.me 84.3 100967685787589
5 Minibits 78.4 95947072628686
Composite calculation (exact)
Weights: C1=10, C2=15, C3=25, C4=15, C5=15, C6=10, C7=10
Example (Nutshell): (10×100 + 15×97 + 25×94 + 15×98 + 15×92 + 10×97 + 10×91) / 100 = 95.35 → 95.4

1) Nutshell (CLI)

Composite 95.4 / 100 Upstream cashubtc/nutshell
Reference Python wallet + mint for Cashu

Nutshell is a Chaumian ecash wallet and mint for Bitcoin Lightning based on the Cashu protocol (cashu.space, protocol docs). It is commonly treated as a reference stack due to the combined wallet + mint implementation in one repository (GitHub).

C1 Purity
100
C2 FOSS
97
C3 Privacy
94
C4 Deploy
98
C5 Anti-Capture
92
C6 Compose
97
C7 Maturity
91
Rationale (criterion-by-criterion)
  • C1 (100): BTC-native ecash implementation aligned with Cashu protocol spec (docs.cashu.space).
  • C2 (97): Open-source repository and tooling surface suitable for inspection/forking (GitHub).
  • C3 (94): CLI substrate avoids browser and app-store telemetry. Tor can be disabled in tests (see repo docs), so privacy is strong but not “hard-enforced at all times” (repo docs).
  • C4 (98): Wallet + mint in one stack enables sovereign deployment (mint run instructions and fake backend for testing are documented in repo) (repo docs).
  • C5 (92): Optional but explicit identity-provider hook: NUT-21 clear auth via OIDC providers such as Keycloak is documented inside the repository (NUT-21 Keycloak section; spec context: NUT-21, NUT-22).
  • C6 (97): CLI + mint pairing supports direct automation and integration into infra patterns (wallet + mint ops are first-class) (repo).
  • C7 (91): Explicit “experimental / not production-ready” disclaimer exists on PyPI (PyPI disclaimer snapshot). Concrete ecosystem security note: NVD records a DoS-class issue (CVE-2025-65548) referencing “nutshell before 0.18.0” (NVD, GitHub Advisory). Those facts cap “maturity” even with strong activity.
Key links (embedded, no appendix)

2) CDK CLI

Composite 94.3 / 100 Upstream cashubtc/cdk Docs cdk-cli (docs.rs)
Rust dev kit + CLI wallet

CDK (Cashu Development Kit) is a collection of Rust crates for Cashu wallets and mints and is explicitly marked as early development / API-changing (repo readme, cdk (docs.rs)). The CLI wallet documents multi-mint ops, token operations, Lightning support, Tor support (when built with feature), and npubcash integration (cdk-cli docs).

C1 Purity
100
C2 FOSS
99
C3 Privacy
91
C4 Deploy
97
C5 Anti-Capture
90
C6 Compose
99
C7 Maturity
87
Rationale (criterion-by-criterion)
  • C1 (100): Cashu protocol core implementation for BTC-native ecash apps (protocol docs).
  • C2 (99): Rust + MIT licensing and modular crates increase auditability and long-term stack purity (repo).
  • C3 (91): Strong CLI substrate; Tor can be “on by default” when built with Tor feature, and can be disabled via --tor off (docs.rs). Privacy is reduced by default-enabled npubcash feature and its polling/hosted server assumptions (see below).
  • C4 (97): CDK is designed for composable infra: crates + CLI wallet + mint daemon patterns (repo overview).
  • C5 (90): NpubCash integration is explicitly documented as enabled by default and defaults to https://npubx.cash (npubcash docs section), including a workflow that polls a hosted server (subscribe polls every 5 seconds per docs). This creates a capture/metadata surface even if optional.
  • C6 (99): Dev kit architecture + CLI + crates create maximal composability for custom sovereign stacks (repo).
  • C7 (87): Explicit early-development warning exists in docs (“use amounts you don’t mind losing”) (docs.rs warning). Sustainability signal: OpenSats lists CDK as a first-time grant in the Sixteenth Wave (published Feb 4, 2026) (OpenSats wave 16).
Key links (embedded, no appendix)

3) Harbor

Composite 93.6 / 100 Repo HarborWallet/harbor Site harbor.cash
Tor-only desktop privacy chassis (Cashu + Fedimint)

Harbor is positioned as an ecash desktop wallet for better Bitcoin privacy with explicit focus on Tor-only networking, multi-mint distribution, and automation (Mutiny blog announcement, GitHub repo, harbor.cash). Harbor reached a signed v1.0.0 release in August 2025 (release page).

C1 Purity
98
C2 FOSS
96
C3 Privacy
97
C4 Deploy
90
C5 Anti-Capture
96
C6 Compose
85
C7 Maturity
88
Rationale (criterion-by-criterion)
  • C1 (98): Focused on Bitcoin ecash, supporting Cashu and Fedimint; no altcoin surface, but multi-protocol ecash support reduces “single-protocol purity” (Mutiny blog).
  • C2 (96): Open-source desktop wallet in Rust; larger UI stack yields a modest complexity deduction vs CLI primitives (repo).
  • C3 (97): Explicit design target: “Harbor will be Tor-only and will not depend on other network connections for anything besides the ecash mints” (announcement, privacy section). Desktop substrate is still OS-dependent, but network posture is maximally strict.
  • C4 (90): Desktop application is less infra-native than CLI/mint toolkits, though it explicitly pursues long-interval automation and “always-online devices” use cases (automation section).
  • C5 (96): Tor-only + “no dependencies on centralized coordinators or even the developers” is an explicit longevity goal (privacy section). App-store chokepoints are avoided by being desktop-first.
  • C6 (85): Automation exists inside the app, but an explicit CLI/API surface is not the primary interface (contrast with Nutshell/CDK). Repo focus is a GUI tool (repo).
  • C7 (88): v1.0.0 release exists and is signed/verified on GitHub (releases). Early history includes explicit “not ready for mainnet yet” notes in the 2024 announcement, consistent with cautious maturity scoring (roadmap / mainnet note).
Key links (embedded, no appendix)

4) Cashu.me

Composite 84.3 / 100 Repo cashubtc/cashu.me Hosted cashu.me
PWA / browser wallet surface

Cashu.me is a Chaumian ecash wallet for Bitcoin built as a progressive web app (PWA), MIT-licensed, with a documented first release (0.1) (GitHub release 0.1). The repo includes one-liner docker bring-up and PWA build instructions (repo README).

C1 Purity
100
C2 FOSS
96
C3 Privacy
76
C4 Deploy
85
C5 Anti-Capture
78
C6 Compose
75
C7 Maturity
89
Rationale (criterion-by-criterion)
  • C1 (100): Cashu protocol wallet surface; release notes position it as Bitcoin ecash and mention multiple units (Bitcoin + USD) backed by Bitcoin (0.1 release notes).
  • C2 (96): MIT-licensed repo with reproducible build steps (npm/quasar) and docker compose instructions (repo README).
  • C3 (76): Browser/PWA substrate is inherently high-surface: web PKI + browser telemetry and fingerprinting risks; release notes also warn ecash is bearer and recommend small spending amounts (0.1 caution section).
  • C4 (85): Self-hosting and local deployment are possible via docker and PWA builds, but the interface is UI-first, not infra-first (docker + build instructions).
  • C5 (78): Default use relies on a hosted domain (cashu.me). Capture risk is reduced by FOSS/self-hosting, but browser platform dependencies remain.
  • C6 (75): Function-rich UI surface (animated QR, offline send/receive, P2PK locking, Nostr discovery, NWC) is documented in release notes (0.1 features list); composability is less direct than CLI/SDK toolchains.
  • C7 (89): Matured as a widely referenced default web wallet; first release is signed/verified on GitHub, and ongoing issues/PR activity exists (releases, issues).
Key links (embedded, no appendix)

5) Minibits

Composite 78.4 / 100 Repo minibits-cash/minibits_wallet Tor helper Orbot
Mobile wallet surface with app-store + hub/OTA vectors

Minibits is an ecash and Lightning wallet exploring Bitcoin-backed ecash via Cashu protocol and Lightning Network (repo README). The README explicitly describes the wallet as early beta, research-use, and warns against holding large amounts (warnings section).

C1 Purity
95
C2 FOSS
94
C3 Privacy
70
C4 Deploy
72
C5 Anti-Capture
62
C6 Compose
86
C7 Maturity
86
Rationale (criterion-by-criterion)
  • C1 (95): BTC-backed ecash focus, but documented “multiple currency units issued by mints” introduces a mild abstraction layer in typical UX (README “Mints” section).
  • C2 (94): Open-source project, but mobile tooling (React Native, store signing, device constraints) increases build-chain complexity (repo).
  • C3 (70): Privacy depends on mobile OS hygiene and optional Tor routing. The README states that own Tor daemon connectivity was discontinued from v0.1.7 and that mint connections can be done using Orbot (Orbot / Tor daemon notes; Orbot upstream: guardianproject/orbot-android). Mobile substrate inherently leaks more metadata than CLI/desktop Tor-only models.
  • C4 (72): Mobile-first wallet is not infra-first; README shows explicit server/hub environment variables (API host, relay URL, mint URL) (.env variables section).
  • C5 (62): Capture/chokepoint surfaces: app-store distribution paths and the presence of OTA updates (even if opt-in) are explicitly listed (DevOps section (OTA updates)), plus server/hub/relay dependencies implied by configuration variables.
  • C6 (86): Strong functionality and integration surfaces (ecash + LN flows, offline/QR workflows, Nostr-related addressing features are described in README) (feature lists).
  • C7 (86): Active development and ongoing releases (example: latest beta release listing) (releases), while still clearly marked “beta/research-use” in README (maturity capped) (warnings section). Sustainability signal: OpenSats wave 16 lists a Minibits Wallet grant renewal (Feb 4, 2026) (OpenSats wave 16).
Key links (embedded, no appendix)

Structural Takeaways

Tier structure
  • Infrastructure-grade primitives: Nutshell and CDK CLI lead because CLI/SDK substrates minimize web/app-store capture surfaces while maximizing operator control.
  • Desktop privacy chassis: Harbor leads on strict privacy posture via an explicit Tor-only design goal (source), but is less infra-composable than CLI toolkits.
  • Edge/web/mobile surfaces: Cashu.me and Minibits offer broad UX reach, but incur substrate and capture penalties: browser/PWA domain dependencies (Cashu.me release notes) and mobile store/OTA/server vectors (Minibits README).
Where the biggest penalties came from
  • Centralized identity hooks: Nutshell documents clear authentication via OIDC providers such as Keycloak (NUT-21/NUT-22 context) (repo section, NUT-21).
  • Hosted API defaults: CDK CLI documents npubcash feature enabled by default and a default server URL (npubx.cash) (docs.rs npubcash section).
  • Browser/PWA substrate: Cashu.me’s own release notes emphasize bearer-asset risk and small-amount usage (0.1 release notes).
  • Mobile OS + OTA + hub vectors: Minibits documents OTA updates (opt-in), Orbot routing, and server/relay configuration variables (Minibits README).
Maintenance & funding signals (non-binding, but relevant)
  • OpenSats Sixteenth Wave (published Feb 4, 2026) lists CDK as a first-time grant and renewals for Nutshell and Minibits (OpenSats wave 16). These signals support resilience but do not remove substrate/capture risks.