CraysZEUS
ZEUS is a serious mobile Bitcoin wallet: it can manage LND and Core Lightning nodes, run local wallet backends, use Cashu, publish ZEUS Pay addresses and turn the phone into a permissioned Nostr Wallet Connect service for other apps.
A wallet that can also manage the node
ZEUS is best understood as a mobile control room for Bitcoin and Lightning, not as a single-purpose zap wallet. The public README describes it as a mobile Bitcoin and Lightning wallet and a remote node manager for LND and Core Lightning. That sentence is important because it sets the scope: ZEUS is not merely holding an account balance inside a hosted service. It can sit in front of serious node infrastructure.
The app runs on Android and iOS and is built with TypeScript and React Native. In practical use, it can be a phone wallet, a remote dashboard for an existing node, a point-of-sale terminal, a Lightning Address receiver and a Nostr Wallet Connect service. Readers coming from social Nostr clients should not treat ZEUS as just another app that happens to pay zaps. It is closer to the wallet layer that those apps can call.
That broader shape is why ZEUS needs careful handling. A social client can lose a draft or fail to load a relay. A wallet can move money, expose balances, reveal payment history or control node operations. ZEUS gives the user a lot of power on a phone, which means the useful question is not whether it supports many features. The question is which backend, permissions and custody model are active in the setup in front of you.
The current public project
The checked public repository was `ZeusLN/zeus`. GitHub listed it as a TypeScript project with the description `A mobile Bitcoin wallet fit for the gods`, a homepage at `ZeusLN.com`, and topics that include bitcoin, lightning, lnd, core-lightning, ldk, cashu, ecash, nostr, payments, react-native, self-custody and mobile platforms. The repository was created on February 16, 2019 and remained actively pushed on June 11, 2026.
The project is open source under the GNU Affero General Public License v3. The README also tells developers to verify the code before building and links to reproducible build material. That tone fits a wallet project: users should not be asked to trust a binary only because it has a familiar icon. ZEUS publishes source, release artifacts, manifests and signature material so advanced users can check more than the app store listing.
The release history was active at the time of checking. The latest stable release returned by the GitHub releases API was `v13.0.2`, published on May 21, 2026. The newest prerelease was `v13.1.0-beta2`, published on June 9, 2026. The beta highlighted Cashu multi-mint sends, queue-less iOS NWC payments, CLINK noffers, ZEUS Pay changes and Android persistent mode improvements. Those are current signals, but a beta should still be treated as a beta.
Install paths and verification habits
ZEUS is distributed through several channels. The README links Android users to Google Play, F-Droid through the official download page and Zapstore; iOS users are linked to the Apple App Store. GitHub releases also publish Android APK files, an iOS IPA for testing paths, manifests and detached signatures. The official download page describes ZEUS as an open-source, self-custodial Lightning wallet for iOS, Android, F-Droid and Zap Store.
That variety is useful because wallet users have different risk models. Some readers will prefer the App Store or Google Play update path. Others will want F-Droid or direct release artifacts so they can compare signatures and hashes. ZEUS release notes include GPG verification instructions and Android signing fingerprint material, which is exactly the kind of public hygiene a wallet project should make visible.
The verification point is not cosmetic. A mobile Lightning wallet may contain node credentials, seed material, Cashu state, NWC secrets and spending authority. A user who installs from an unofficial mirror, a stale APK archive or a cloned store listing can lose more than a login. Before using ZEUS with meaningful funds, the installation source and version should be as deliberately chosen as the wallet backend.
Remote node control is still central
ZEUS became known because it could manage remote Lightning nodes from a phone. The documentation still explains that users can either connect a remote node or run a node and wallet locally on the phone. The remote path supports LND and Core Lightning nodes, LNDHub accounts and platform-specific connection guides for systems such as Alby Hub, BTCPay, myNode, RaspiBlitz, StartOS and Umbrel.
That model is different from a hosted wallet login. If you connect ZEUS to your own node, the phone is a client for infrastructure you operate somewhere else. The app can show balances, invoices, channels, payments, peers, routing reports and node data depending on the backend. In a strong setup, the phone does not replace the node; it becomes the mobile console for the node.
The advantage is control. The cost is operational responsibility. Remote node credentials, Tor access, macaroon permissions, network reachability and platform-specific configuration all matter. ZEUS can make the interface pleasant, but it cannot make a badly backed up node safe or a broadly permissioned credential harmless. The reader should treat remote setup as wallet administration, not a casual app login.
Local wallet paths changed the product
ZEUS is no longer only a remote controller. The documentation tells new users that, if they do not have a remote node or account, they can use a local wallet path that runs on the phone. Recent releases also highlight LDK Node and Embedded LND work, including a 2026 release line that brought a new node-in-the-phone path and an updated onboarding process.
Local wallet paths make ZEUS easier for readers who do not already operate a Lightning node. They also change the risk profile. A phone-based wallet can be more direct and convenient, but backups, channel state, liquidity, device loss and mobile operating system behavior matter. The app can guide the user, but the user still needs to understand which funds are on-chain, which are in Lightning channels and which are represented by ecash.
The README feature list reflects that wide span: self-custody, no KYC, Tor, Lightning address send and receive, LNURL, channel management, routing reports, fees, MPP and AMP, keysend, SegWit, message signing, fiat display, coin control, external signer support, watch-only accounts and contact handling. The long list is impressive, but the setup mode determines which parts are actually available.
ZEUS works on both sides of NWC
Nostr Wallet Connect is where ZEUS becomes especially relevant for the wider Nostr app ecosystem. In one direction, ZEUS can connect to an external NWC wallet by accepting a `nostr+walletconnect://` URL and using Alby's `NostrWebLNProvider`. In the other direction, ZEUS can create NWC connections for other apps, giving them permissioned access to wallet functions.
That dual role matters. Many tools in the NWC ecosystem are only interfaces: they ask a remote wallet to do something. ZEUS can be an interface in that sense, but it can also be the wallet service that another app talks to. A Nostr client, command palette, web tool or payment experiment can receive a ZEUS-created connection string and request actions through the relay path the user selected.
The reader should think of NWC as delegated wallet authority. It is not a harmless profile link. A connection can include enough information for an app to request invoices, read balances, inspect transactions or send payments, depending on permissions. ZEUS exposes the controls that make such delegation usable: labels, permissions, budgets, expiry, relays, QR display and revocation.
When ZEUS connects to another NWC wallet
The `backends/NostrWalletConnect.ts` file shows ZEUS acting as a NWC client. It imports `NostrWebLNProvider` from `@getalby/sdk`, reads the configured NWC URL from settings, creates the provider with `nostrWalletConnectUrl`, calls `enable()` and then maps wallet actions to provider methods. This is the familiar app-to-wallet direction of NIP-47.
In that backend, ZEUS can ask the remote NWC wallet for a Lightning balance, create invoices, pay invoices, look up invoices and list transactions. The same file marks Cashu wallet support and NWC service support as false for this backend. That is sensible: when ZEUS is merely connected to another NWC wallet, it is not the underlying wallet service. It is using someone else's service.
The wallet configuration screen also treats NWC as a specific implementation. It expects a string that starts with the Nostr Wallet Connect scheme and presents it as a connection option alongside other wallet backends. This gives a reader one clear mental model: in this mode ZEUS is a mobile interface for a remote wallet that already issued a NWC pairing URL.
When ZEUS becomes the NWC service
The more powerful direction lives in `stores/NostrWalletConnectStore.ts`. That store imports `NWCWalletService` and key-pair types from the Alby SDK, stores service and client keys, tracks app connections, starts relay subscriptions, publishes wallet service info and answers NIP-47 style requests. This is ZEUS operating as the wallet behind the connection, not merely as a client.
The implementation creates per-connection URLs in the `nostr+walletconnect://` form with a wallet public key, relay and secret. It can also include a Lightning Address value when the relevant ZEUS Pay setting is enabled. The connection is shown through UI components that can display a QR code, wait for the app to connect and then return the user to the connection list.
This is the part of ZEUS that deserves attention from Nostr app users. A ZEUS phone can become the wallet service for another app, while the user keeps the app connection specific to one tool. That is the practical promise of NWC: a client does not need to hold keys or funds, and a wallet does not need to become a social client. The phone can authorize a narrow payment channel between them.
Permissions, budgets and expiry are the guardrails
ZEUS models NWC connections with permission types, spend budgets and expiry. The connection model includes Full Access, Read Only and Custom permission modes. It also tracks budget renewal windows such as never, daily, weekly, monthly and yearly. The UI lets the user create or edit a connection, choose a relay, select permissions, set a maximum budget and choose when the connection expires.
The available permission methods include information, balance, payment, invoice creation, invoice lookup, transaction listing and message signing. The read-only preset is not the same as a spending-capable connection. A zap-heavy social app might need `pay_invoice`; a donation receiver might only need invoice creation; an accounting view might need transaction listing but no payment permission.
Budgets are where this becomes practical for everyday use. A connection that can pay invoices should not inherit the whole wallet. ZEUS tracks spending, remaining budget, warnings and activity status. If a user wants a Nostr client to zap from ZEUS, the safer default is a connection with a clear label, small limit, short expiry and permissions that match the app's real job.
Relays are part of the wallet path
ZEUS includes default NWC relay choices in the store, including relay URLs for Alby, Snort and Damus. The UI also supports custom relay entry with URL validation. That relay selection is not a decoration. NWC requests and responses move through Nostr relays, so reliability, latency, availability and privacy all affect the payment experience.
A NWC relay does not become the custodian of funds, but it can observe metadata around requests, connection timing and availability. It can also become a source of failure if it is down or blocked. A wallet connection that works in one country, on one network or during one relay's good day may fail elsewhere. ZEUS gives users a relay choice because relay choice is part of the operational setup.
The app also has mobile-specific handling for keeping NWC service behavior alive. The code and settings refer to persistent NWC service mode on Android and iOS keepalive behavior. That exists because phones are not servers. Operating systems aggressively suspend background work, and a wallet that is expected to answer remote app requests has to deal with that reality.
Backend support is not uniform
ZEUS contains multiple backend classes, and they do not all expose the same capabilities. The source showed NWC service support enabled for several serious wallet paths such as LND, Core Lightning REST, LNDHub, Lightning Node Connect, Embedded LND and LDK Node. The NWC client backend itself does not expose NWC service support, because it is already consuming another service.
Cashu support is also backend-dependent. The code showed Cashu wallet support for Embedded LND and LDK Node, while other backends did not advertise it in the same way. That lines up with the documentation, which says ZEUS introduced experimental Cashu ecash support and currently ties Cashu wallets to Embedded LND wallet setups while still allowing users to sweep Cashu tokens in other contexts.
This is why a checklist of features can mislead. A reader may see ZEUS, NWC, Cashu, Lightning Node Connect, LNDHub and LDK Node in the same project and assume every combination works the same. It does not. The actual wallet mode determines whether a feature is active, whether it is self-custodial, whether it can act as a NWC service and whether Cashu can be used directly.
ZEUS Pay adds the Lightning Address layer
ZEUS Pay is the project's Lightning Address service layer. The docs include pages for Zaplocker, Cashu lightning addresses, Nostr Wallet Connect remote lightning addresses and ZEUS Pay+. The NWC lightning address page says remote node users can receive payments directly to their nodes through the Nostr Wallet Connect protocol. That is a different product shape from a normal wallet receive screen.
The NWC lightning address docs are also explicit about best practice: the connection string used for this purpose should be invoice-only. The reason is straightforward. A service that only needs to create invoices for incoming payments should not also be able to access funds. A receive address is not a spending tool, and the NWC connection should reflect that boundary.
This distinction is valuable for readers who want a public address but do not want a hosted wallet. With the right setup, a ZEUS Pay address can route payment creation through a permissioned NWC connection and settle directly to the user's node. The setup still depends on relay availability, NWC software and correct permissions, but it points toward a more self-custodial address model.
Cashu is useful and explicitly risky
ZEUS documentation describes Cashu as a free and open-source Chaumian ecash protocol built for Bitcoin with good privacy properties. It also calls out the core risk: Cashu is custodial because the mint can steal funds. That warning belongs near the center of any honest ZEUS article because Cashu can make onboarding and small payments smoother, but mint trust does not disappear because the wallet UI is polished.
The docs explain that Cashu is part of a graduated wallet system. New users can get started more quickly, experience Lightning and even get a Lightning Address before moving toward stronger economic self-custody. In recent release notes, Cashu appears repeatedly: rewrites, offline mode, token sweeping fixes, multi-mint sends and token detection inside URLs. It is not a side experiment anymore.
For NWC, Cashu creates another axis of choice. ZEUS can use Cashu activity in its NWC transaction conversion paths, can route NWC payment handling through Cashu when configured, and can expose Cashu-related balances and activity depending on the backend. The user should understand whether a payment is coming from a Lightning channel, a remote node, an LDK wallet or ecash held at a mint.
Nostr appears beyond NWC
ZEUS also touches Nostr outside the strict NWC service. The README lists Nostr contact import as a feature. The package dependencies include `@nostr-dev-kit/ndk`, `nostr-tools` and an Alby SDK version modern enough to support NWC flows. The docs footer links the project's Nostr profile, and the community contact list includes Telegram, Slack, Twitter and Nostr.
That does not make ZEUS a general Nostr social client. The product still centers on money, nodes and wallet operations. Nostr is used where it helps: identity-adjacent contact discovery, NWC requests, wallet service discovery, relays and lightning-address infrastructure. Readers should not expect ZEUS to replace Damus, Amethyst, noStrudel or Primal as a social timeline.
The sharper reading is that ZEUS is a wallet that treats Nostr as useful infrastructure. That is often the more durable pattern. A wallet does not need to become a feed to participate in the Nostr economy. It needs a controlled way to let apps ask for wallet actions and a careful way to keep the user's money boundary clear.
Mobile background limits are real
NWC feels simple when a desktop wallet or server is always online. A phone is different. Android and iOS try to conserve battery, pause background activity and restrict long-running services. ZEUS code and settings around persistent NWC service mode, Android foreground behavior and iOS keepalive are there because a mobile wallet service has to fight normal mobile platform rules.
This matters when another app expects ZEUS to answer a NWC request. If the phone is offline, asleep, battery-optimized, force-closed or unable to reach the selected relay, the remote app may fail even though the wallet itself is healthy. Users should test the exact pattern they plan to rely on: foreground use, background use, locked phone, mobile data, Wi-Fi and travel networks.
The tradeoff is worth it for some readers. A phone-based NWC service keeps spending authority close to the user's device rather than a hosted backend. It can also be more transparent than giving every web app a direct custodial account. But the user should not expect a phone to behave like a server unless the app, operating system and battery settings are configured for that role.
Privacy depends on the chosen path
ZEUS contains privacy features such as Tor support and privacy mode, but the privacy story still depends on setup. A remote node over Tor differs from a public LNDHub endpoint. A NWC connection through one relay differs from a connection through several relays. A Cashu mint differs from a self-custodial Lightning channel. A Lightning Address exposes a human-readable receiving endpoint by design.
NWC adds its own privacy shape. The connected app may learn balance information, transaction lists, invoice details or payment success depending on permissions. The relay can see timing and event routing metadata. The wallet can see the app connection's behavior. That is not necessarily bad; it is the cost of making a remote app useful. The important part is matching permissions to the app's real need.
For a reader who wants good privacy, the starting point is not a slogan. Use a dedicated connection per app. Keep labels clear. Prefer invoice-only connections where possible. Avoid reusing NWC URLs. Review relay choice. Separate Cashu mint trust from Lightning node custody. Keep remote node credentials scoped. Revoke old connections. ZEUS gives many of the controls, but the user has to use them.
What to test before relying on ZEUS
A serious first test should use tiny amounts. Create a local or remote wallet setup, verify backup and recovery instructions, receive a small invoice, pay a small invoice, inspect the activity screen and confirm that channel or backend state matches what the app shows. Then test the same flow through the actual network path you plan to use: Tor, Lightning Node Connect, LNDHub, Core Lightning, LDK Node or Embedded LND.
For NWC, create a fresh connection for one app. Give it the minimum permissions that app needs, set a small budget, choose an expiry, select a relay and scan or copy the connection into the app. Test invoice creation, payment, balance reads and transaction reads only if those permissions are intentionally granted. Then revoke the connection and confirm the remote app stops working.
For ZEUS Pay and Lightning Address use, confirm whether payments settle to a node, to Cashu or through another model. The NWC lightning address path should be invoice-only. If Cashu is involved, test mint restore behavior, token sweeping and the backup path before holding meaningful value. For direct APK or IPA installs, compare release signatures and hashes rather than assuming the file name proves authenticity.
Who ZEUS fits best
ZEUS is strongest for Bitcoin users who want a mobile wallet that can grow with them. A beginner can start with a simpler local path. A node runner can connect to LND or Core Lightning. A builder can use NWC app connections. A merchant can explore point-of-sale tooling. A privacy-conscious user can choose Tor, scoped credentials and careful relay choices. The same app can cover several stages of competence.
It is less suited to someone who wants a completely abstracted custodial account with no operational choices. ZEUS asks the user to care about backend type, backup, connection strings, channels, relays, permissions and releases. That is not a flaw, but it is part of the product. The app is powerful because it exposes real wallet machinery instead of hiding every tradeoff behind a single balance number.
Nostr users who want zaps from a phone should look at ZEUS carefully. It can be the wallet behind apps rather than another social frontend. The best experience will come from pairing it with apps that respect NWC limits and from keeping each connection specific. When that discipline is present, ZEUS becomes one of the more capable mobile anchors for Nostr payments.
The reader takeaway
ZEUS is a major wallet in the Nostr Wallet Connect story because it brings NWC to a real mobile Bitcoin wallet with node management, local wallet options, Cashu, ZEUS Pay and active release work. It is not a thin demo around NIP-47. It is a wallet project that has absorbed NWC into the parts of the app where outside apps need controlled access to money.
The strength is flexibility: remote node, local wallet, LDK Node, Embedded LND, Lightning Node Connect, LNDHub, Core Lightning, Cashu, Lightning Address and point-of-sale paths can all appear in the same product family. The risk is the same flexibility. A reader should always know which backend is active, which app connection can spend, which relay is in the middle and which funds are self-custodial.
Used carefully, ZEUS can make a phone the user's Lightning control surface and NWC wallet service. Used casually, it can grant too much authority to too many apps. The difference is not hidden in branding. It is visible in the connection screen, the permissions, the budget, the expiry, the release source and the backup plan.
Sources worth opening
Start with the official ZEUS site, documentation, GitHub repository, release notes, store listings, source files for Nostr Wallet Connect, ZEUS Pay documentation, Cashu documentation and the protocol specifications that the app relies on.
- ZEUS official website
- ZEUS download page
- ZEUS documentation
- ZEUS remote or embedded wallet documentation
- ZEUS remote connections documentation
- ZEUS local wallets comparison
- ZEUS Cashu documentation
- ZEUS Lightning Address intro
- ZEUS Nostr Wallet Connect lightning address docs
- ZEUS Pay+ documentation
- ZEUS GitHub repository
- ZEUS README
- ZEUS package.json
- ZEUS license
- ZEUS reproducible builds documentation
- ZEUS PGP key
- ZEUS GitHub API repository metadata
- ZEUS GitHub releases
- ZEUS v13.1.0-beta2 release
- ZEUS v13.0.2 release
- ZEUS v13.0.0 release
- ZEUS Google Play listing
- ZEUS Apple App Store listing
- ZEUS Zapstore listing
- ZEUS Nostr profile
- ZEUS Nostr Wallet Connect backend source
- ZEUS Nostr Wallet Connect store source
- ZEUS NWC connection model
- ZEUS Nostr Connect utilities
- ZEUS NWC settings view
- ZEUS add or edit NWC connection view
- ZEUS NWC connection QR view
- ZEUS NWC connections list view
- ZEUS NWC connection activity view
- ZEUS NWC lightning address creator
- ZEUS NWC address settings
- NIP-47 Nostr Wallet Connect
- nwc.dev
- Alby JavaScript SDK
- Nostr Development Kit
- nostr-tools
- Lightning Node Connect documentation
- LND documentation
- Core Lightning documentation
- LDK Node project
- Cashu website
- Cashu documentation
- Cashu NUT specifications
- LNURL specifications
- Lightning Address
- Awesome NWC
