Desktop Bitcoin Wallet Audit — Final Scoring, Ranking & Rationale

A desktop-wallet–only evaluation of eight Bitcoin-only, open-source wallets that passed strict sovereignty, privacy, and resilience filters. This page documents the scoring model, the final composite ranking, and the per-wallet rationale with inline primary-source links.

Scope Desktop wallets only Gating Bitcoin-only + FOSS + self-custody Scale 0–100 per criterion Output Weighted composite (0–100)

1) Method

All candidates already satisfy the gating constraints: Bitcoin-only, open-source licensing, and self-custody architecture. The scoring below differentiates verification trust model, privacy tooling, policy expressiveness, service dependence, security maturity, hardware ecosystem, and usability across beginner → advanced operators.

Composite formula
Composite = Σ(scoreᵢ × weightᵢ). Weights sum to 100%.

Service / platform dependence (SD) is explicit here: 100 means the wallet’s core workflows function without vendor accounts, vendor servers, or “guardian” services. Optional services reduce SD when they are central to typical workflows or heavily marketed as the default path.

2) Weights

SV — Sovereign VerificationBackend trust model (full node vs SPV/public servers)
20%
PR — Privacy ModelOn-chain + network privacy tooling & defaults
20%
SR — Script / Recovery / ResilienceMultisig, Miniscript, timelocks, inheritance, portability
18%
SD — Service DependenceVendor/cloud reliance and chokepoint surface
14%
SE — Security / MaturityReview depth, reproducible builds, incident history
12%
HW — Hardware & AirgapPSBT/QR/SD flows, signer breadth, reliability
8%
UX — UX Across UsersBeginner survivability + advanced transparency
8%

3) Final Results

Composite scores are weighted by the model above. The table links each wallet to its official site, documentation, and source repositories.

Rank Wallet Composite SVPRSRSDSEHWUX
#1
Specter Desktop Node-centric coordinator Hardware + multisig
Docs FAQ (v2.0 backend model) GitHub Bitcoin.org listing
91.6 94909095929880
#2
Sparrow Wallet Daily-driver desktop Privacy tooling
Official site Docs (Quick Start + Core connection) Privacy guide GitHub
91.0 90978595909682
#3
Liana Miniscript vault Timelocks + inheritance
Official site GitHub Changelog (managed bitcoind / Connect) Safety Net explainer
88.6 939010070889080
#4
Bitcoin Core Reference full node Minimal wallet UI
Official site GitHub Guix-based release builds Guix attestations Descriptors
84.3 10078751001006055
#5
Electrum Veteran SPV Power-user tool
Official site GitHub Tor documentation Electrum Personal Server Phishing incident analysis
83.2 82788290869475
#6
JoinMarket (JoinMarket + Jam) Decentralized CoinJoin Specialist privacy engine
Docs GitHub USAGE (Bitcoin Core requirement) Jam GitHub Jam docs
82.9 1001007095924035
#7
Nunchuk Multisig + inheritance Service-oriented UX
Official site libnunchuk Desktop repo Group Wallet (E2EE model) Inheritance Autonomous inheritance
82.2 85789555869388
#8
Bitcoin Knots Core derivative Policy knobs
Official site GitHub org Guix attestations model (Core reference) Knots popularity + filtering debate OCEAN block template selection Block template policies explainer
81.9 1007078100926050

Note The score table is intentionally verbose with direct links. No “appendix dump”: sources are embedded where the claims appear.

4) Wallet Deep Dives (Rationale)

Each entry includes (a) role framing, (b) criterion-by-criterion rationale, and (c) inline links to the most relevant primary sources.

Specter Desktop #1 — 91.6
Node-centric coordinator Hardware-first multisig Watch-only + PSBT workflows
  • SV (94) — Encourages pairing with a self-hosted Bitcoin Core node or a self-hosted Electrum server; since v2.0 it can also use public Electrum servers, which reduces “hard-node-only” purity. Refs: FAQ, docs.
  • PR (90) — Strong baseline privacy via local-node verification and coin control; lacks native CoinJoin tooling and does not focus on PayJoin/BIP47 flows. Refs: Bitcoin.org feature summary.
  • SR (90) — Excellent multisig coordination (descriptors + PSBT) as a desktop controller for multiple signers; policy expressiveness is strong even without Miniscript templates. Refs: Descriptors, BIP174 (PSBT).
  • SD (95) — No required vendor account for core operation; backend choice remains operator-controlled (Core RPC or Electrum server). Refs: FAQ.
  • SE (92) — Mature project with public code, long usage history, and visible release process. Refs: Releases.
  • HW (98) — Broad hardware support and a design optimized for multi-hardware coordination (PSBT workflows and air-gapped signers). Refs: Bitcoin.org listing.
  • UX (80) — Strong clarity for serious operators; entry friction increases when a local node or dedicated server is required. Refs: Bitcoiner.Guide, RaspiBolt guide.
