Log In

Published

Oct 28, 2025

Category

NWC

A Trust-Minimized Multi-user NWC Wallet With Ark & Spark

Discover a novel multi-user wallet architecture built on Ark or Spark that delivers a seamless in-app payment experience using Nostr Wallet Connect (NWC).

Nostr Wallet Connect (NWC) gives apps seamless, persistent, permissioned access to user's wallets, enabling awesome usecases:

The possibilities are almost endless for developers who now have access to programmable money built on the lightning network through NWC.


Why App Developers Choose NWC

NWC Makes Building Easy - developers only need to implement NWC and their app can connect to many different wallets without being exposed to their incompatible APIs. Think of NWC as the USBC for wallet and app connections.

This means developers can instead spend more time focusing on what makes their app unique, rather than spending time building wallet integrations.


Good Connection UX for App Users

Bitcoin app developers who build apps for a wide range of users need a seamless connection flow that does not create a barrier for users - both users that have an existing wallet, and users who do not yet have a wallet.

As simple as logging in with Google, with NWC users can connect their wallet in one click and experience seamless wallet integration in bitcoin apps.

Bitcoin Connect enables NWC's one-click flow for web-based applications, which enable users to quickly connect their existing wallet, or create a brand new wallet with a few clicks.


Mobile Wallets are Challenging NWC Wallets

For NWC, it's important the wallet is always online and accessible, so that it can be used seamlessly whenever needed. This means that mobile wallets unfortunately are not the best option. If your mobile phone runs out of battery or loses signal then your wallet is no longer accessible. Even if your mobile phone is always online and connected, there are severe limitations (especially on iOS) around processing background events, which are necessary for processing NWC requests. The current OS-independent method is relying on push notifications, but handling push notifications reliably in all different app states (open, backgrounded, closed) on both operating systems is a huge challenge and so far we have yet to see a mobile NWC wallet that works well with push notifications.

On Android, it's possible to run a 24-7 foreground service directly connected to a NWC relay and natively run a wallet, however there are downsides here too - the user is exposed to a permanent foreground notification, possible battery drainage notifications, and possibly the user has to change their optimization settings to ensure the foreground service doesn't get killed.


Server Wallets are Ideal NWC Wallets

24-7 online server wallets are perfect for NWC - they are always online, and unlike on mobile, they are not restricted by the operating system to process NWC events. For reliability and ability to process time-critical automated wallet requests, a server wallet is needed.


The Server Wallets Tradeoff

Unlike mobile wallets which are easy for users to install and run, server-based self-custodial hosted wallets like Alby Hub or LNbits keep users in control, but need to be hosted somewhere: either locally on dedicated hardware or in the cloud. This means they are less likely to be chosen by both casual and beginner users.

24-7 online custodial wallets such as CoinOS, and Rizful also work great and are perfect for beginners and casual users, however user funds are on the same node secured by a single private key and a user accounting system. Users are completely dependent on the custodial wallet service, and there is always the possibility of losing access to their money.


Can The New Layer-Twos change this?

Even with the coming of new trust-minimized layer-two wallets such as Spark and Ark, the challenges of running a NWC wallet on mobile still remain: mobile wallets are not always online and are very limited in their ability to process background tasks.

Users who only need simple payments can use something like Wallet of Satoshi's new Spark-based wallet, where the user's keys are safely stored on the user's mobile device. However, if we want to reliably enable programmable money uses-cases on lightning with NWC, the keys need to be moved to an always-online server.


A Trust-Minimized Multi-User NWC Wallet

Spark and Ark can be applied to a multi-user hosted wallet model, which comes with improvements but also challenges when it comes to ensuring users stay in control of their wallet.


Less Dependence On Operator

In custodial wallets, all the users share a single custodial node which only the operator has the the keys. User balances exist as a mere database entry and can only be accessed through the custodial wallet. This makes users completely dependent on the service operator. With Spark or Ark, each user has their own key and can unilaterally exit. Users can spend their funds completely outside of the NWC wallet service by importing their 12-word seed phrase into another wallet, allowing them to always spend their funds even if the operator is unco-operative.


Lowered Risk

With Spark or Ark, each user's funds are tied to their own key. This means the wallet service does not need any accounting logic, which lowers risks of many possible bugs and attack surface exposed by accounting systems.

Users could even have individual wallets for each app connection, completely isolating activity between apps. However, this has its own UX challenges.


Wallet Access

A hosted multi-user wallet still means that each user's wallet still needs to be accessible by the server in order to make payments, but this does not necessarily mean that the server needs to keep all its user's keys in plaintext or accessible in memory.

Spark (and maybe later Ark), support offline receive through the ability to share a public key that others can pay to, meaning the user can always receive funds. But the real challenge is sending.

User keys can be encrypted at rest and only accessible by the user themselves, keeping the user in control and ownership of their keys. When a payment needs to be made, the user's wallet will need to be temporarily unlocked to sign a payment.


Trust Model

This idea is inspired by Spark's moment-in-time trust model, where a user's lightning wallet can only be unlocked for the duration of responding to an NWC request. The NWC request would need to contain some key material to be able to unlock the user's wallet - meaning that the service cannot access the user's wallet on its own.

However, since the service has access to the wallet at the time of the request, this depends on the assumption that the server forgets the keys, which like Spark this is not provable. Therefore, again like Spark, the service would need to be run by a group of N operators, collaboratively signing user payment requests, with the assumption that at least a required threshold of operators forget the key material after the request, and that each operator acts as a co-signer and cannot access the user's wallet on their own.

How wallet access works in combination with NWC and whether the same model can be applied has technical and regulatory challenges, but it's definitely interesting to consider.


Alby Keeps Pushing the Boundaries

This is just one idea as we push the boundaries of what is possible with programmable money on lightning. We also believe that with the right use cases, people will put in the work to run their own hosted self-custodial NWC lightning wallet. For those already living on the bitcoin standard, self-hosted NWC wallets like Alby Hub are a perfect fit.

What do you think about the idea of a trust-minimized multi-user NWC wallet with Ark & Spark? Let us know!