Core Lightning (CLN): A Spec-First Lightning Network Node in C

What Core Lightning is, and who it is actually for

Core Lightning, formerly c-lightning, is an implementation of the Lightning Network protocol written in C and developed by Blockstream. The README describes it as lightweight, customizable and standard compliant, and the repository's own one-line description puts spec compliance and performance first. That ordering matters: this is a node for people who care that their software tracks the BOLT specifications closely and who are willing to run infrastructure to get that.

The audience is narrower than "anyone who wants Lightning". Core Lightning only works on Linux and macOS, and it requires a locally or remotely running bitcoind, version 25.0 or above, fully caught up with the network you intend to use, and relaying transactions with blocksonly=0. If you do not already operate a Bitcoin full node, this project is not the place to start. The README recommends experimenting on testnet (testnet4 or regtest) before mainnet, and the repository ships a regtest helper for exactly that purpose.

The project has been in production use on Bitcoin mainnet since early 2018, according to the README, which ties that date to the launch of the Blockstream Store. That is the strongest maturity signal in the README, and it is a claim about deployment history rather than about code quality.

The daemon, the socket, and the plugin boundary

The architecture is visible in the repository's top-level directories. A set of single-purpose daemons each own one part of the protocol: lightningd is the main process, connectd handles peer connections, channeld runs channel state machines, openingd handles channel opening, closingd handles cooperative close, onchaind handles on-chain resolution, gossipd spreads routing gossip, and hsmd holds signing authority. A wallet/ directory and a db/ directory sit alongside them. This is a process-per-concern design, and it means a failure or a restart in one area does not automatically take the whole node down.

The interface you actually touch is JSON-RPC 2.0 over a Unix Domain socket. The README states that lightning-cli is the tool for reaching it, and that a Python client library lives in contrib/pyln-client. Starting the daemon creates a .lightning/ subdirectory in your home directory; the README points to man -l doc/lightningd.8 for runtime options.

Extensions are plugins, and the repository treats them as a first-class surface: there is a plugin RPC command, a plugins/ directory, and a separate collection of community plugins at github.com/lightningd/plugins. The Cargo workspace lists Rust plugin crates including grpc-plugin, rest-plugin, lsps-plugin, wss-proxy-plugin, bip353-plugin and currencyrate-plugin, which tells you the intended extension path is not only C. If you want to add behaviour without patching the daemon, that boundary is where you work.

Installing Core Lightning and opening your first channel

The README gives three supported installation routes: a pre-compiled binary from the GitHub release page, one of the provided Docker images on Docker Hub, or compiling the source as described in the installation documentation. There is no Homebrew or distro-package path documented in the README itself, so pick one of those three.

Before anything else you need a synced bitcoind. The README's mainnet example starts it as a daemon:

bitcoind -daemon

Wait until it has synchronized with the network. The README warns that walletbroadcast=0 in ~/.bitcoin/bitcoin.conf can cause trouble, and that running against a pruned node may cause issues if not managed carefully. Once bitcoind is ready, start the Lightning daemon against mainnet with debug logging:

lightningd --network=bitcoin --log-level=debug

The README notes this creates a .lightning/ subdirectory in your home directory. For a faster, risk-free loop, the repository ships a regtest script that sets up two local nodes and a start_ln helper:

. contrib/startup_regtest.sh

With a node running, the funding flow starts with an address. lightning-cli newaddr returns one; the README also documents a taproot variant:

lightning-cli newaddr
lightning-cli newaddr p2tr

Deposit funds, then confirm the node sees them with lightning-cli listfunds, which the README says returns an array of on-chain funds. To open a channel you connect to a peer and then fund it:

lightning-cli connect <node_id> <ip> [<port>]
lightning-cli fundchannel <node_id> <amount_in_satoshis>

The README states the funding transaction needs 3 confirmations before the channel is usable and 6 before it is announced to the network. lightning-cli listpeers should show state CHANNELD_NORMAL after 3 confirmations (1 on testnet), and after 6 you can check lightning-cli listchannels for a public field of true. For discovering peers, contrib/bootstrap-node.sh connects you to other nodes on the network.

Where Core Lightning is the wrong tool

