CraysMutiny Wallet
Mutiny Wallet is best read as a serious open-source experiment in web Lightning, Nostr Wallet Connect, budgets, zaps, Fedimint and self-hosting. The hosted wallet is gone; the design lessons are not.
An archived wallet that still matters
Mutiny Wallet deserves a careful reading because it is both finished and unfinished. The hosted wallet was shut down, yet the ideas inside it still sit close to the center of Nostr payments: Nostr Wallet Connect, social zaps, wallet connections with budgets, payment requests over relays, Lightning addresses, Fedimint ecash and self-hostable wallet infrastructure. A reader looking for a wallet to install today should not treat Mutiny like a fresh app-store recommendation. A reader trying to understand Nostr money UX should absolutely study it.
The project's own timeline tells users what changed. Mutiny announced in August 2024 that the company would wind down the wallet, stop hosting the web app, remove mobile apps from Apple and Google distribution, and shut down supporting services. The September 2024 timeline told users to move funds out, close open Lightning channels, transfer any Fedimint balance and use self-hosting only if they wanted to keep running Mutiny under their own control.
That shutdown context is not a footnote. It is the first trust signal. Mutiny was a hot wallet, a Lightning node, a browser storage experiment, a Fedimint wallet and a Nostr payment endpoint. Those are not small operational promises. The strongest article about Mutiny is not a fan note and not an obituary. It is a map of what worked, what strained and what builders can still take from it.
The original wager was web self-custody
Mutiny began from an unusually bold product premise: compile enough of a Bitcoin Lightning wallet into a website that a user could run self-custodial payments from a browser. Bitcoin Magazine described the open beta as a web-accessible self-custodial Lightning wallet. No Bullshit Bitcoin's beta coverage highlighted on-chain and Lightning support, LSP support, LNURL Pay and Auth, backup and import, plus experimental Nostr Wallet Connect.
That browser-first decision solved one distribution problem and created several harder ones. It let Mutiny avoid some app-store friction and made onboarding as simple as opening a URL. It also meant the wallet had to live with browser storage, WebAssembly, IndexedDB, service workers, private browsing limitations, mobile browser behavior, device locks and the risk that users would treat a web tab like a normal custodial account.
The PWA manifest still captures the product shape: Mutiny Wallet, short name Mutiny, display standalone, categories finance and social, and app shortcuts for Send, Receive and Activity. The web app was not a marketing shell around a server wallet. It was a real client surface for a Rust and WebAssembly wallet stack, with native wrappers added later through Capacitor.
The shutdown explains the burden
Tony Giorgio's shutdown post is unusually candid about the operational cost. Mutiny had raised capital, shipped a mainnet-ready beta, served hundreds of daily active Lightning wallets and built several ambitious pieces: local-first multi-device Lightning state, Fedimint support, a hybrid Fedimint and self-custodial Lightning wallet, a federated Lightning address server, subscriptions, self-custody Nostr zaps, blinded authentication and a developer signet environment.
The same post says the team concluded that a consumer-facing wallet in that technical environment was not sustainable for the small company. That matters for readers because it separates two questions. Mutiny proved that a lot of the stack could be made to work. It did not prove that a small team could support that stack as a mass consumer wallet indefinitely.
The timeline later gave practical instructions rather than slogans. Move funds. Close channels early. Expect force-close delays from 3 to 14 days in some cases. Use the 12-word seed for on-chain funds. Transfer Fedimint balances elsewhere. Self-host if you are ready to run your own instance. That is the responsible framing for Mutiny in 2026.
NWC was a first-class wallet feature
Mutiny's strongest Nostr contribution was its Nostr Wallet Connect work. NWC lets apps request wallet actions over Nostr relays using encrypted request and response events. In practice, this means a Nostr client can ask a wallet to pay a Lightning invoice without importing the user's private wallet keys. Mutiny made that more than an experimental checkbox.
The Rust code in mutiny-core/src/nostr/nwc.rs defines NWC profiles with names, relays, enabled and archived state, allowed commands, labels, profile tags and spending conditions. The wallet can create NWC URI objects, generate a wallet-connect info event, create filters for wallet request events, decrypt requests, check whether a profile is active, check whether a command is allowed and then respond with encrypted NWC response events.
The supported command path is deliberately concrete. The code handles payment requests, invoice creation, invoice lookup, balance reads and wallet info. It also saves pending payment requests when approval is needed, deletes single-use profiles after use and persists budget updates after payments. Mutiny treated NWC as wallet infrastructure, not as a badge on a settings page.
Budgets made auto-pay less reckless
Budgeted NWC was one of Mutiny's most useful design contributions. Normal wallet permissions can be too blunt: either every payment needs approval, which makes zaps tedious, or a connection can pay too freely, which makes users nervous. Mutiny added spending conditions around NWC profiles so a connection could require approval, use a single-use grant or pay within a budget.
The code defines budget periods for day, week, month, year and custom seconds. It records tracked payments by time, amount and payment hash, cleans old payments when the period rolls over and calculates remaining budget. The web interface exposed this in the Wallet Connections screen through auto-approve controls, budget amounts, reset intervals, spent and remaining counters.
No Bullshit Bitcoin's v0.4.19 coverage captured why this mattered for Nostr users: a person could set a small daily budget and let zaps go through until the budget was exhausted. That is exactly the kind of UX Nostr payments need. Tiny social payments do not work if every one requires a full wallet ceremony, but they also should not become an unlimited blank check.
Subscriptions were push payments, not card pulls
Mutiny's subscription post is one of the clearest examples of NWC changing product design. The article explains Mutiny+ billing as a Bitcoin-native push model. A service sends a payment request through NWC. The wallet decides whether to pay. The user can set autopay with a budget, and cancellation is simply refusing future payments or disabling the connection.
That sounds subtle until compared with a card subscription. In the card world, the merchant keeps a credential and pulls until the user stops it through the merchant's process. In Mutiny's NWC model, the wallet stays in charge of payment initiation. The subscription server receives a wallet-connect string, but the wallet still applies its profile, budget and approval rules.
The Rust subscription client shows this in code. It checks subscription status, fetches plans, requests a subscription invoice and submits an NWC string to the subscription service. The web app then links Mutiny+ renewal UX, wallet connections and auto-pay. The product was trying to make recurring payments feel native to Bitcoin without handing away pull authority.
AutoZaps turned NWC into social infrastructure
Mutiny's subscriptions post also points to AutoZaps through ZapplePay. The idea was simple: subscribe to a Nostr profile, have the service send a payment request for a chosen amount and interval, and let the wallet pay automatically if the user's budget allows it. That is not only wallet UX. It is a funding primitive for people, creators and community services.
This is where Mutiny belongs in a Nostr archive. It did not just connect a wallet to a social client. It explored what happens when a social graph, a wallet, a recurring payment and a spending budget all use open protocols. The payment request travels over Nostr. The identity is an npub. The money path is Lightning. The consent boundary is the wallet connection.
The idea remains useful even though Mutiny's hosted wallet is gone. Any modern NWC wallet can learn from the same pattern: separate connection names, explicit methods, budget periods, clear renewal timing, disabled connections, pending requests and user-visible remaining allowance. The wallet should make recurring Nostr payments boring in the good sense: understandable, bounded and reversible.
Nostr Wallet Auth reduced connection friction
Mutiny also worked on Nostr Wallet Auth, a flow meant to make wallet connection setup feel less like copy-pasting a dangerous secret. The blog post presented it as one-step wallet connect: an app can request a connection, specify commands and budget details, and let the wallet create or confirm a profile in a clearer interaction.
The web code still contains parser comments for nostr+walletauth:// URLs with relay, secret, required commands, budget and identity parameters. The Rust NWC implementation can create a confirmation event for Nostr Wallet Auth profiles and uses a parameterized replaceable event kind in the confirmation path. That is a strong sign that Mutiny was thinking about connection UX, not merely request handling.
The broader lesson is still current. NWC strings are powerful. Mutiny's Nostr Wallet Auth work aimed at a safer handshake: a named app, a visible permission set, a budget, a relay and a confirmation path. That should remain part of the design conversation for NWC wallets.
Gifts used NWC as a one-time payment rail
Mutiny Gifts showed another unusual NWC use case. A user could create a gift link or QR code, keep funds under their own control until the recipient claimed the gift, and revoke the gift if it was never claimed. The recipient could open Mutiny on the web and redeem into a new wallet. The sender's wallet had to be online for the payment to complete.
The blog post explains the mechanism in Nostr terms: the QR code carried enough information for the recipient to send a Nostr message with an encoded invoice, while the sender listened through a relay and paid. The project described this as a one-time-use addition to its Nostr Wallet Connect feature set. The app strings also warned that the sender's copy of Mutiny needed to be open for redemption.
That is a useful example of NWC beyond zaps. A wallet connection can be a gift, a temporary authorization, a subscription mailbox, a normal app connection or a one-off payment request. The same primitive becomes safer when the wallet supports profile tags, single-use conditions, visible labels and deletion after use.
Nostr contacts made the wallet social
Mutiny's interface treated Nostr identity as part of the wallet. The English locale includes Nostr identity, importing an existing Nostr profile, Nostr keys, Nostr contacts, Nostr npub fields, public and private zaps, zap notes and a Nostr activity view. The send screen code includes zap handling, LNURL and npub paths, and private or public zap visibility.
The Rust side used the nostr and nostr-sdk crates with features for NIP-04, NIP-05, NIP-47 and NIP-57. It also includes a Primal API helper for fetching user profiles, contact lists, direct-message conversations and trusted users. A wallet that can import contacts and show who zapped whom is no longer only a payment form. It becomes a small social money client.
That social layer had a cost. Nostr keys, wallet keys and Lightning state need different mental models. Mutiny's settings warned users to be careful with private Nostr keys, allowed unlinking or deleting a Nostr profile and separated wallet backup from social identity. A wallet can make payments social without pretending that every key has the same consequence.
Fedimint changed the receive path
Mutiny's later wallet story included Fedimint in a serious way. The shutdown announcement called it one of the first Fedimint wallets and the first hybrid Fedimint plus self-custodial Lightning wallet. The app strings show a setup path for joining a federation, managing federations, adding invite codes, transferring funds, reading federation messages and warning that on-chain Fedimint deposits required confirmations.
The Rust federation code uses Fedimint client, wallet, mint and Lightning modules. It stores federation identities, invite codes, metadata, federation IDs, gateway fees, icons, welcome messages, expiry fields and operation progress. That is not an ornamental integration. It is a second money domain inside the wallet: eSATS and federated custody beside self-custodial Lightning and on-chain state.
The tradeoff was visible in the product copy. If a user joined a federation, some minimums and setup fees could disappear, and Lightning receives could land in the chosen federation. But the shutdown timeline also told users to move ecash balances out and explained that Fedimint funds have to be transferred through federation-compatible paths. Ecash improved UX, but it added another counterparty and recovery path.
Native apps did not erase the web DNA
Mutiny eventually shipped Android and iOS apps, but the native apps did not turn it into a conventional mobile wallet. The web repository still used a PWA-first stack with Solid, Vite, WebAssembly, Capacitor, QR scanning, secure storage plugins and a shared Rust wallet package. The native releases were a way to package the same ambitious wallet more comfortably on phones.
The migration post explained two paths from the PWA to the native apps. One path exported the full wallet state through the Emergency Kit and imported it into the new app. The other restored from seed words only, which recovered Lightning and on-chain funds but lost metadata such as payment history and wallet connections. That distinction is important because NWC profiles and activity state are wallet context, not just a seed.
The app's own locale warns against multiple active browsers or devices. Mutiny can only be used in one place at a time, and it may ask users to wait if another device or tab appears to be running the wallet. That was part of the local-first state challenge. Multi-device wallet state is possible, but Lightning state is not as casual as opening the same notes app on three screens.
Storage and recovery were central, not secondary
Mutiny's storage design is one of the reasons the project is worth studying. The shutdown announcement says the team built a multi-device, local-first and redundant synchronization data store that protected Lightning state for nearly 50,000 Lightning nodes over a year. The code shows IndexedDB storage, optional encryption, VSS integration, import and export paths, device locks and log export tooling.
The Emergency Kit copy is plain about what it does. It can export the entire Mutiny Wallet state, import state into another browser and download logs. It also warns that after exporting, a user should avoid further operations in the old browser unless they export again. That is the correct level of caution for a Lightning wallet where stale state can matter.
The recovery guidance separates seed recovery from full state recovery. On-chain funds can be recovered with the 12-word seed, and the timeline notes Mutiny's taproot derivation path m/86'/0'/0'. But wallet connections, payment history and some operational metadata live outside a simple seed restore. Readers should understand that before treating any web wallet export as optional.
Self-hosting became the survival path
After the hosted wallet shutdown, self-hosting became the only durable path for people who still wanted Mutiny. The self-hosting guide in mutiny-deploy walks through running a VPS or local Linux host, installing Docker and Docker Compose, cloning the deploy repository, running containers, setting up nginx and TLS, and later updating the stack through git pull and Docker pulls.
The timeline pointed less technical users toward a Start9 option and more technical users toward the deploy guide. That distinction is important. A self-hosted Mutiny instance is not simply a static webpage. It depends on services around storage, Lightning connectivity, LSP choices, web sockets, Esplora, RGS, TLS and the user's willingness to operate infrastructure.
Self-hosting is empowering only when the user understands the burden. If someone wants to preserve an old Mutiny wallet or study the code, the guides matter. If someone simply wants a working 2026 wallet for Nostr zaps, self-hosted Mutiny is probably the long path. A reader should not confuse open source survivability with consumer support.
The server settings reveal the dependencies
Mutiny's server settings show how many services a web Lightning wallet may lean on. The interface includes settings for a WebSocket proxy, Esplora, Rapid Gossip Sync, LSP, LSPS connection strings and tokens, encrypted VSS backup storage and Tor limitations. That list is a compact education in why self-custodial Lightning UX is difficult.
The Lightning Service Provider layer is especially important. Mutiny's receive screen warned about setup fees, minimum receive amounts, channel reserves and cases where the first receive might default to on-chain. The server settings described the LSP as the component that opens channels for inbound liquidity and can wrap invoices for privacy. The shutdown timeline later noted Voltage LSP wind-down timing and said Zeus LSP was available for self-hosting.
Nostr does not remove those wallet realities. NWC can make an app request a payment elegantly, but the wallet still needs liquidity, routing data, storage, backups, channel state, fee handling and recovery. Mutiny made the Nostr payment surface feel smooth while exposing, in settings and recovery docs, how much machinery lived underneath.
Blinded authentication pointed beyond wallets
Mutiny's later posts also moved beyond direct wallet payments. The blinded authentication post described protecting user identity when accessing paid services. The shutdown announcement listed a blinded authentication client as one of the pieces that had worked well and might inform the team's future tools. The timeline later pointed to OpenSecret and Maple as the company's next privacy-focused direction.
That matters because Mutiny was not only trying to make zaps easier. It was exploring the wider problem of private service access: prove payment or entitlement without leaking more identity than necessary. Nostr, NWC, LNURL Auth, blinded tokens and wallet-controlled payment requests all live near that border between money and login.
For readers, the lesson is to separate the product from the research path. The wallet shut down. The privacy and security ideas did not. Mutiny's archive is useful because it shows how a small team connected wallet state, identity, authorization, recurring payments and service access in public code and public writing.
What to verify before touching an old Mutiny setup
A reader who still has old Mutiny state should begin with the shutdown timeline, not with nostalgia. Check whether funds remain on-chain, in Lightning channels or inside a Fedimint. Close channels early if channel state is still recoverable. Expect force-close delays and fees. Verify the LSP path. Move Fedimint balances to a compatible wallet. Download logs and state only from a trusted local session.
The 12-word seed is vital, but it is not the whole wallet story. On-chain recovery may require the right derivation path. Lightning channel recovery depends on state, not just seed words in the same simple way as an on-chain wallet. NWC profiles, subscriptions, gifts, payment history and labels are metadata that can be lost when restoring seed only.
A reader considering self-hosting should test on small balances, fork or preserve the code they need, understand that the main web and node repositories are archived, review open issues, inspect service dependencies and keep expectations modest. The right use today is archival recovery, learning or controlled experimentation. It is not casual onboarding for a new user with meaningful funds.
What Nostr builders can still take from Mutiny
The cleanest design lesson is that wallet connections need names, permissions, spending conditions and visible state. Mutiny's NWC profiles had labels, command lists, active flags, archives, budgets and tags for subscriptions, gifts and general use. That beats treating one NWC string as an invisible pipe.
The second lesson is that social payments need boring safety. Zaps, gifts and subscriptions become humane when the wallet gives the user budgets, pending approval, deletion, readable history and clear warnings. Mutiny did not solve every reliability problem, but it built controls that later NWC wallets should keep refining.
Sources worth opening
Start with the shutdown timeline, the original shutdown announcement, the Mutiny web and node repositories, the NWC code, the self-hosting guide, the PWA manifest, the Nostr Wallet Connect posts and the external launch and release coverage.
- Mutiny hosted app
- Mutiny PWA manifest
- Mutiny Blog RSS
- Mutiny Wallet shutdown announcement
- Mutiny Wallet shutdown timeline
- Mutiny subscriptions and NWC
- Mutiny auto-approve zaps
- Mutiny Gifts
- Mutiny Nostr Wallet Auth
- Mutiny Android and iOS announcement
- Mutiny native-app migration guide
- Mutiny federated Lightning addresses
- Mutiny Wallet FAQ
- Mutiny blinded authentication tokens
- Mutiny Harbor announcement
- Mutiny ecash purchase case study
- Mutiny web repository
- Mutiny web README
- Mutiny web package file
- Mutiny English interface strings
- Mutiny wallet worker source
- Mutiny NWC editor source
- Mutiny wallet connections source
- Mutiny pending NWC source
- Mutiny send route source
- Mutiny node repository
- Mutiny node README
- Mutiny core Cargo file
- Mutiny WASM Cargo file
- Mutiny NWC Rust source
- Mutiny subscription client source
- Mutiny Fedimint source
- Mutiny IndexedDB storage source
- Mutiny VSS source
- Mutiny deploy repository
- Mutiny self-hosting guide
- Mutiny recovery wiki
- Bitcoin Magazine open beta coverage
- No Bullshit Bitcoin open beta coverage
- No Bullshit Bitcoin NWC budgeting coverage
- No Bullshit Bitcoin signet release coverage
- Stacker News NWC budgeting walkthrough
- Nostr Wallet Connect site
- NIP-47 Nostr Wallet Connect
- NIP-57 zaps
- NIP-05 identifiers
- Fedimint documentation
- LDK documentation
- BDK project
