Core Lightning (CLN)

Core Lightning (CLN), formerly known as c-lightning, is an implementation of a full Lightning Network node maintained by Blockstream under the ElementsProject organization. Written primarily in C, it has run on Bitcoin mainnet since 2018 and emphasizes strict adherence to the Lightning specification (the BOLTs) alongside a small, modular core — a design philosophy best summarized as: the daemon does the protocol, and everything else is a plugin.

The plugin architecture

The defining trait of CLN is that much of its functionality lives in plugins rather than a monolithic binary. The daemon exposes a JSON-RPC interface, and plugins — separate processes speaking a simple protocol over stdin/stdout — can add RPC commands, subscribe to node events, and hook into decisions like whether to accept an incoming payment or channel. Because the interface is language-agnostic, operators extend their node in Python, Rust, Go, or anything else that can read and write JSON. Custom routing logic, bookkeeping and accounting, liquidity automation, alternative backends — all of it lands as plugins, without forking the core software. For self-hosters this is the attraction: a lean, auditable base you shape to your own needs, rather than a large binary whose feature set someone else chose. Several capabilities CLN pioneered — including its early, first-class support for BOLT12 offers, the reusable-payment-code standard — began life in exactly this modular fashion.

Running a CLN node

CLN requires a locally running Bitcoin backend, typically Bitcoin Core, to validate the chain, watch for channel-relevant transactions, and broadcast to the network — your Lightning node is only as sovereign as the chain view beneath it. It supports mainnet, testnet, signet, and regtest, runs comfortably on modest hardware including single-board computers, and is packaged in several sovereignty-focused node distributions, so most home operators meet it preconfigured rather than compiled from source. Operational duties are the usual Lightning ones and deserve respect: a Lightning node holds keys in hot storage and must stay online to watch its channels, so backups (particularly of channel state), monitoring, and a disciplined update habit matter more than they do for an ordinary self-custody cold wallet. Funds you are not actively routing or spending belong on-chain, not in channels.

Choosing an implementation

Backups are different on Lightning

One Lightning-specific discipline catches newcomers: channel funds cannot be restored from a seed phrase alone. Your seed recovers on-chain keys, but channel balances live in a constantly updated state negotiated with each peer — and broadcasting a stale state looks, to the protocol, exactly like an attempt to cheat, exposing the funds to penalty. CLN's data directory and its channel database therefore need continuous, not occasional, backup, and every serious deployment guide treats this as first-class infrastructure. Test the restore path before funding channels heavily; a backup you have never restored is a hypothesis, not a backup.

CLN is one of several specification-compliant node implementations, each with its own language, architecture, and design philosophy — and the existence of multiple independent implementations is itself a health metric for the protocol, for the same reason it is in Bitcoin: a bug in one client is a bad day, not a network event. We describe them neutrally so operators can pick what fits: CLN's pitch is minimalism, spec fidelity, and extensibility; others trade differently. For context on the alternatives, see our entries on LND (Lightning Network Daemon) and Eclair. Whichever you run, the sovereignty math is the same: your own Lightning node, over your own Bitcoin node, means payments that need no one's permission and reveal their details to no custodian.

Compare LN nodes in the sovereign self-hosting catalog.