Fedimint / Ecash Stack — Final Ranking, Scoring, Analysis

Lens & Scope

This analysis treats Bitcoin as the only monetary base layer, treats free/open-source software as non-negotiable, and treats privacy as a structural requirement (protocol privacy + network privacy + metadata minimization).

The evaluation is also explicitly capture-aware: it penalizes centralized distribution chokepoints, default steering toward “official” infrastructure, and ecosystem entanglements that can turn user experience into a policy lever.

Final Rankings

Criteria & Weights (final)

Ten criteria; each project is scored 0–100 per criterion. Composite score is the weighted sum. Platform risk and key/recovery factors are folded into deployability, capture-resistance, and guardian/automation safety.

Raw Scores & Composites

Scores are 0–100 per criterion. Composite scores are weighted using the table above.

Project Deep Dives

Each project section includes primary links inline (repo, releases/tags where applicable, ecosystem listings, and notable references), followed by the scoring rationale aligned to the criteria above.

Vipr is a modern Progressive Web App wallet for Fedimint, implemented in the open as ngutech21/vipr-wallet. It is listed as a beta-stage open-source PWA wallet on the Fedimint Wallets page and on awesome-fedimint.

Notable ecosystem reference: Fedimint’s H1 2025 ecosystem review explicitly highlights Vipr as a new wallet built using the Fedimint WebSDK and mentions Nostr-based mint discovery via NIP-87 (Fedimint’s post: Fedimint’s Ecosystem: A Look Back at 2025’s First Half).

Primary links

