Eclair

• Name: Eclair
• URL: https://github.com/ACINQ/eclair
• Category: Bitcoin Lightning node implementation / Scala Lightning daemon / HTTP-API-integrated node backend / Bitcoin-Core-coupled wallet-control plane
• Tags: bitcoin-ecosystem
• Summary: Eclair is a real Lightning node implementation and operator backend, not a wallet shell. The useful split is explicit: Eclair runs the Lightning state machine and HTTP/CLI control surface while Bitcoin Core still handles the onchain wallet, chain monitoring, and channel-close settlement. That makes Eclair a programmable Lightning control plane for operators and integrators, not an all-in-one consumer wallet.
• What it does:
  • Implements a Lightning node in Scala with support for standard Lightning peer, channel, routing, and payment flows
  • Exposes a detailed HTTP API plus eclair-cli for connecting peers, opening and closing channels, bumping fees, and sending or receiving payments
  • Uses Bitcoin Core for blockchain monitoring, funding transactions, wallet custody, and channel close settlement rather than shipping its own onchain wallet
  • Organizes the node around actor-based components for peers, channels, relaying, payment initiation, and payment reception, with optional cluster-oriented front-end daemons
  • Publishes advanced operator docs for Tor, PostgreSQL, circular rebalancing, monitoring, and managing Bitcoin Core keys
  • Supports operational monitoring through Kamon and Prometheus / Grafana integrations
• Key claims:
  • The repository README calls Eclair a Scala implementation of the Lightning Network, says it follows the Lightning Network Specifications (BOLTs), and describes a feature-rich HTTP API for application developers
  • The same README says Eclair relies on Bitcoin Core for blockchain interfacing and onchain funds, requires a synchronized non-pruned txindex-enabled node, and returns channel-close funds to the configured Bitcoin Core wallet
  • The API reference says requests use HTTP form data with JSON responses, documents authentication with HTTP Basic auth, and shows endpoints for node info, peer connection, channel opens, RBF fee bumps, CPFP, and channel closes
  • The architecture docs split the system into eclair-core, eclair-node, and eclair-front, and explain the actor model where peer connections, channels, and payment attempts are isolated actors that can scale and fail independently
  • The guides index shows operational depth beyond a basic node binary, including monitoring, Tor, clusterization, circular rebalancing, and PostgreSQL configuration
  • The monitoring docs say Eclair emits Lightning and system metrics through Kamon, supports Prometheus export, and ships Grafana dashboards in-repo for node operators
• Whitepaper: No canonical standalone Eclair whitepaper or litepaper surfaced in this pass. The clearest current sources of truth were the main repository README, the official API reference, and the repository docs for architecture, guides, and monitoring; see ../whitepapers/eclair-primary-sources-2026-05-02.md.
• Sources:
  • https://github.com/ACINQ/eclair
  • https://acinq.github.io/eclair/
  • https://raw.githubusercontent.com/ACINQ/eclair/master/docs/Guides.md
  • https://raw.githubusercontent.com/ACINQ/eclair/master/docs/Architecture.md
  • https://raw.githubusercontent.com/ACINQ/eclair/master/docs/Monitoring.md

Internal linkages

• Canonical implementation contrasts: lnd and core-lightning.
• Company / operator boundary above this implementation: acinq.
• Narrower ACINQ sibling when the question is payment-focused backend packaging rather than general node operations: phoenixd.
• End-user ACINQ distribution surface built on adjacent shared lineage: phoenix-wallet.

Protocol / company boundary

• Keep this note on the implementation surface: Lightning state-machine behavior, HTTP and CLI control, Bitcoin Core dependence, channel and payment operations, and the operator workflow of running Eclair as a real node backend.
• Use acinq when the sharper question is who packages Eclair alongside Phoenix, phoenixd, lightning-kmp, and the rest of ACINQ’s shared software lineage, and who decides how much Lightning operational complexity gets hidden versus exposed across that family.
• That split matters because how does Eclair work as a node backend? and which company is shaping the defaults, documentation, and cross-product operating posture around Eclair? are related but not identical questions.

Control surface

• Practical leverage sits in Bitcoin Core coupling, peer and channel policy, routing behavior, fee-bump and close workflow, API exposure, and how much operator discretion Eclair leaves visible instead of abstracting it away.

• For the higher-level packaging, distribution, and shared-default question across Eclair, Phoenix, and phoenixd, read acinq.

• Treat Eclair as a serious Lightning node backend, not as the full ACINQ story.

• Last reviewed: 2026-08-11 UTC