CraysBitBanana
BitBanana turns an Android phone into a remote control for a Lightning node or wallet backend, with Nostr Wallet Connect as one of its supported connection paths.
A remote control for Lightning, not a normal wallet account
BitBanana describes itself with unusual precision. It says it is not a classical Bitcoin Lightning wallet because it can only be used together with a Lightning node or wallet backend. That sentence is the key to the whole project. BitBanana is the Android surface. The money sits behind the backend the user connects to.
That backend can be LND, Core Lightning, LndHub or Nostr Wallet Connect. If the user controls the node or wallet service, BitBanana becomes a mobile control panel for that user's own infrastructure. If the backend belongs to somebody else, BitBanana can still talk to it, but the user's trust model changes. The app's job is to make that distinction visible.
The clean way to read BitBanana is as a wallet interface with serious payment and node-management depth. It is not automatically the custodian, the node operator or the Lightning service provider. It connects the phone to those pieces and gives the user a polished way to operate them.
The project grew out of Zap Android
BitBanana is maintained by Michael Wuensch and grew out of Zap Android. The repository keeps the older history and the rebranding note explains why the name changed. Zap Android, Zap iOS and Zap Desktop had separate codebases and separate maintainers, and users often confused information about one implementation with another. BitBanana created a clearer identity for the Android project.
The rebranding also says that the Zap team around Jack Mallers had shifted its focus to Strike, while the Android maintainer wanted to continue the work under his own name. The fork happened at tag `v0.5.9-beta`, and the backup and restore feature was kept so existing Zap Android users could migrate contacts and connected nodes.
That history matters because BitBanana is not a throwaway NWC demo. It has years of Android wallet-interface work behind it. The app inherited a node-operator focus and then added its own features, design, release process, translations, F-Droid availability and a distinct support community.
Where Nostr enters the app
Nostr enters BitBanana through Nostr Wallet Connect. The README lists NWC beside LND, Core Lightning and LndHub as a supported remote Lightning node or wallet connection. The Android manifest registers `nostr+walletconnect` as a URI scheme the app can receive. The manual setup screen offers Nostr Wallet Connect as a backend type.
In practice, that means a user can paste or scan a NWC string created by another wallet service. BitBanana parses the string, validates the public key, relay and secret, stores it as a remote backend configuration, and then uses an NWC client to ask the wallet service for payment actions. The user gets a familiar BitBanana interface while the connected NWC service remains the actual wallet.
This makes BitBanana useful for Nostr users who prefer a dedicated Android wallet interface rather than the wallet panel inside a social client. It also keeps expectations honest. BitBanana does not post notes, follow people or manage a Nostr social identity. Its Nostr role is wallet access through NIP-47.
NWC is one backend among several
BitBanana's backend model is broader than Nostr. The `BackendConfig` class defines backend types for LND over gRPC, Core Lightning over gRPC, LndHub and Nostr Wallet Connect. The same app can therefore manage different wallet surfaces, each with its own connection data, network, authentication material, Tor settings and quick receive configuration.
That design is useful because Lightning users are not all in the same place. Some run LND. Some run Core Lightning. Some use LndHub. Some receive a NWC string from a wallet service. BitBanana tries to be the phone interface across those choices instead of forcing users into one server stack.
The tradeoff is complexity. A person connecting to their own LND node has a different risk profile from a person pasting a NWC string from a custodial hosted wallet. A person using Core Lightning may see different feature support than a person using NWC. BitBanana can unify the interface, but the backend still determines custody, permissions and available functions.
The NWC parser is strict where it should be
The Nostr Wallet Connect parser expects the `nostr+walletconnect://` URI shape described by NIP-47. It checks that the host is a 64-character hex public key, that the query includes a relay, and that the secret is a 64-character hex value. It also accepts an optional `lud16` Lightning Address field and stores it as a quick-receive configuration when valid.
The parser then asks the Rust Nostr SDK to parse the URI on supported Android versions. That second validation step is important because hand-written URL checks can miss edge cases. BitBanana performs its own friendlier checks first so it can show clearer errors, then uses the Nostr SDK for the protocol object.
The output is a BitBanana backend configuration. The source and backend type become Nostr Wallet Connect, the location becomes remote, the full connect string is stored, and the NWC backend can later open the connection. This is the practical bridge between a NIP-47 URI and the rest of the app.
The NWC client translates BitBanana actions
The NWC client code opens a connection by parsing the current backend's NWC string, creating `NostrWalletConnectOptions`, setting a timeout based on the app's backend timeout, and constructing an NWC client with the Rust Nostr SDK. If parsing or option creation fails, BitBanana sets a backend error rather than pretending the wallet is connected.
The NWC API then maps app actions to wallet-service calls. `getCurrentNodeInfo` calls `getInfo`, reads the network value, marks keysend support when the service reports `pay_keysend`, and builds BitBanana's node-info model. `getBalances` calls `getBalance`. Invoice creation calls `makeInvoice`. Invoice lookup calls `lookupInvoice`. Transaction screens call `listTransactions` for incoming and outgoing items.
Payments follow the same pattern. A BOLT11 invoice payment becomes `payInvoice`. A keysend payment becomes `payKeysend` with TLV records. BOLT 12 payment is not implemented for the NWC backend in the code path reviewed. The reader should therefore think of BitBanana as an adapter: it exposes a consistent mobile wallet interface, then translates into whatever the backend actually supports.
The app warns about custodial NWC
BitBanana's user guardian system is one of its strongest design signals. The app contains warning text for NWC connections that says a Nostr Wallet Connect wallet may be custodial unless the user is the host of the NWC service. It also warns that the service entity can control the money and view transaction history, and tells the user to deposit only what they are willing to trust with that service.
That is a mature way to present NWC. NIP-47 is a protocol for wallet communication. It does not, by itself, prove self-custody. A NWC string can point to a wallet service the user runs, a wallet inside a self-hosted stack, or a hosted account controlled by another operator. The connection format is not the custody model.
BitBanana also warns before connecting to a NWC public key and asks the user to check it carefully. That matters because a wrong NWC string is not like a wrong website bookmark. It can connect the app to a wallet service that may receive payment requests. The app's caution is part of the product, not a side note.
Self-custody depends on the backend
BitBanana says it is fully self-custodial when used with the user's own infrastructure and that the BitBanana team does not know the user is using the app. That statement is credible in the app's own role: BitBanana is open source, runs locally on Android, and connects directly to the configured backend rather than routing through a BitBanana service.
The harder truth is that self-custody is inherited from the backend. If BitBanana connects to the user's own LND or Core Lightning node, the user is much closer to self-custody. If it connects to LndHub run by someone else, the app warns that the setup can be custodial. If it connects to a NWC service run by someone else, the same warning applies.
This is the right kind of nuance for a wallet interface. The app can protect local access, warn about dangerous actions, avoid data collection and support Tor. It cannot make a custodial backend non-custodial. Readers should judge the full payment path, not only the Android app.
Node management is a major part of the product
BitBanana is not only a send-and-receive screen. The feature list includes managing multiple nodes, peers, channels, routing fees, routing summaries and watchtowers. That makes it closer to a mobile node console than a normal consumer wallet. The phone becomes the place where a node operator can check and act while away from the machine.
That explains why the app speaks LND and Core Lightning directly. A social-client wallet can hide node details because it mostly needs zaps. BitBanana exposes infrastructure controls. Users can manage channels, inspect routing, work with watchtower behavior and handle on-chain and Lightning wallet surfaces tied to their node.
NWC support does not replace that node-management identity. It adds a wallet-interface path for services that speak NIP-47. A NWC backend will not necessarily expose the same channel or routing functions as a direct LND or Core Lightning connection. BitBanana's real feature set depends on the backend type in use.
Payments cover more than zaps
BitBanana handles on-chain and off-chain payments, Lightning invoices, Lightning Addresses, keysend, LNURL pay, withdraw, auth and channel flows, NFC, transaction filters, labels, UTXO handling, SegWit and Taproot address support, sign and verify tools, and multiple Bitcoin unit displays. These are not social-app wallet extras. They are node-operator wallet features.
The latest GitHub release checked for this article was `v1.0.1`, published in April 2026. Its release notes added receiving funds by NFC on a generated Lightning invoice using LNURL-withdraw, reading NFC text tags, full Persian and Spanish translations, updated translations, a fix for Core Lightning connect string certificate and key parsing, and a fix for missing route hints in edge cases.
For Nostr readers, the important lesson is scale. BitBanana can be the wallet interface for NWC payments, but the app is not built only for zaps. It is meant to control a broader Bitcoin and Lightning wallet environment from Android. A user should understand it beside node wallets and power-user tools, not only beside social clients.
Privacy is more than a slogan here
BitBanana's public site says the app has zero data collection and is 100 percent self-custodial. The privacy notice says the author does not collect, use, maintain or share personal information when the app is used, and does not use tracking technology. It also separates app-store relationships from BitBanana itself, because Google Play or another store may know things the app author does not.
The code and feature list support that privacy posture with practical controls. BitBanana supports Tor, self-hosted block explorers, self-hosted exchange-rate providers and self-hosted fee estimation providers. It can warn before opening sensitive data in a normal browser when Tor is enabled in the app. It can hide balances and use a stealth mode that makes the app less obvious on the device.
Readers should still think in layers. Tor inside BitBanana does not hide what a custodial wallet service knows. Self-hosted block explorers help avoid leaking address lookups to third parties, but only if the user actually configures them. Privacy is strongest when the phone, backend, network path and external services are aligned.
The guardian system teaches wallet hygiene
BitBanana's guardian warnings are unusually concrete. The app warns about clipboard replacement risks, remote server connections, NWC public keys, old node software, zero-amount invoices, unspecified-amount invoice behavior, certificate verification, backup restore overwrites, custodial LndHub, custodial NWC, restricted LND accounts, low on-chain fees, watchtower removal, logs and UTXO consolidation privacy.
Those warnings are not abstract education text. They sit near the actions that can cause loss of funds or privacy leaks. A user copying a Lightning invoice is reminded that other apps may see or modify clipboard data. A user disabling certificate verification is warned about man-in-the-middle risk. A user consolidating UTXOs is warned that address linkage can weaken privacy.
This is one reason BitBanana reads like a node-operator app rather than a glossy wallet shell. It assumes the user may make powerful choices and tries to slow down the dangerous ones. That design fits Nostr Wallet Connect especially well because NWC can make wallet actions feel simple while hiding serious trust decisions behind a short URI.
Android distribution is broad
BitBanana is available from GitHub releases, F-Droid, Google Play, OpenAPK and Android Freeware. The official site links to the main download options and the README lists the same channels. That gives users a choice between app-store convenience, F-Droid style distribution and direct APK verification.
The Google Play listing checked for this article showed the package `app.michaelwuensch.bitbanana`, developer Michael Wuensch, finance category, more than 5,000 installs, a 4.4 rating with dozens of ratings, version 1.0.1 and an April 2026 update. F-Droid presents the app as free and open source and repeats the important positioning: BitBanana is not a wallet on its own, but a remote control for a node.
The distribution mix matters for trust. A user can install from Google Play, but the app's open-source and reproducible-build story lets more technical users verify what they are running. For a wallet interface, that matters more than usual. The software handles payment paths and connection secrets, so distribution integrity is part of the security model.
Reproducible builds are treated seriously
BitBanana's README calls out reproducible releases, and the docs explain why that matters. If an open-source wallet app cannot be reproduced from its public source code, users have a weaker basis for trusting the distributed APK. A malicious or accidental difference between source and binary could affect funds or private data.
The project provides instructions for verifying GitHub and F-Droid releases with Docker and `disorderfs`, then comparing the built APK with the downloaded release. Starting with version `v0.9.4`, the release verification docs also describe signature files for APK authenticity, including importing the maintainer's public signing key and checking the `.asc` signature.
The README also links to WalletScrutiny's page for BitBanana and notes that the app passed WalletScrutiny's reproducibility check. Readers should still verify the current version they install, but the presence of this process is a strong positive signal. It shows that BitBanana's security story extends beyond in-app warnings.
Android permissions match the app's job
The Android manifest asks for camera, vibration, internet, network state, biometric, NFC, WireGuard tunnel control, foreground service and notification permissions. Those permissions fit the visible feature set: scanning QR codes, reading NFC tags, connecting to remote nodes, protecting app access, automating VPN paths and keeping long-lived network connections alive.
The manifest also registers several wallet and node-related URI schemes: `bitcoin`, `lightning`, `lndconnect`, LNURL variants, `keyauth`, `clngrpc`, `lndhub` and `nostr+walletconnect`. That means BitBanana can be opened from links, QR scans or NFC tags carrying the kind of connection and payment data it understands.
Permissions are still worth reviewing before installation. Camera and NFC are expected for a wallet interface, but they are also sensitive device capabilities. The better question is whether the requested permissions line up with the user's intended use. In BitBanana's case, the permission set is broad because the app is broad.
Language and accessibility work are visible
BitBanana is available in many languages and supports right-to-left layouts for Arabic languages. The Gradle configuration lists many packaged languages, and the README credits Weblate for community translation work. The translation docs explain that updates are usually brought into the next release and that languages need enough coverage to stay visible in the app.
This matters for a wallet because misunderstandings can cost money. A user who cannot read the warning around custodial NWC, certificate verification or zero-amount invoices may make a bad decision even if the software is technically sound. Translation is therefore not cosmetic. It is part of the safety surface.
The app's educational posture also appears in the docs and website. BitBanana says it provides explanations and help across the app. That is a good fit for node management, where even experienced Bitcoin users can be surprised by channel behavior, watchtowers, route hints, fee policies or backend connection formats.
What to check before using BitBanana with NWC
Before pasting a NWC string into BitBanana, the user should identify who operates the wallet service. If it is the user's own service, the next questions are uptime, relay choice, spending permissions and backup. If it is somebody else's service, the user should assume that operator can affect funds and transaction visibility unless the service proves otherwise.
The user should also learn what methods the NWC service supports. BitBanana can display and use features that the backend reports, but unsupported methods will limit the experience. A service may support invoice creation and payment, but not keysend. It may support balance but not transaction history. It may expose a Lightning Address through `lud16`, or it may not.
Finally, the user should protect the connection string. The NWC URI contains a secret. Store it like a wallet credential, not like a public address. If an experiment is temporary, revoke the connection from the wallet service after use. BitBanana can be a good Android interface, but the lifecycle of the NWC permission still belongs to the wallet service.
Where BitBanana shines
BitBanana shines for users who want a real Android control surface for Lightning infrastructure. It is especially attractive when the user already has an LND or Core Lightning node and wants mobile access without handing custody to a third party. The app's channel, routing, watchtower, UTXO, contact and privacy tools make sense in that world.
It also shines for people comparing wallet-interface design. BitBanana does not reduce wallet safety to a single marketing phrase. It distinguishes backend types, warns about custodial arrangements, provides reproducible-build instructions, offers F-Droid distribution, and gives advanced users ways to keep lookups and connections closer to their own infrastructure.
For Nostr, the shine is narrower but useful. BitBanana gives NWC a serious Android home outside social clients. A user can connect a NWC service and interact through a wallet interface that was built for node operators, not only for zaps. That makes it a meaningful entry in the NWC ecosystem even though Nostr is only one part of the app.
Where it is the wrong tool
BitBanana is the wrong tool for someone who wants a wallet account without understanding the backend. It does not remove the need to know whether the user controls the node, whether the connected service is custodial, whether the NWC string can spend, or whether the backend supports the desired features.
It is also not an iOS option, a desktop dashboard or a Nostr social app. The project is Android first. Its strength is the phone-as-control-panel model. Users who want a web wallet, a browser extension, a social wallet inside a client or a hosted onboarding account will likely prefer a different product.
The best way to use BitBanana is to respect its honesty. It can give a phone superpowers over a Lightning node or wallet backend. It cannot make a weak backend safe, an unknown operator trustworthy or a leaked NWC secret harmless. The app is strongest when the user knows exactly what it is connected to.
Sources worth opening
Open the BitBanana site and README first, then compare the Android code for backend configuration, NWC parsing, NWC API calls, guardian warnings, privacy, reproducible builds and the current release notes.
- BitBanana official site
- BitBanana documentation
- BitBanana download page
- BitBanana GitHub repository
- BitBanana README
- BitBanana license
- BitBanana privacy notice
- BitBanana rebranding note
- BitBanana install guide
- BitBanana regtest guide
- BitBanana verify release guide
- BitBanana reproducible builds guide
- BitBanana GitHub and F-Droid reproduce guide
- BitBanana Play Store reproduce guide
- BitBanana translation guide
- BitBanana latest release v1.0.1
- BitBanana releases
- BitBanana on F-Droid
- BitBanana on Google Play
- BitBanana on WalletScrutiny
- BitBanana Weblate project
- BitBanana Android build file
- BitBanana Android manifest
- BitBanana backend configuration model
- BitBanana NWC URI parser
- BitBanana NWC backend
- BitBanana NWC client
- BitBanana NWC API adapter
- BitBanana Rx NWC wrapper
- BitBanana remote connect utility
- BitBanana user guardian
- BitBanana English app strings
- NIP-47 Nostr Wallet Connect
- nwc.dev
- Rust Nostr SDK
- Lightning Polar