Sparrow Wallet #2 — 91.0
Privacy-focused daily desktop Deep coin control Hardware-friendly
  • SV (90) — Supports full-node privacy by connecting to Bitcoin Core via a local Electrum server; the Quick Start explicitly covers public-server setup first. Refs: Docs overview, Connect to Core (if unavailable, use the docs index above).
  • PR (97) — Strong GUI privacy tooling: built-in Tor, advanced UTXO controls/labels, spending-privacy guides, and CoinJoin workflows in documentation. Refs: Feature list, Spending privately.
  • PR note (coordinator risk) — When CoinJoin is performed via coordinator-based systems (e.g., Whirlpool), censorship/availability risk is structurally different from decentralized orderbooks. Refs: Whirlpool post-mix notes, JoinMarket (contrast).
  • SR (85) — Solid multisig + PSBT + descriptor capabilities; not primarily an inheritance/miniscript-policy vault. Refs: BIP174 (PSBT), Descriptors.
  • SD (95) — No vendor account requirement; optional privacy features may introduce optional third-party dependencies, but the core wallet remains operator-controlled. Refs: Docs.
  • SE (90) — Reproducible-build instructions exist; deterministic reproduction is documented from v1.5.0 onward (pre-codesigning/installer packaging caveats apply). Refs: Reproducible builds.
  • HW (96) — Broad signer compatibility and smooth PSBT workflows (air-gapped devices well supported). Refs: Hardware setup guides.
  • UX (82) — Explicit design goal: “do not hide information,” with detailed UTXO and transaction transparency. Refs: Project statement.
Liana #3 — 88.6
Miniscript vault Timelocked recovery Inheritance-ready policies
  • SV (93) — Supports local verification with an internal/managed Bitcoin Core node option; configuration can be per-wallet (local node vs Connect). Refs: Changelog.
  • PR (90) — Full-node capability and modern script usage (Taproot descriptors); privacy is strong by architecture even without native CoinJoin tooling. Refs: Descriptors.
  • SR (100) — Miniscript + timelocks define the product: policy expressiveness for inheritance and loss protection is first-class. Refs: Miniscript spec, Liana repo.
  • SD (70) — Optional “Safety Net” and optional remote backend surfaces exist; the local-only mode remains the highest-sovereignty configuration. Refs: Safety Net design, Plans (Safety Net positioning).
  • SE (88) — Newer than Core/Electrum; nonetheless, public code and build attention are visible in the project’s engineering artifacts. Refs: GitHub.
  • HW (90) — Strong PSBT workflows; hardware breadth is solid though not the broadest in this set. Refs: Docs / issues / releases.
  • UX (80) — Templates reduce policy complexity; requires conceptual comfort with timelocks and recovery paths. Refs: Overview.
Bitcoin Core #4 — 84.3
Full validation substrate Most-reviewed codebase
  • SV (100) — Fully validating node + wallet, directly on the P2P network. Refs: Repo.
  • PR (78) — Strong baseline (local chain, no wallet-to-server leakage) but limited integrated privacy tooling compared to specialist wallets. Refs: Descriptors.
  • SR (75) — Descriptor wallets and PSBT support exist, but advanced scripting policy UX is minimal in the GUI. Refs: BIP174.
  • SD (100) — No vendor service dependency.
  • SE (100) — Guix-based reproducible releases and public signature attestations. Refs: Release notes (Guix builds), guix.sigs workflow.
  • HW (60) — Possible via external tooling and workflows; less ergonomic than dedicated hardware-oriented GUIs.
  • UX (55) — Conservative UI and initial sync friction reduce approachability as a “wallet app” compared to purpose-built desktop GUIs.
Electrum #5 — 83.2
SPV architecture Highly flexible
  • SV (82) — SPV by design; sovereignty improves when paired with a self-hosted server such as Electrum Personal Server. Refs: Electrum Personal Server.
  • PR (78) — Tor support is documented; privacy depends heavily on server selection and configuration. Refs: Tor docs.
  • SR (82) — Mature multisig/PSBT workflows; not miniscript-vault oriented. Refs: BIP174.
  • SD (90) — No vendor account requirement; however, server dependency is intrinsic to SPV.
  • SE (86) — Real-world phishing incidents exploited a weakness in how some servers could push malicious update messages; documented widely. Refs: Malwarebytes report, Electrum issue discussion.
  • HW (94) — Strong hardware signer integration across common devices. Refs: Electrum.
  • UX (75) — Powerful but sharp; default server model can be confusing for non-technical users.
JoinMarket (+ Jam) #6 — 82.9
Decentralized CoinJoin market Full-node required
  • SV (100) — Requires Bitcoin Core to operate (pruned node is supported); no SPV shortcut. Refs: USAGE.
  • PR (100) — Privacy-first design via CoinJoin as a market mechanism; no single centralized coordinator is required. Refs: Docs, Repo.
  • SR (70) — Script sophistication is transaction-privacy oriented rather than inheritance/policy-vault oriented.
  • SD (95) — No vendor account required; relies on network infrastructure for maker/taker coordination but not a single company-controlled platform.
  • SE (92) — Long-running project in the privacy niche; public development history.
  • HW (40) — Limited hardware integration compared with hardware-first desktop coordinators.
  • UX (35) — Jam improves usability, but the stack remains advanced-user territory (node + JoinMarket runtime + coordination). Refs: Jam, Jam docs.
