Scoping Zeus

Why Zeus is in the Red Team cut: a mobile Lightning wallet where the phone holds credentials, talks to nodes, and moves money with a tap.

Zeus is the third project in the Red Team cut, alongside SeedSigner and bitcoinjs-lib. This is a scope, not a findings post.

What it is

Zeus is a self-custodial Bitcoin and Lightning wallet for Android and iOS. It is written in TypeScript on React Native and licensed AGPLv3. Source lives at ZeusLN/zeus.

It is also a node manager. The same app can run an embedded LND node on the phone, or connect to a remote LND or Core Lightning node, an LNDHub account, Nostr Wallet Connect, or Cashu. It supports Tor, PIN or passphrase encryption, LNURL, Lightning addresses, NFC payments, watch-only accounts, and external signers. The project documents reproducible builds.

Why it is in the cut

bitcoinjs-lib is code that wallets import. SeedSigner is the device that signs. Zeus is the layer most people actually touch: an app on a phone that holds credentials, talks to nodes, and sends money with a tap.

The blast radius is not only keys. A remote-node wallet stores the credentials that let it drive someone’s node: macaroons, runes, connection strings. If one of those leaks, or grants more than the user thinks it does, someone else can spend from a node the user runs at home.

It is also a different kind of software from the rest of the cut: a mobile app with a JavaScript runtime, native modules, platform keychains, deep links, and QR codes and NFC as input. That is where my years of mobile testing are useful, and where a model can read a lot of TypeScript quickly.

Surfaces I will treat as in-scope

Public source and my own test wallets on testnet or regtest. Not other people’s nodes, not mainnet funds, and not the project’s infrastructure.

Backends and credentials. Embedded LND, remote LND, Core Lightning, LNDHub, Nostr Wallet Connect, and Cashu. How credentials are stored, shown, exported, and scoped, and whether switching between backends leaves anything behind.

Payment input. Invoices, LNURL, Lightning addresses, QR codes, NFC, and deep links. The same question as SeedSigner: does what the screen shows match what gets paid?

Local protection. PIN and passphrase encryption, privacy mode, and what survives backgrounding, screenshots, and restarts.

Network paths. Tor, clearnet fallbacks, and what leaks when a connection fails.

Build and release. Reproducible builds, and the path from a git tag to an app store binary.

backends   # embedded LND, remote nodes, LNDHub, NWC, Cashu
input      # invoices, LNURL, QR, NFC, deep links
storage    # credentials, PIN, privacy mode, backgrounding
network    # Tor, fallbacks, failure modes
release    # reproducible builds, tag to store

How I will use AI here

The same rule as the rest of the cut: a claim has to point at a line, and it only counts once I reproduce it on my own build. Models are good at reading a large TypeScript codebase for places where input is trusted or a credential crosses a boundary. They are bad at knowing what a phone actually does at runtime, so every lead gets checked on a device.

Disclosure

Zeus asks for security reports by email to security@zeusln.com, encrypted with the PGP key in SECURITY.md, and never through public issues. I have already reported one issue privately. Its details stay with the maintainers, and this blog will not describe it.

Previous: bitcoinjs-lib. Strategy: the scoping post.