Phoenix Wallet primary-source snapshot
Fetched: 2026-05-01 UTC
1) Public README
Source: https://raw.githubusercontent.com/ACINQ/phoenix/master/README.md
Selected excerpts from the official repo:
Phoenix is a Bitcoin wallet developed by ACINQ, that allows you to send and receive bitcoin securely over the Lightning Network.
It is self-custodial, which means that you hold the keys of the wallet.
It provides a simple and clean UX.
Thanks to native Lightning support, payments are faster and cheaper.
This wallet is self-custodial.
When creating a new wallet, a 12-words recovery phrase is generated.
Additional signals from the source:
- The README is explicit that Phoenix is not just Lightning-compatible but Lightning-native and self-custodial
- The build layout also shows Phoenix is a substantial codebase with shared Lightning business logic plus separate Android and iOS frontends
2) FAQ: trust model and wallet architecture
Source: https://phoenix.acinq.co/content/faq.md
Selected excerpts from the FAQ:
Phoenix is a real, self-contained Lightning node that runs on your phone.
It does not require you to run another Lightning node at home or in the cloud.
It is not a custodial wallet either, you are in full control of your funds.
Phoenix is trust-minimized, but not trustless.
Swaps are trustless.
You can configure Phoenix to use your own Electrum server to watch the Blockchain and monitor your channels.
Additional signals from the source:
- This is the clearest primary-source explanation of what Phoenix actually is: a mobile node with explicit trust tradeoffs, not a generic wallet shell
- The documentation is unusually candid about where trust remains and where it has been reduced, which is useful for categorization
3) FAQ: liquidity, fee model, and Lightning operations
Source: https://phoenix.acinq.co/content/faq.md
Selected excerpts from the FAQ:
Sending via Lightning — 0.4 % + 4 sat
Receiving via Lightning — 0 (no fees)
Receiving via Lightning with insufficient liquidity — 1% + mining fees
Requesting liquidity — 1% + mining fees
Channel creation — 1000 sat
It is the amount that you can receive within your existing channel, without incurring any fee.
Depending on your use case, if you know you are going to receive more than spend, then it makes sense to request inbound liquidity in bulk ahead of time.
Additional signals from the source:
- Phoenix is documenting a real liquidity-management surface, not just a wallet send/receive screen
- The bucket analogy and fee table show that channel-capacity management is a first-class user-facing concept in the product
4) FAQ: onchain behavior and limitations
Source: https://phoenix.acinq.co/content/faq.md
Selected excerpts from the FAQ:
There is no on-chain balance. Phoenix is a pure LN wallet, all your funds are always in channels.
You can still send and receive on-chain payments with swaps, they are completely transparent.
As soon as the transaction to this address is published, Phoenix will notify that you have incoming funds.
The incoming transaction needs to reach 3 confirmations, and then it will be swapped to Lightning.
Phoenix has been designed for less technical users.
You would be better off with a “remote-control” app to your Lightning node.
Additional signals from the source:
- The docs make clear that Phoenix is purpose-built around Lightning-first operation and not around remote control of an existing node
- That sharp product boundary helps distinguish Phoenix from node-dashboard wallets such as Zeus or RTL-like tooling
5) Phoenix 2.0 splicing update
Source: https://acinq.co/blog/phoenix-splicing-update
Selected excerpts from the official blog post:
Splicing changes the game.
Phoenix now manages a single dynamic channel, full control on inbound liquidity, better predictability, trustless swaps.
each user has only one channel
there is no more scattered liquidity or splitting issues
the 1% / 3000 sat fee is replaced by the mining fee for the underlying on-chain transaction
Removing funds from a channel (it’s called a splice-out), effectively translates to making an on-chain transaction directly from your channel.
No swap service is needed and the operation is trustless.
Additional signals from the source:
- This post is the key primary-source evidence that Phoenix evolved into a splicing-based Lightning operating stack rather than staying a multi-channel wallet abstraction
- The fee-model discussion also shows that the product team thinks in terms of UTXO efficiency, future close risk, and channel economics, not just app UX
6) Swaproot update
Source: https://acinq.co/blog/phoenix-swaproot
Selected excerpts from the official blog post:
Depositing on-chain funds to Phoenix is now cheaper and more private.
Phoenix will generate a new swap-in address every time you receive a transaction.
swap-in transactions are now cheaper, harder to track on-chain
Phoenix uses a trustless, instant swap-in protocol
Phoenix triggers a zero-conf splice.
Additional signals from the source:
- The swaproot writeup shows Phoenix is still evolving its trust-minimized bridge between onchain Bitcoin and Lightning channels using current Bitcoin primitives
- Taproot, MuSig2, and descriptor usage make Phoenix especially worth cataloging as wallet-control-plane infrastructure rather than as a generic mobile wallet
Notes
- Phoenix Wallet appears best cataloged as bitcoin-lightning wallet-control-plane / self-custodial mobile-node and splicing infrastructure / trust-minimized onchain-lightning bridge.
- No canonical standalone whitepaper or litepaper surfaced in this pass.
- The most useful primary sources were the FAQ markdown, Phoenix technical blog posts, and the public README.