Nunchuk #7 — 82.2
Multisig + inheritance platform E2EE collaboration
  • SV (85) — Supports either an Electrum server or a Bitcoin Core node backend; this is documented as a core backend choice. Refs: Backend options (0.9.7).
  • PR (78) — Coin control and privacy features exist, but collaboration layers can create metadata surfaces even when encrypted. Refs: Group Wallet (E2EE), Coin control, BIP329 labels.
  • SR (95) — Strong miniscript/timelock policy emphasis and “autonomous inheritance” positioning. Refs: Miniscript 101, Autonomous inheritance, Miniscript spec.
  • SD (55) — Many flagship flows are platform-shaped (group coordination, guided inheritance pathways, service-layer UX). The score reflects “platform gravity,” not key custody. Refs: Group Wallet, Inheritance.
  • SE (86) — Open-source core libraries exist (e.g., libnunchuk) with multi-year history; platform scale can also increase incentive for attack. Refs: libnunchuk, libnunchuk announcement.
  • HW (93) — Broad hardware signer support in the desktop client. Refs: Desktop repo.
  • UX (88) — Strong guided UX for multisig/inheritance setup compared to most peers.
Bitcoin Knots #8 — 81.9
Core derivative Extra policy knobs
  • SV (100) — Full validation on the P2P network (Core-derived). Refs: Knots site, GitHub org.
  • PR (70) — The privacy score is reduced due to the broader public debate around transaction filtering policies and how those policies may affect CoinJoin-like transactions and other “non-monetary” activity in some templates/policy sets. Refs: Filtering debate overview, Knots popularity & filtering, OCEAN template selection, Block template policy explainer.
  • SR (78) — Similar baseline capability to Core (descriptors, PSBT, multisig), but not a policy-vault UX. Refs: Descriptors (Core reference).
  • SD (100) — No vendor account or platform dependency.
  • SE (92) — Core-derived maturity plus additional patches; generally strong but below Core’s “most-reviewed” ceiling. Refs: Knots Bitcoin fork.
  • HW (60) — Similar “possible but not ergonomic” hardware flows as Core’s GUI.
  • UX (50) — More knobs increase cognitive load; desktop wallet UX remains conservative.

5) Alternate Ranking — Privacy/Fungibility Bias

A privacy-weighted lens (approx.): PR 50%, SV 30%, SD 20%. This view emphasizes decentralized CoinJoin and privacy tooling.

RankWalletWhy it rises
#1 JoinMarket — docs Decentralized CoinJoin market + full-node requirement.
#2 Sparrow — privacy guide Deep privacy controls in a GUI; optional coordinator-based CoinJoin paths.
#3 Specter — FAQ Node-centric verification + coin control baseline.
#4 Bitcoin Core — Guix builds Maximum verification; minimal privacy tooling.
#5 Liana — overview Strong architecture; focus is recovery policy more than mixing.
#6 Bitcoin Knots — filtering debate Debates about filtering policies weigh against privacy/fungibility orientation.
#7 Electrum — Tor docs SPV + server model increases metadata risk unless hardened.
#8 Nunchuk — group wallet Service-layer collaboration can create additional metadata surface.

6) Alternate Ranking — Resilience/Inheritance Bias

A resilience-weighted lens (approx.): SR 60%, SE 20%, SD 20%. This view favors miniscript/timelock policy expressiveness and survivable recovery.

RankWalletWhy it rises
#1 Liana — repo Miniscript + timelocks as first-class vault policy.
#2 Specter — docs Clean multisig coordination with minimal platform dependence.
#3 Nunchuk — autonomous inheritance Very strong policy tooling; SD becomes the limiting factor.
#4 Bitcoin Core — guix.sigs Security maturity ceiling; policy UX is minimal.
#5 Sparrow — site Generalist strength; not a dedicated inheritance vault.
#6 Electrum — EPS Powerful but SPV-by-design unless hardened with a personal server.
#7 Bitcoin Knots — site Core-derived; UX and policy posture remain contentious.
#8 JoinMarket — Jam Purpose-built for transactional privacy, not long-horizon inheritance policy.

7) Composition Patterns (How these tools commonly combine)

These are not “recommendations,” but observed archetypes that fall naturally out of the trade-offs in the score model. Each pattern links to the docs that explain the integration points.

Pattern A — Node + Multisig Coordinator

A full node provides verification; a coordinator provides multisig + hardware signing UX.

Pattern B — Daily Wallet + Privacy Engine

A general desktop wallet for day-to-day control; a specialist tool for high-privacy spending flows.

Pattern C — Inheritance / Timelock Vault

A policy vault where timelocks and recovery are encoded on-chain.

8) Key Protocol References (linked where used)

These are the protocol primitives repeatedly referenced in the scoring.

Privacy Protocols

Policy & Interop

Notes on interpretation
Back to top