Skip to content
Back to skills

Eclair

ASecurity

Eclair Lightning implementation by ACINQ: Scala/Akka, eclair-cli, plugin system, primarily backend service. Powers Phoenix wallet's server side and ACINQ's main routing node. USE WHEN: deploying Eclair as backend, integrating with ACINQ's Phoenix backend, evaluating Scala/JVM Lightning options.

  • 31 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 8, 2026
ai-agentsrustgojavabashsqlnodegitapidatabasebackend

Works with

  • cli
  • api

Security analysis

A100/100

Scanned September 22, 2026

npx -y skills add claude-dev-suite/claude-dev-suite --skill eclair --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Eclair?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Eclair
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/claude-dev-suite-eclair/badge)](https://www.skillsdirectory.com/skills/claude-dev-suite-eclair)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: lightning-eclair
description: |
  Eclair Lightning implementation by ACINQ: Scala/Akka, eclair-cli,
  plugin system, primarily backend service. Powers Phoenix wallet's
  server side and ACINQ's main routing node.
  USE WHEN: deploying Eclair as backend, integrating with ACINQ's
  Phoenix backend, evaluating Scala/JVM Lightning options.
allowed-tools: Read, Grep, Glob
---

# Eclair (ACINQ)

Eclair is ACINQ's Lightning implementation. Scala-based, runs on JVM,
designed primarily as a **routing/payment infrastructure** node rather
than personal wallet.

## Versions and upgrade path

Release line as of September 2026 (dates from the ACINQ/eclair GitHub
releases page):

| Version | Released | Notes |
|---------|----------|-------|
| v0.14.3 | 2026-09-14 | Security hardening (most fixes from project Loupe); adds `on-chain-fees.max-funding-feerate`. |
| v0.14.2 | 2026-08-26 | Gossip-query and pre-auth connection rate limits; `tor.auth` defaults to `safecookie`; adds `channel.max-funding-satoshis`. |
| v0.14.1 | 2026-07-29 | Raises the Bitcoin Core floor to 31.x; disables the BOLT 12 blinded-path fee discount. |
| v0.14.0 | 2026-05-21 | Final splicing / taproot channels / zero-fee commitments; drops non-anchor channels. |
| v0.13.1 | 2025-10-27 | Last release supporting channels without anchor outputs. |

- **Bitcoin Core floor**: v0.14.0 raised the dependency to Core 30.x to
  get v3/TRUC transactions and ephemeral dust; v0.14.1 raised it again
  to 31.x. The v0.14.3 README states "Eclair requires Bitcoin Core 31
  or higher". The node must still be synchronized, wallet-enabled,
  non-pruning, tx-indexing and ZMQ-enabled.
- **Java**: Eclair targets Java 21 (Adoptium OpenJDK 21) as of v0.14.3.
- **Non-anchor channels are gone** in v0.14.0. Legacy channels must be
  closed *before* upgrading — v0.13.1 is the last release that can
  operate them. List them while still on v0.13.1 with
  `eclair-cli channels` and select commitments whose
  `commitmentFormat` is `legacy`, then `close` (or `forceclose` if the
  peer is offline).
- **Channel splicing, taproot channels (unannounced) and zero-fee
  commitments** shipped their final form in v0.14.0; zero-fee
  commitments remain flagged experimental there.
- **Experimental peer scoring** was added in v0.14.0 to optimize
  routing. Off by default (`eclair.peer-scoring.enabled = false`); it
  first only recommends liquidity and relay-fee actions, and must be
  explicitly configured before it acts on its own.
- Upgrades within the v0.14.x line need no channel closes: stop,
  upgrade, restart.

## Components

- `eclair-node` — main daemon.
- `eclair-cli` — CLI tool wrapping HTTP API.
- HTTP/JSON-RPC API (no gRPC by default).
- Phoenix (mobile wallet) talks to ACINQ's Eclair backend via custom
  protocol.

## Configuration

`eclair.conf`:
```hocon
eclair {
  chain = "mainnet"
  bitcoind {
    host = "127.0.0.1"
    rpcport = 8332
    rpcuser = "..."
    rpcpassword = "..."
    zmqblock = "tcp://127.0.0.1:28332"
    zmqtx = "tcp://127.0.0.1:28333"
  }
  api {
    enabled = true
    port = 8080
    binding-ip = "127.0.0.1"
    password = "..."
  }
  node-alias = "eclair-node"
  channel {
    min-public-funding-satoshis = 100000
    min-private-funding-satoshis = 100000
    // 50 BTC; added in v0.14.2, channels above this are rejected
    max-funding-satoshis = 5000000000
  }
  on-chain-fees {
    feerate-tolerance.ratio-low = 0.5
    feerate-tolerance.ratio-high = 10.0
    // sat/byte cap on funding and splice feerates; added in v0.14.3
    max-funding-feerate = 50
  }
  router.sync {
    // per-peer gossip-query limits added in v0.14.2
    max-queries-per-second = 5
    max-queries-per-sync = 2000
  }
}
```

HOCON syntax (superset of JSON).

## API

HTTP basic auth with single password (set in conf). Calls:
```bash
curl -u :password -X POST http://localhost:8080/getinfo
curl -u :password -d "uri=03abc...@host:9735" \
  http://localhost:8080/connect
curl -u :password -d "nodeId=03abc..." -d "fundingSatoshis=1000000" \
  http://localhost:8080/open
curl -u :password -d "invoice=lnbc..." \
  http://localhost:8080/payinvoice
```

## Plugin architecture

Eclair plugins are JVM JAR files dropped into the `plugins/` directory.
Implement `Plugin` interface in Scala/Java. Hooks into:
- Channel events.
- Payment events.
- Routing decisions.

## Watchtower

Eclair has **no watchtower**, client or server. As of September 2026
there is no watchtower code in `ACINQ/eclair` (checked at tag v0.14.3)
and no `eclair.conf` setting for one — breach protection depends on the
node itself being online to see a revoked commitment and publish the
penalty transaction.

- Penalty material lives in the node's own database. Eclair keeps
  per-HTLC revocation info for the lifetime of each channel and prunes
  it in batches once a close or splice confirms
  (`eclair.db.revoked-htlc-info-cleaner`).
- `eclair.blockchain-watchdog` is **not** a watchtower. It cross-checks
  the local chain tip against external header sources
  (`bitcoinheaders.net`, `blockcypher.com`, `blockstream.info`,
  `mempool.space` by default) and warns when the node falls behind
  (`missing-blocks-threshold = 7`). It detects eclipse/desync, not
  channel breaches.
- Budget for downtime accordingly:
  `eclair.channel.unhandled-exception-strategy` defaults to
  `local-close`, and `reference.conf` explicitly warns that an
  unmonitored node gives peers a window to publish a revoked
  commitment.

See [watchtowers/SKILL.md](../watchtowers/SKILL.md) for the third-party
options.

## Implementation strengths

- **Liquidity advertisement**: Eclair pioneered "liquidity ads" for
  selling channel inbound to peers.
- **PathFinding**: variant of Dijkstra with sophisticated probability
  tracking.
- **Backend / server-grade**: designed for high-throughput routing
  nodes.
- **Phoenix backend**: ACINQ's hosted infrastructure for Phoenix users.

## Phoenix integration

Phoenix mobile wallet uses a hybrid model:
- Mobile holds keys (self-custodial).
- ACINQ-hosted Eclair server is "trusted intermediary" for
  channel-on-pay and routing.
- "Splice-on-demand" — Phoenix can request capacity changes.

## Memory / resource

JVM-based: ~500 MB - 1 GB RAM typical. Heavier than LND/CLN/LDK but
not unreasonable for a backend.

## Common issues

- JVM tuning: heap too small → OOM under load.
- HTTP API password leak via process listing — use env var or file
  reference instead.
- Backup: SQLite database in `~/.eclair/eclair.sqlite.db`. Standard
  warnings about not restoring old DB.
- Plugin compatibility breaks across Eclair versions; verify before
  upgrading.
- Remote `bitcoind`: since v0.14.2 ACINQ documents that `bitcoind` must
  run on the same machine as Eclair, or behind a tunnel providing both
  encryption and authentication. A plain RPC connection over the
  network is treated as a broken setup.
- Tor: `eclair.tor.auth` defaults to `safecookie` from v0.14.2 onward,
  and password auth is rejected when `eclair.tor.host` is not a local
  address (v0.14.3 re-allows it on private networks). The onion private
  key is sent to the control port at every startup, so a remote control
  port leaks it regardless of auth method.
- Upgrading past v0.13.1 with non-anchor channels still open leaves no
  code path to operate them — close them first (see *Versions and
  upgrade path*).

## See also

- [bolts/SKILL.md](../bolts/SKILL.md)
- [channels/SKILL.md](../channels/SKILL.md)
- [consumer-wallets/SKILL.md](../consumer-wallets/SKILL.md)

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.