Phoenix puts a self-custodial Lightning wallet on Android and iOS

Self-custodial Lightning without running a node

Phoenix is a Bitcoin wallet from ACINQ that sends and receives payments over the Lightning Network while the user keeps the keys. The README frames the design goal plainly: you hold the keys, and the wallet exists to make that as painless as possible. Native Lightning support is the reason it feels different from an on-chain wallet, since payments are faster and cheaper. The audience is people who want to hold bitcoin themselves but do not want to operate a full node, and the second audience is developers who want to work on mobile Lightning code. What the project is not is a custodial account or an exchange. There is no server side balance in the model, no deposit address you hand to someone else, and no account recovery by support. The cost of that choice is stated in the same paragraph that describes the benefit, and it is worth reading the two together before installing anything.

One Kotlin core under an Android and an iOS interface

The repository is split into three modules, and the split explains most of the engineering decisions. `phoenix-shared` holds the business logic in Kotlin and is shared between the two applications, and it delegates everything Lightning and Bitcoin related to the separate lightning-kmp project. `phoenix-android` is the user interface for the newer Android application, written in Kotlin with Jetpack Compose. `phoenix-ios` is the user interface for the iOS application, written in Swift. So the protocol work exists once, in Kotlin, and the two apps are shells around it. That arrangement means a bug in fee handling or channel logic is fixed once rather than twice, and it also means the iOS app has no native Swift protocol layer of its own. For a contributor, the practical consequence is that most changes land in `phoenix-shared` and then surface through the `phoenix-android` and `phoenix-ios` modules.

Installing from the stores, or the APK from the releases page

Phoenix ships as an ordinary mobile app, so there is no server to install and no configuration file to edit. The README lists the download routes: for iOS it is on the App Store and requires iOS 15 or newer, and for Android it is on Google Play or available as an APK from the GitHub releases, requiring Android 8 or newer. The releases page also carries a testnet build, and the README links a Testnet APK badge alongside a CI badge for the testnet build workflow, which suggests a separate track for experimenting with testnet coins. Because the wallet is self-custodial, the relevant first action is not installation but key creation: when a new wallet is generated, a 12-words recovery phrase is produced, and the README is emphatic that only the user has it.

The recovery phrase is the entire custody model

There is no second factor and no support fallback in this design, and the README says so without hedging. Creating a wallet generates a 12-words recovery phrase, and the responsibility to back it up sits entirely with the user. The phrase gives full access to the funds, so the documentation tells you not to share it with anyone, and it says plainly that losing the phrase means the funds are lost. There is no mention of a passphrase, of a hardware signer, of multi-device sync, or of a threshold scheme, and there is no policy for a lost phrase in the README, because there cannot be one under this model. That asymmetry is the whole tradeoff: a custodial wallet can restore access because a third party holds a copy, and a self-custodial one cannot. The README also does not describe any key rotation or channel backup mechanism, so a reader should not assume recovery covers anything beyond restoring the wallet seed.

The Docker image pins Android SDK 33 and OpenJDK 17

Building from source is documented in BUILD.md, and the repository ships a Dockerfile that describes the CI environment precisely enough to reproduce it. The image is Ubuntu 24.04 with a UTF-8 locale, the Android command line tools downloaded from Google and unpacked into /usr/local/android-sdk, and a specific set of SDK packages installed: build tools 33.0.2 and the android-33 platform. The build JVM is openjdk-17-jdk installed through apt.

FROM ubuntu:24.04

ENV LC_ALL en_US.UTF-8
ENV LANG en_US.UTF-8
ENV LANGUAGE en_US:en
ENV ANDROID_API_LEVELS android-33
ENV ANDROID_BUILD_TOOLS_VERSION 33.0.2
ENV ANDROID_HOME /usr/local/android-sdk

Two details in the file matter for a local setup. The image deletes local.properties after copying the project in, so that properties are not read from the host environment, and it converts line endings with dos2unix so the Gradle wrapper behaves the same on every platform. A local.properties.template file sits in the repository root for the machine specific values the image throws away.

Where a phone wallet is the wrong tool

Phoenix covers a narrow slice of what a Bitcoin user might want, and outside that slice the project offers nothing. There is no option in the README for holding assets other than bitcoin, and no on-ramp or fiat conversion handled for you. For a user who wants a custodial balance with a support team behind it, or a business that needs accounting exports and a stablecoin on a platform that handles compliance, this wallet is the wrong shape of tool, and no configuration in the project changes that. The mobile only factor also means a phone compromise or a lost device sits directly in front of the funds. A second constraint is the release channel: the app is delivered through the App Store and Google Play, plus an APK from the releases page, so store policy and store availability sit between you and the build, and a version you want may not be the version your store serves.

Release cadence, licence and where to report problems

The recent release tags are Phoenix 2.8.4 on 2026-10-02, Phoenix 2.8.2 on 2026-09-08 and Phoenix 2.8.1 on 2026-06-18, all tagged with an android prefix, and the last push was on 2026-10-08. The README points bug tracking at GitHub issues and says pull requests are reviewed by members of the ACINQ team, and the contributing guidance points at the Eclair repository for routing nodes and the lightning-kmp repository for mobile nodes if your interest is the protocol rather than the app. Translation work is handled through a TRANSLATION.md guidelines file, and a SECURITY.md sits at the repository root. The licence is Apache 2.0, a permissive licence with an explicit patent grant, which is worth noting for anyone embedding the shared module in a commercial product.

Editorial conclusion

Phoenix is a reasonable fit for a user who wants to hold their own keys and move bitcoin over Lightning from a phone without running a node, and for developers who want to work on Lightning mobile code in Kotlin. It is the wrong choice for a custodial account, for a business that needs stablecoins or fiat onramps handled for it, and for anyone unwilling to write down a 12 word recovery phrase and keep it offline. Before trusting it with real funds, check that the 12 word phrase from wallet creation is written down and stored offline, confirm the app came from the App Store, Google Play or the GitHub releases rather than a mirror, and read the terms and privacy pages the README links to. The last push was on 2026-10-08 and the current Android release is Phoenix 2.8.4 from 2026-10-02.

Frequently asked questions

Official sources

1. ACINQ/phoenix on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases