Summary: Phoenix Wallet is better cataloged as self-custodial Lightning operating infrastructure than as a simple Bitcoin wallet app. Its primary-source materials jointly define a real Lightning node running on the phone, a single dynamic channel managed with splicing, explicit inbound-liquidity controls, transparent onchain swap-in and splice-out behavior, and unusually candid documentation about trust, privacy, fee tradeoffs, and failure recovery. The result is a wallet that packages a substantial slice of Lightning channel and liquidity management into a mobile-first control plane.
What it does:
Provides a self-custodial Bitcoin wallet for iOS and Android where the user holds a 12-word recovery phrase and Lightning is the primary operating layer
Runs a real self-contained Lightning node on the phone rather than requiring the user to operate a separate node at home or in the cloud
Manages a single dynamic Lightning channel using splicing, so the wallet can grow or shrink channel capacity instead of accumulating many static channels
Supports inbound-liquidity reservation and fee controls so users can manage when incoming payments trigger onchain channel-management costs
Handles onchain deposits and withdrawals through trust-minimized Lightning-channel operations, including splice-based swap-outs and Phoenix-controlled swap-ins that remain under the user’s control
Supports restoration from seed across current Android and iOS 2.x versions and allows connection to a user-chosen Electrum server for blockchain watching and channel monitoring
Key claims:
The public README says Phoenix is a self-custodial Bitcoin wallet developed by ACINQ that lets users send and receive bitcoin over Lightning while they hold the keys
The FAQ says Phoenix is a “real, self-contained Lightning node that runs on your phone,” is not custodial, and gives users full control of funds, while also stating clearly that Phoenix is trust-minimized rather than fully trustless
The FAQ fee table says Lightning sending is priced at 0.4% + 4 sat, Lightning receiving is free when existing liquidity is sufficient, and channel creation is charged separately, which shows Phoenix documents its operating model in unusually concrete detail
The Phoenix 2.0 splicing update says the wallet moved to a single dynamic channel, replaced scattered multi-channel behavior with splicing, improved predictability around fees, and made swap-outs trustless by removing the need for a separate swap service
The FAQ says Phoenix is a pure Lightning wallet with no separate onchain balance, though users can still send to and receive from onchain addresses through transparent swap flows
The FAQ says users can point Phoenix at their own Electrum server to reduce dependency on third parties, but also says Phoenix is not designed for connecting to arbitrary or self-run Lightning nodes because its tradeoffs target less technical users
The Swaproot blog post says Phoenix now uses Taproot, MuSig2, and descriptors so swap-in addresses rotate, deposits are harder to track onchain, and swap-in spending costs are reduced
Whitepaper: No canonical standalone Phoenix Wallet whitepaper or litepaper surfaced in this pass. The clearest current sources of truth were the public FAQ markdown, ACINQ’s Phoenix technical blog posts, and the public repository README; see ../whitepapers/phoenix-wallet-primary-sources-2026-05-01.md.
Reusable lens: Phoenix Wallet matters because it exposes the operating model plainly instead of pretending channel, liquidity, and fee management disappeared