Lightning Wallets, Nodes and the Custody Choice
The hardest wallet question is not which logo you like. It is who controls funds, who can spend, who can recover, who can censor and what breaks when the service behind the app goes away.
The logo is not the custody model
A wallet card can look friendly while hiding a serious trust decision. Some wallets are custodial accounts. Some connect to your own node. Some are self-custodial mobile wallets. Some are remote controls. Some are wallet services that other apps can call through NWC. Some are Cashu wallets where mint trust is the center of the story.
This is why the Wallets hub cannot be a flat list of names. You need to know what a product is holding, what it can spend, what it stores, what it encrypts and what happens if the company, server, relay, mint or phone disappears.
The right first question is not 'which wallet is best?' It is 'best for what risk?' A creator taking zaps has different needs from a merchant reconciling payments, a node runner managing liquidity, a fan sending tiny sats, a developer testing NWC or a venue building a member checkout.
Four wallet shapes you keep meeting
The first shape is the custodial or hosted account. It is easy, usually fast and often excellent for onboarding. Coinos, hosted Lightning services and some app-integrated wallets can sit here depending on configuration. The tradeoff is obvious: someone else operates the account system and can set rules, limits or recovery procedures.
The second shape is the node-connected wallet. ZEUS, BitBanana and other remote wallets can talk to your LND or Core Lightning node, giving you deeper control but also more responsibility. You care about channels, routing, backups, connection security and uptime.
The third shape is the wallet operating system. LNbits is the clearest example. One funding backend can support many wallets, API keys and extensions. That is powerful for operators, communities and experiments, but it means the admin boundary matters. Who controls the funding source? Who creates wallets? Who can revoke keys?
The fourth shape is the app connection layer. NWC lets a wallet service expose limited actions to another app. This is not custody by itself; it is permissioned remote control. It is excellent when scoped tightly and dangerous when treated like a generic password.
ZEUS shows the self-custody end of the spectrum
ZEUS describes itself as Bitcoin-only, self-custodial, open source, no KYC and able to connect to your own Lightning node. Its documentation lists Nostr Wallet Connect service and client support, Lightning addresses, Tor, LNURL, node management, point of sale, routing reports and more. That feature depth is why ZEUS is important in the Nostr wallet map.
But depth is not the same as simplicity. ZEUS is strongest when you understand or are willing to learn the node side of Lightning. It can also serve average users through newer embedded-node and LSP flows, but the core identity of the project is serious wallet control, not just a social zap button.
Read ZEUS beside Alby Hub, LNbits and BitBanana. Together they show the spectrum: hosted convenience, personal wallet service, operator backend, node remote and mobile self-custody.
Alby and LNbits show the service layer
Alby Hub makes the service layer visible for normal people. It can sit between your wallet and the apps you use, expose NWC connections, connect to Alby Account features, provide a Lightning address and make budgets readable. That is a huge UX contribution because payment permissions stop being hidden in developer strings.
LNbits is more like a modular wallet operating system. It lets an operator create wallets, extensions and API surfaces around a funding backend. In a Nostr context, LNbits matters because communities, venues and builders can use it as the payment infrastructure behind zaps, point-of-sale flows, experiments and NWC services.
Both are powerful. Both require operational honesty. If you run the service, you inherit uptime, backups, access control, logs and user support. If someone else runs it, you inherit their policies and reliability.
Brand trust is not vibes
A wallet brand earns trust through boring proof: source code, documentation, security posture, recovery instructions, issue history, clear fees, active maintainers, wallet permissions, custody disclosure and a support trail. A beautiful app store screenshot is not enough.
For small zaps, people tolerate more experimentation. For meaningful balances, the bar rises. Can you export funds? Can you rotate or revoke NWC connections? Can you see spending limits? Is there a backup path? Are private keys local, hosted, encrypted or never held by the app? Does the product say this plainly?
Nostr makes the trust story more complicated because a wallet may also act as a signer, profile surface, relay client or app connector. A product that handles identity and money at the same time must be read with extra care.
The failure path is the real product spec
Ask what happens when something breaks. If a relay is offline, can payment requests still complete? If a wallet service is down, does the app fail gracefully? If a phone is lost, can funds be recovered? If an NWC connection leaks, is the budget small and revocable? If a Lightning channel is stuck, does the UI explain what happened?
These questions sound negative only until you have money in motion. Then they are the product. Wallets do not become trustworthy because nothing ever breaks. They become trustworthy because the breakage is bounded, visible and recoverable.
That is also the right standard for Crays. Creator payments, award voting, premium content and venue flows should be built around small permissions, clear receipts and recoverable paths, not vague confidence.
What to do before funding a wallet
Use a new wallet with a small amount first. Create one NWC connection for one job. Set a budget that matches the job. Pay yourself a test invoice. Revoke the connection. Restore or reconnect on a second device if the wallet claims portability. Read the docs before moving meaningful funds.
That routine is not glamorous. It is how the wallet layer becomes boring enough to use every day.
Sources worth opening
Open these when you want the specification, product documentation or implementation trail behind the article.