• Repository: github.com/ngutech21/vipr-wallet
• Fedimint listing: fedimint.org/wallets
• Ecosystem list: awesome-fedimint → Wallets
• WebSDK: fedimint/fedimint-web-sdk
• NIP-87 reference: nostrhub.io/87 (PR discussion reference: nostr-protocol/nips#1110)

Scoring rationale (high-signal)

Sovereign Deployability — 83
PWA architecture is trivially self-hostable and can be deployed from source on sovereign infrastructure; however, browser-based delivery inherits JS supply-chain and client fingerprinting risks unless hardened and pinned.

Ecash / Protocol Privacy — 88
Fedimint ecash foundation with multi-federation features; protocol privacy is strong when paired with disciplined mint selection and distribution.

Network / Transport Privacy — 65
No explicit Tor-by-default posture in primary docs; network privacy depends on the browser environment (e.g., routing via Tor Browser) and host configuration.

Bitcoin / FOSS Purity — 96
Open-source, AGPL-3.0; Bitcoin/ecash oriented and aligned with FOSS enforcement through copyleft.

Stack Composability / Automation Hooks — 72
Strong internal developer substrate via the WebSDK, but the application itself is primarily a GUI wallet rather than a daemon/API boundary.

Ghost-Forkability & Dev Ergonomics — 90
Web stack forkability is exceptional; branding, deployment, and iterative modification are comparatively low-friction.

Maturity & Resilience — 74
Active repo with tooling and testing signals, but publicly framed as beta and the ecosystem listings caution about incomplete features/bugs.

UX Clarity & Structural Transparency — 85
Strong bias toward exposing federation/guardian structure and onboarding mechanics rather than hiding everything behind a single balance.

Synthetic-Stack Proximity / Capture Resistance — 87
Independent project positioning + strong forkability provide an exit hatch if ecosystem pressures arise; however, the underlying Fedimint substrate remains shared protocol risk.

Guardian Topology & Automation Safety — 83
Multi-federation orientation supports distribution strategies; the main risk is that discovery layers (e.g., Nostr mint discovery) can become correlation surfaces if defaults are not carefully controlled.

Harbor is an ecash desktop wallet focused on privacy, built in Rust, integrating Fedimint and Cashu ecosystems. The project is maintained as HarborWallet/harbor and is referenced on awesome-fedimint and awesome-cashu.

The public project site harbor.cash emphasizes Tor-first networking, and external ecosystem coverage includes Mutiny’s announcement and a detailed write-up at NoBsBitcoin.

Primary links

• Repository: github.com/HarborWallet/harbor
• Releases: github.com/HarborWallet/harbor/releases
• Project site: harbor.cash
• Fedimint ecosystem list: awesome-fedimint → Wallets
• Cashu ecosystem list: awesome-cashu → Wallets
• External coverage: Mutiny Blog, NoBsBitcoin

Scoring rationale (high-signal)

Sovereign Deployability — 92
Desktop binaries + MIT licensing + public releases support sovereign distribution patterns and reduce dependency on mobile app stores.

Ecash / Protocol Privacy — 92
Multi-ecash posture (Fedimint + Cashu) reduces monoculture risk and enables privacy strategies across mint sets.

Network / Transport Privacy — 95
Tor-first posture is central in Harbor’s public framing (site and ecosystem coverage); network metadata minimization is treated as a design requirement.

Bitcoin / FOSS Purity — 95
MIT-licensed, ecash/Bitcoin oriented; no alt-asset orientation.

Stack Composability / Automation Hooks — 77
Strong operational features (including automation concepts), but the primary interface is a desktop GUI rather than a universal API daemon.

Ghost-Forkability & Dev Ergonomics — 78
Forkable (MIT), but Rust GUI stacks and build tooling are higher-friction than a web PWA fork.

Maturity & Resilience — 84
Clear release history (including v1.0.0) and multi-contributor development indicates real stabilization compared to beta-stage clients.

UX Clarity & Structural Transparency — 82
Explicit intent to demystify ecash mints and make structure visible; supports serious operator understanding.

Synthetic-Stack Proximity / Capture Resistance — 85
Tor-only orientation + multi-ecash diversity + local app model are structurally resistant to centralized steering, though ecosystem funding narratives should still be treated as potential vectors.

Guardian Topology & Automation Safety — 85
Multi-mint distribution strategies are explicit; automation is valuable but must remain transparent and overrideable under adversarial mint conditions.

Ecash App is an open-source Fedimint wallet under the Fedimint GitHub organization. It is built with Flutter (UI) and Rust (bridge), aiming for high structural transparency: fees, gateways, federation UTXOs, and ecash denominations are explicitly surfaced.

Distribution and marketing references include the Fedimint Wallets page (fedimint.org/wallets) and the dedicated landing page repository (fedimint/ecash-app-site), which points to APK downloads.

Primary links

• Repository: github.com/fedimint/ecash-app
• Releases (latest shown as v0.5.0): github.com/fedimint/ecash-app/releases
• Fedimint listing: fedimint.org/wallets
• Landing site repo (APK): fedimint/ecash-app-site
• Fedimint docs: docs.fedimint.org

Scoring rationale (high-signal)

Sovereign Deployability — 83
Fully open-source with APK-oriented distribution references; however, mobile platform realities increase ambient surveillance pressure compared to desktop/daemon deployments.

Ecash / Protocol Privacy — 90
First-class Fedimint wallet with comprehensive feature surface; protocol privacy is strong within Fedimint’s model.

Network / Transport Privacy — 68
No explicit Tor-by-default commitment in primary materials; network privacy depends on OS-level routing hardening rather than enforced defaults.

Bitcoin / FOSS Purity — 95
MIT license, Bitcoin/ecash oriented.

Stack Composability / Automation Hooks — 70
GUI wallet posture; composability is secondary relative to infra daemons and API-focused components.

Ghost-Forkability & Dev Ergonomics — 74
MIT license supports forking, but Flutter+Rust toolchain complexity is non-trivial compared to a PWA fork.

Maturity & Resilience — 93
Clear ongoing release cadence (e.g., v0.5.0 on the releases page) under the official org suggests strong continuity.

UX Clarity & Structural Transparency — 92
Best-in-class structural UI: fees, gateways, federation UTXOs, and denominations are explicitly exposed in the project’s own description.

Synthetic-Stack Proximity / Capture Resistance — 69
Official-org proximity increases risk of default steering and “recommended infra” nudging becoming a control surface; open source provides an exit hatch, but the gravitational center is closer than indie wallets.

Guardian Topology & Automation Safety — 80
Strong visibility into federation structure; the remaining risk is centralized default selection patterns (gateways/federations) if UX ever shifts toward “safe defaults” that become policy levers.

fedimint-clientd is a server-side Fedimint client daemon designed for programmatic integration: it runs a Fedimint client (ecash, Lightning, on-chain) and exposes a REST API with wrappers for multiple languages. It uses a multimint layer to manage clients across multiple federations from a single instance.

Primary repo reference: fedimint/fedimint-clientd. Note on release signaling: GitHub shows no “Releases” page publications (releases), but version tags exist (e.g., v0.3.3) on the tags page.

Primary links

• Repository: github.com/fedimint/fedimint-clientd
• Tags (version tags): github.com/fedimint/fedimint-clientd/tags
• Releases page (currently empty): github.com/fedimint/fedimint-clientd/releases
• Fedimint technical reference: docs.fedimint.org

Scoring rationale (high-signal)

Sovereign Deployability — 96
Daemon-first architecture is natively sovereign: deployable on private servers, homelabs, and constrained nodes without app-store gatekeepers.

Ecash / Protocol Privacy — 93
Full Fedimint client posture; privacy derives from protocol + disciplined federation selection.

Network / Transport Privacy — 87
Transport privacy is operator-controlled: the daemon can be routed through Tor/VPN/LAN-only overlays. The absence of enforced defaults is treated as neutral in infra contexts (where policy is deployment-level).

Bitcoin / FOSS Purity — 95
MIT license and Bitcoin/ecash orientation.

Stack Composability / Automation Hooks — 98
The core differentiator: REST API boundary plus language wrappers enable clean integration into sovereign systems (services, merchants, agents, automation).

Ghost-Forkability & Dev Ergonomics — 86
MIT licensing + clean daemon posture make it structurally forkable; the cost is operational sophistication rather than legal or architectural constraints.

Maturity & Resilience — 86
Multi-language wrapper surface and maintained integration intent are strong maturity signals. Tag-based versioning exists; GitHub “Releases” are not currently published (tags are used instead).

UX Clarity & Structural Transparency — 60
Human-facing UX is absent by design; clarity is achieved via API schema, metrics, and deployment discipline.

Synthetic-Stack Proximity / Capture Resistance — 72
Official-org infra proximity means protocol-level capture pressure hits early; open source + forkability provide the escape hatch.

Guardian Topology & Automation Safety — 82
Multimint architecture supports distribution strategies; the main risk is not the daemon itself but how upstream defaults and operator configuration harden (or fail to harden) federation selection and key management.

Implementation Notes

A few ecosystem tensions remain relevant regardless of wallet choice:

• Ecosystem listing staleness: awesome-fedimint may describe projects in “early” or “signet-only” terms even when project release pages show later maturity; always cross-check against the project’s releases or releases.
• Discovery layers as correlation surfaces: Nostr mint discovery (e.g., NIP-87) can improve onboarding but can also amplify metadata leakage if default relays or public identity bindings are not controlled.
• Protocol vs client capture: All Fedimint clients share protocol-level risk. Differences in capture-resistance mostly come from distribution chokepoints, default steering, and forkability. Reference: Fedimint Wallets.
• Cross-ecash diversity: Harbor’s explicit inclusion in both awesome-fedimint and awesome-cashu indicates a multi-protocol posture that reduces monoculture dependency.