phoenixd

• Name: phoenixd
• URL: https://phoenix.acinq.co/server
• Category: Lightning server wallet / payment-backend daemon
• Tags: bitcoin-ecosystem
• Summary: phoenixd is a specialized Lightning payment daemon. ACINQ packaged inbound liquidity, offers, webhooks, and payment handling into a small self-custodial server wallet so operators can run a backend without pretending to be a full routing node.
• 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.
• Company / operator boundary above this payment daemon: acinq.
• 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.

Protocol / company boundary

• Keep this note on the product surface: auto-liquidity behavior, invoice and offer APIs, webhook and websocket integration, password-scoped backend control, and the self-custodial server-payment workflow phoenixd exposes directly.
• Use acinq when the sharper question is who packages phoenixd with the wider ACINQ stack, decides the default liquidity posture and documentation style around it, and steers how much server-side Lightning complexity gets hidden behind the minimal specialized node story.
• That split matters because how does phoenixd behave as a payment daemon? and which company is shaping the surrounding operating assumptions and shared software lineage? are related but not identical questions.

Control surface

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

• The broader packaging and default-setting authority for phoenixd’s place inside the ACINQ family lives one layer up in acinq.

• Read it as a specialized payment daemon with packaged liquidity policy, not as a general Lightning node baseline and not as the whole ACINQ story.

• Last reviewed: 2026-08-11 UTC