The hardest constraint is the bitcoind dependency. Core Lightning does not ship a Bitcoin node, and the README requires version 25.0 or above, fully synced, with transaction relay enabled. If your bitcoind runs with blocksonly=1 you are outside the documented configuration. If you run a pruned node, the README calls pruning partially supported and links to a dedicated section rather than promising it works; that is a real limitation, not a footnote.

Platform support is the second boundary. The README says Core Lightning only works on Linux and macOS. There is no Windows path documented. This is a C project with a Unix domain socket as its primary control interface, and the design assumes a Unix-like host.

There is also an operational cost that the README states plainly: the funding transaction needs 3 confirmations before a channel is usable and 6 before it is announced. Anyone expecting to open a channel and route through it immediately will be waiting. And the wallet is a real wallet: the README devotes a section to encrypting the HD wallet seed and points to it as the way to have "a less reckless experience", which is an admission that the default setup is not the careful one.

Finally, the project is not the right choice if you want a node that manages its own Bitcoin backend. Everything here assumes you already know how to run, sync and monitor bitcoind.

How Core Lightning differs from LND

LND is the obvious alternative, and the difference is architectural rather than cosmetic. Core Lightning is a set of cooperating daemons with a Unix-socket JSON-RPC control plane, and its extension model is plugins that can be written in C or in Rust through the workspace crates. LND is a single Go binary with a gRPC-first API and its own Lightning-specific wallet and chain backend handling.

That shapes day-to-day work. With Core Lightning you script against lightning-cli and JSON-RPC commands such as newaddr, listfunds, connect, fundchannel, invoice, xpay and plugin, each with its own reference page. With LND you would typically write against gRPC. Core Lightning's Python client library in contrib/pyln-client and the pyln-* workspace packages give you a supported scripting path; the pyproject.toml pins dependencies including pyln-client, pyln-proto and pyln-grpc-proto, and there is a cln-grpc crate if you want the gRPC surface anyway.

The practical difference for a spec-focused operator is how much of the protocol is exposed as discrete, documented commands versus hidden behind a higher-level API. Core Lightning leans toward exposing the pieces. That is more to learn and more to wire together, and it is the trade the project makes deliberately.

Maintenance, releases and what the licence field does not tell you

The repository is not archived, and the last push was on 2026-09-23. Releases are frequent and versioned by date: v26.06.8 landed on 2026-09-22, v26.06.7 on 2026-08-28, and v26.06.6 on 2026-07-22. The Makefile names CLN_NEXT_VERSION as v26.09 and CLN_PREV_VERSION as v26.06, and it explicitly notes that the previous release is kept for downgrade testing. If you run Core Lightning, plan for regular upgrades rather than a long-lived pinned version, and read the CHANGELOG.md at the repository root before each one.

Build dependencies are not trivial, which is part of the upgrade cost. The Dockerfile installs build-essential, autoconf, automake, bison, flex, libtool, gettext, jq, plus uv and rustup, and the Cargo workspace declares a minimum Rust version of 1.85.0. The Python side requires Python >=3.10,<4.0 and pins protobuf to 6.32.1 and grpcio-tools and grpcio to 1.75.1 to match CI. Expect to maintain both a C toolchain and a Rust toolchain if you build from source.

The licence is listed as NOASSERTION. That is a metadata state, not a licence grant, and it means you cannot rely on the repository's licence field to tell you the terms. The LICENSE file is at the repository root; read it, and if the terms matter to your organisation, get your own legal review. Nothing here should be read as legal advice.

Editorial conclusion

Adopt Core Lightning if you already run a full bitcoind and want a spec-compliant daemon whose RPC surface is documented command by command, and if you are comfortable on Linux or macOS. Do not adopt it if you need Windows, or if you cannot keep an unpruned, transaction-relaying bitcoind in sync. Before committing funds, verify three things: that your bitcoind is version 25.0 or above with blocksonly=0, that your prune setting is one the documentation supports, and that you have read the HD wallet encryption section, because the README points to it as the way to avoid a reckless setup.

Frequently asked questions

Official sources

1. ElementsProject/lightning on GitHub
2. Issues
3. README
4. Releases