CraysElectrum
Electrum is not a hosted Nostr wallet. It is a mature local Bitcoin wallet that added Nostr where relay transport solves real wallet problems: remote Lightning control, swap discovery and multisig PSBT exchange.
A serious Bitcoin wallet before it is a Nostr tool
Electrum should be read in the right order. It is not a social client that later learned how to pay invoices. It is one of Bitcoin's best-known self-custodial wallets, built around the idea that the user controls the wallet while the software can still stay light enough to run on ordinary machines. The Nostr features are interesting because they sit inside that older wallet culture: local keys, wallet files, server selection, signing, recovery words, transaction control and a user who is expected to understand that real money is involved.
That background changes the way Nostr Wallet Connect feels in Electrum. With a hosted wallet, NWC often looks like an account permission screen. With Electrum, it looks more like exposing a running local Lightning wallet to an external app through an encrypted relay path. The wallet is still local. The Lightning node state is still in Electrum. The NWC string is a controlled spending credential, not an identity login.
The official Electrum site also sets the security tone. It tells users to download Electrum only from electrum.org, shows the current release, and links to signatures and source code. That warning belongs at the top of any practical Electrum discussion. A Nostr connection cannot make a compromised desktop wallet safe. Before a user worries about NWC budgets, relays or app compatibility, they should first know that they installed the real Electrum release and verified it as far as their threat model requires.
Why a lightweight wallet still matters
Electrum's core design is a lightweight Bitcoin wallet. It does not require the user to run Bitcoin Core locally in order to see balances and create transactions. Instead, it talks to Electrum servers for blockchain data while keeping the wallet's private keys on the user's device. That is the reason Electrum has stayed useful for people who want self-custody without maintaining a full node on every computer or phone.
The model has an honest tradeoff. A user gets faster setup and lower local resource requirements, but server selection and privacy become part of the wallet's risk surface. Electrum can connect through Tor, can use custom servers, and can be paired with more private infrastructure, but the default experience still depends on a network service to learn chain state. That is not the same risk as a custodial account, but it is still a risk worth naming.
For Nostr readers, this is important because Electrum's NWC plugin does not replace Electrum's base architecture. An app connected through NWC is requesting Lightning wallet actions from an Electrum wallet that still has Electrum's normal wallet, network and Lightning assumptions.
Electrum added Nostr where relay transport solves wallet problems
Nostr arrived in Electrum in release 4.6.0, published on July 16, 2025. The release notes describe a new dependency, electrum-aionostr, and say Electrum uses Nostr for submarine swaps and several plugins. They also make an important promise: Electrum does not connect to Nostr by default, only when required. That keeps Nostr from becoming a silent background dependency for users who are not touching Nostr-powered features.
The same release introduced two Nostr-facing wallet features that are easy to confuse but serve different jobs. The Nostr Wallet Connect plugin lets apps remotely control Electrum Lightning wallets through NIP-47. The Nostr Cosigner plugin lets multisig cosigners exchange PSBTs over Nostr, replacing the older centralized cosigner-pool style. Both use Nostr as a transport layer, but one is about app-controlled Lightning payments and the other is about transaction coordination among cosigners.
Submarine swaps became another Nostr use case. Electrum clients can use Nostr to discover swap providers and perform related RPC calls. Providers advertise fees and liquidity on Nostr, and the setup documentation explains how operators can run the swapserver plugin. That is a very Electrum-shaped use of Nostr: not a public feed, not a profile timeline, but a way for independent wallet services to find each other without requiring one central HTTP endpoint.
NWC is a plugin for Lightning-enabled Electrum wallets
The NWC feature in Electrum is a first-party plugin named Nostr Wallet Connect. Its manifest describes it plainly: remote control of Electrum Lightning wallets via Nostr NIP-47. The Qt interface adds a wallet menu action called Nostr Wallet Connect, but only for a wallet that has Lightning enabled. If the current wallet is not Lightning-capable, the plugin tells the user to open a Lightning-enabled wallet first.
That requirement is not cosmetic. NWC in Electrum is about Lightning wallet operations, especially paying and creating invoices. A normal on-chain-only Electrum wallet can still be powerful, but it is not the right object for NIP-47 payment automation. The user needs an Electrum wallet with Lightning available, channels or usable Lightning balance, network connectivity and enough liquidity for the requested payment direction.
This also means Electrum's NWC is not a universal remote for every Electrum feature. A connected app should not expect to select UTXOs, export seeds, manage hardware-wallet policies or control every on-chain setting. The plugin deliberately exposes a NIP-47 wallet-service surface. That is healthier than pretending one connection string should be able to do everything a full desktop wallet can do.
The connection string is a spending credential
Creating an Electrum NWC connection starts with a name, optional daily satoshi budget, optional validity period and a main NWC relay. Electrum then produces a nostr+walletconnect:// URI that contains relay parameters and a secret. The user can copy the string or show a QR code to the app that needs wallet access.
The secret is the part to treat carefully. Whoever gets the connection string can ask the wallet for whatever that connection is allowed to do. If the connection has a spending budget, the app can spend up to that budget. If the connection has no expiry, it can remain useful for longer than the user remembers. If the app is abandoned, compromised or too permissive, a stale NWC connection becomes a quiet liability.
The safe habit is simple: name connections after the app and purpose, set a small daily budget, set an expiry for temporary tests, make one connection per app, delete unused entries and do the first payment with a tiny amount. Electrum's interface shows existing connections, budget use and expiry, which makes review possible. That review only helps if the user actually returns to the list and cleans it up.
Daily budgets are useful, but version matters
Electrum's NWC plugin supports a daily spending limit. The server code stores daily_limit_sat on the connection, checks budget use before a payment, and returns a QUOTA_EXCEEDED error if the next payment would exceed the allowance. A connection with a daily limit of zero behaves as receive-only: the info event removes spending methods for that client while keeping non-spending methods available.
That is the right safety model, but it also has history. Electrum 4.7.2, released on April 1, 2026, disclosed a low-severity Nostr Wallet Connect daily spending limit bypass and linked a GitHub security advisory. The same release notes also mention NWC spec synchronization and bug fixes. In practical terms, anyone using Electrum's NWC plugin for spending should be on 4.7.2 or newer, not an older experimental NWC build.
A budget is not a vault wall if the software enforcing it is outdated. The reader should treat the 4.7.2 advisory as a normal part of wallet hygiene, not as trivia. Update first, then create app connections. If a connection was created on an older version, delete and recreate it after updating. The inconvenience is small compared with letting a payment automation feature run on code with a known spending-control bug.
What Electrum advertises to NWC clients
Electrum's NWC server publishes wallet capability information through NIP-47-style events. The plugin code defines the info, request, response and notification event kinds as 13194, 23194, 23195 and 23196. It rebroadcasts info events periodically and listens for encrypted request events from the client pubkeys associated with the user's saved connections.
The supported spending method is currently pay_invoice. The broader supported method set includes make_invoice, lookup_invoice, get_balance, get_info, list_transactions, notifications and pay_invoice. It also advertises payment-sent and payment-received notifications. That gives a compatible app enough surface for the common loop: learn capabilities, create or pay an invoice, check balance and reconcile transaction state.
The negative space matters too. Electrum's method list does not advertise pay_keysend as a spending method. It does not present itself as a broad wallet-account API. A Nostr client built around another wallet's richer method set may need to adapt. For Electrum, compatibility should be tested against the actual advertised methods, not against the most optimistic interpretation of NWC as a protocol family.
Relays are part of the user experience
Electrum's NWC URI puts the selected main relay first because the plugin authors observed that many NWC clients only use the first relay URL in the connection string. The UI exposes a main relay selector and warns that the selected relay must accept the user's events. The server still includes additional configured Nostr relays, but the first relay can decide whether a connection feels reliable or mysteriously broken.
This is one of the places where NWC differs from a normal web API. A payment request may fail because the app cannot reach the relay, because the relay rejects events, because the wallet is offline, because the wallet has no Lightning connectivity, because the request is stale or because the app does not understand the response. The relay is not just a pipe in a diagram. It is an operational dependency.
For a practical setup, choose a relay the wallet and the app can both use, test the connection immediately after creating it, and avoid assuming that adding many relays automatically makes the connection robust. If the app only honors the first relay, the first relay is the one that matters most. Electrum's UI is unusually direct about that, which is good for users who are trying to debug real payments.
The plugin is careful about stale requests
Electrum's NWC server does several things a real wallet service should do. It rejects request events whose explicit expiration tag has already passed. If a request has no expiration tag, it ignores events older than about thirty seconds so that a late relay delivery does not trigger a payment the user or app already considers timed out. It also checks the request's encryption tag and returns an unsupported-encryption error if the client asks for a scheme the plugin does not support.
The supported encryption scheme set is currently nip04. NIP-04 is widely used in Nostr wallet-control flows, but it is also older than newer direct-message encryption patterns. The important point for the reader is compatibility: the client and wallet must agree on the encryption scheme, and Electrum will not silently process a request tagged with something outside its supported set.
Those checks make Electrum feel more like wallet infrastructure than a demo. Money operations should not be triggered by stale events, malformed JSON or guessed encryption. A clean error is better than a ghost payment. Still, a user should not mistake protocol hygiene for complete safety. The desktop wallet, relay, app, connection string and operating system all remain part of the trust boundary.
Paying an invoice is deliberately narrow
When an NWC client asks Electrum to pay a Lightning invoice, the plugin parses the BOLT11 invoice, accepts an explicit amount for amountless invoices, builds a payment fee budget, checks the connection's daily allowance and then calls Electrum's Lightning worker to attempt the payment. If the payment succeeds, the response can include the preimage. If it fails, the plugin returns a typed error instead of pretending the request vanished.
That flow is narrow in a good way. The app is not handed the wallet. It is handed a constrained payment method with budget logic and method-specific validation. The user can create a connection that lets a trusted app pay small invoices while leaving the rest of the wallet outside the app's reach. That is exactly the kind of boundary a desktop wallet should want when it participates in Nostr app workflows.
There are still Lightning realities behind the clean interface. A payment can fail because of liquidity, fees, route failure, an expired invoice, a malformed invoice, wallet network trouble or a wallet that is no longer running. NWC makes app requests portable across relays. It does not make Lightning settlement magically synchronous. Serious clients should use lookup and transaction listing methods to reconcile instead of treating one request-response pair as the entire truth.
Receiving and reconciliation are part of the method set
Electrum's NWC support is not only a payment button. The method list includes make_invoice, lookup_invoice and list_transactions, which are essential for apps that need to receive, display state or reconcile after an uncertain payment attempt. The transaction listing code maps Electrum invoice and payment status into NIP-47-style transaction records, including timestamps, expiry and fees where available.
That matters for real apps. A live-streaming client, game, point-of-sale experiment or social app may need to create an invoice and later check whether it was paid. A payment app may need to show pending, settled or failed states. A bot may need transaction history to avoid double-processing. A wallet that only pays invoices can be useful, but a wallet that also exposes lookup and history is much easier to integrate responsibly.
Electrum remains cautious about the surface it exposes. Non-spending methods can still reveal wallet information such as balance and transaction state, so they are not harmless. A receive-only or read-capable connection should still be treated as sensitive. The difference is that Electrum lets the user separate read/receive behavior from spending behavior by using the daily limit model, especially the receive-only zero-budget case.
Submarine swaps show the broader Nostr design
Electrum's Nostr work is larger than the NWC plugin. Release 4.6.0 moved submarine swap discovery and related RPC calls onto Nostr. Swap providers can advertise fees and liquidity on relays, and they do not need to expose a public HTTP endpoint for the client RPC flow. The documentation for running a swap server now belongs to the same story as Electrum's Nostr transport layer.
This is a good example of Nostr being used as infrastructure. The user does not need a public persona or social feed to benefit. The wallet can discover service providers, compare advertised liquidity and fees, and perform a request flow over relays. Providers, unlike ordinary clients, use persistent identity. Clients use ephemeral Nostr keys for swap interactions, which reduces how much long-lived identity is attached to normal wallet actions.
The release notes also explain why zero-confirmation swaps were removed in that decentralized service model: a decentralized swap marketplace needs trust-minimized behavior. That is the tone Electrum brings to Nostr. It is added where it can decentralize service discovery or message transport, without keeping shortcuts that would make the decentralized version less safe.
Nostr Cosigner is a different feature, not NWC
Electrum's Nostr Cosigner plugin deserves a separate mention because it explains how the project thinks about relays. Multisig wallets need cosigners to exchange partially signed Bitcoin transactions. The older cosigner-pool model depended on a central service. The Nostr Cosigner plugin uses Nostr to send and receive PSBTs between cosigners instead.
That is not a Lightning payment connection and it should not be described as NWC. It is a multisig coordination tool. Its presence matters because it shows Nostr's value for wallets beyond zaps and app payments. A relay network can help independent wallet users exchange signed transaction material without every wallet project operating a bespoke message server.
The security questions are also different. With NWC, the concern is a connected app spending within or beyond a budget. With cosigning, the concern is whether cosigners understand the transaction they are signing, whether PSBT exchange is authentic, whether wallet policies are correct and whether the relay transport leaks useful metadata. The shared word is Nostr, but the wallet behavior is not the same.
Electrum is powerful because it is local
A local wallet has advantages that hosted wallets cannot copy. Electrum users can work with wallet files, recovery seeds, hardware wallets, watch-only setups, multisig policies, cold storage workflows, transaction preview, fee choices and server selection. That makes Electrum attractive to users who want more control than a simple web wallet gives them.
The same locality creates practical NWC limits. A connected app can only reach the wallet when Electrum, the plugin, the wallet network and the relevant Lightning components are available. A cloud wallet may answer NWC requests at all hours. Electrum is closer to a workstation or phone wallet: it is excellent when the user wants local control, less ideal when the user wants unattended always-on payment automation.
That distinction should guide use cases. Electrum NWC is sensible for a desktop user who wants a known app to make small Lightning payments from a self-custodial wallet while they are running Electrum. It is less natural as a backend for a public service that expects 24-hour unattended uptime. For that, a dedicated node, hosted NWC service or server wallet may fit better.
The update habit is not optional
Electrum's release history is one reason people trust it, but the same release history shows why wallet software has to be updated. Version 4.7.2 included security fixes and disclosures, including an external plugin authorization bypass and the NWC daily spending limit bypass. It also changed default Unix permissions to a more restrictive umask and fixed several Lightning and swap issues.
For readers, the practical advice is direct: do not build NWC habits around an old Electrum install. Before connecting a Nostr app, check the version, download from the official site, read the release notes for wallet-affecting changes and consider verifying signatures. If a release note mentions a plugin you use for money movement, treat it as operational information, not developer trivia.
What to check before connecting a Nostr app
A careful Electrum NWC setup starts with the wallet, not the app. Confirm that Electrum is current, the wallet is Lightning-enabled, Lightning is connected, the balance and channel liquidity match the intended use, and the wallet is on a machine you trust. Then decide what the app should actually be allowed to do. A zap client, a game and a point-of-sale tool do not need the same budget.
When creating the connection, use a descriptive name, choose a relay that the app can really use, put a small daily limit on spending, add an expiry for short experiments and keep the connection string private. After scanning the QR code or pasting the URI, perform a tiny test invoice. Then check Electrum's connection list and transaction state to make sure the app and wallet agree on what happened.
After the test, keep pruning. Delete connections for apps you no longer use. Lower budgets if an app only needs occasional zaps. Recreate connections after major wallet updates if you are unsure about old state. If a client behaves strangely, stop by deleting the connection rather than trying to debug while the app still has a live spending credential.
The bottom line
Electrum's Nostr work is worth taking seriously because it is specific. Nostr moves swap discovery, PSBT cosigning and NWC wallet-control messages. It does not turn Electrum into a social network, and it does not hide the fact that the user is operating a real wallet. That restraint is part of the appeal.
The NWC plugin is useful when its limits are respected. It is a Lightning-focused permission channel with budgets, expiry, relay choice and a concrete method list. It is not a blanket account login. It should be small, named, tested, monitored and removed when no longer needed.
For a reader deciding whether to use it, the answer is not simply yes or no. Use Electrum NWC if you want an Electrum Lightning wallet to serve one Nostr app within a narrow budget. Update first, start tiny, choose the relay carefully, and remember that the most important security boundary is still the local wallet itself.
Sources worth opening
Open Electrum's official site, release notes, NWC plugin code, security advisory, Nostr relay dialogs, swapserver documentation, NIP-47 and the NWC documentation before deciding whether to use Electrum as an app-controlled Lightning wallet.
- Electrum official website
- Electrum GitHub repository
- Electrum release notes
- Electrum NWC plugin manifest
- Electrum NWC plugin entry point
- Electrum NWC server implementation
- Electrum NWC Qt interface
- Electrum NWC command line interface
- Electrum Nostr relay configuration dialog
- Electrum Nostr swap providers dialog
- Electrum submarine swap implementation
- Electrum swapserver plugin
- Electrum Lightning worker code
- Electrum NWC daily spending limit advisory
- Electrum external plugin authorization advisory
- Electrum documentation index
- Electrum FAQ
- Electrum cold storage documentation
- Electrum multisig documentation
- Electrum hardware wallet documentation
- Electrum merchant documentation
- Electrum swapserver documentation
- NIP-47: Nostr Wallet Connect
- Nostr Wallet Connect official site
- NWC documentation
- Awesome NWC wallet list
- Electrum icon asset
- Electrum NWC icon asset
- Electrum Nostr icon asset
- Electrum Python requirements
- Electrum hardware wallet requirements
- Electrum download signatures directory
