phoenixd

• Name: phoenixd
• URL: https://phoenix.acinq.co/server
• Category: Lightning node infrastructure / self-custodial server wallet / API-first payments control plane / automated-liquidity middleware
• Tags: bitcoin-ecosystem
• Summary: phoenixd is an API-first self-custodial Lightning control plane, not a general routing node and not just Phoenix Wallet with a server sticker on it. ACINQ’s own materials describe a minimal specialized node for sending and receiving payments over an HTTP API with automated liquidity handling for receive-heavy workloads. The real value is that it compresses messy Lightning operations into a developer-facing daemon while still leaving the seed and final funds under the operator’s control.
• What it does:
  • Runs a self-custodial Lightning daemon for Linux, macOS, and Windows/WSL using the same core software lineage as Phoenix Wallet
  • Exposes a local HTTP API and companion phoenix-cli so applications can create invoices/offers, pay invoices/offers/Lightning addresses, inspect balances and channels, and export payment history
  • Automates inbound-liquidity management for receive-heavy workloads, including large-chunk auto-liquidity purchases and fee-credit buffering for small incoming payments
  • Supports reusable Bolt12 offers, BIP-353 Lightning addresses, LNURL-pay / withdraw / auth flows, per-invoice external IDs, and per-invoice or global webhook notifications
  • Streams payment-received events over websocket and authenticates webhook payloads with an HMAC signature header for backend integration
  • Lets operators splice funds out to onchain Bitcoin addresses, bump fees with CPFP, and close channels without turning the product into a full routing-node operations stack
• Key claims:
  • The server FAQ says phoenixd is a “minimal, specialized Lightning node” for sending and receiving Lightning payments, runs on a server instead of a mobile device, uses an HTTP API instead of a GUI, and is designed for developers and businesses who want to build on Lightning with “minimum hassle and maximum reliability, without compromising on self-custody”
  • The same FAQ says users can get ready “in seconds” with “absolutely zero configuration,” explicitly listing no channel management, peer management, liquidity management, or firewall configuration as part of the intended operating model
  • The FAQ distinguishes phoenixd from Eclair by saying Eclair is a highly scalable general-purpose Lightning node for routing and large channel sets, while phoenixd is the minimal specialized payment-focused node
  • The FAQ also says phoenixd is self-custodial, generates a 12-word seed stored in ~/.phoenix/seed.dat, and warns that sharing the same seed across Phoenix instances can cause connection issues, payment failures, and force closes
  • The auto-liquidity docs say phoenixd is “always” accepting payments with “seemingly infinite inbound liquidity,” using large automatic liquidity purchases plus a non-refundable fee-credit buffer so small bootstrapping payments are not simply rejected
  • Those liquidity docs say the default auto-liquidity chunk is 2 million sat and that liquidity costs 1% plus mining fees, which is a concrete clue that phoenixd is packaging Lightning liquidity operations into a predictable backend product rather than leaving them entirely manual
  • The API reference says the API must not be exposed publicly, uses generated Basic-auth passwords, and supports both a primary password and a limited-access secondary password that is blocked from more dangerous endpoints such as payinvoice, sendtoaddress, closechannel, and export
  • The same API docs expose a broad backend surface including Bolt11 invoices, Bolt12 offers, BIP-353 Lightning addresses, LNURL flows, websocket payment events, webhook delivery with X-Phoenix-Signature, CSV export, and onchain splice-out / CPFP fee-bumping actions
  • The README and getting-started docs say phoenixd ships with a companion phoenix-cli, runs natively across major desktop/server targets, and can be downloaded and used in a few commands rather than assembled from many Lightning subsystems by the operator
• Whitepaper: No canonical standalone phoenixd whitepaper or litepaper surfaced in this pass. The clearest current sources of truth were ACINQ’s server FAQ, API and auto-liquidity docs, the getting-started page, and the public phoenixd repository / README; see ../whitepapers/phoenixd-primary-sources-2026-05-02.md.
• Sources:
  • https://phoenix.acinq.co/server
  • https://phoenix.acinq.co/content/server/faq.md
  • https://phoenix.acinq.co/content/server/get-started.md
  • https://phoenix.acinq.co/content/server/api.md
  • https://phoenix.acinq.co/content/server/liquidity.md
  • https://raw.githubusercontent.com/ACINQ/phoenixd/master/README.md

Internal linkages

• Closest product lineage: phoenix-wallet
• General-purpose Lightning node contrast inside the same company lineage: eclair
• Strongest app-facing comparison when the question is local daemon versus external wallet session layer: alby

Governance / control risk

• Practical leverage accumulates around auto-liquidity pricing and thresholds, which permissions are delegated through the limited API password, which webhook or backend systems are trusted, and how exposed or recoverable the server environment is.

• Last reviewed: 2026-05-28 UTC