BOLT Specification

BOLT stands for Basis of Lightning Technology, the set of open specifications that define how Lightning Network implementations interoperate. Maintained collaboratively in a public repository, the BOLTs are the shared rulebook that lets independently written software — LND, Core Lightning, Eclair, LDK, and others — speak the same protocol, open channels with one another, and route payments across a network none of them controls. They are to Lightning what the BIPs are to Bitcoin: not software, but the agreement that makes plural software possible.

What the BOLTs cover

The specifications are numbered and modular, each owning one layer of the problem. BOLT 1 defines the base message format and BOLT 8 the encrypted, authenticated transport every peer connection runs over. BOLT 2 governs the payment channel lifecycle — opening, updating, closing — while BOLT 3 pins down the exact on-chain transaction formats, including the HTLC output scripts that make routed payments enforceable. BOLT 4 specifies the onion routing packet, so each hop learns only its predecessor and successor. BOLT 5 covers on-chain enforcement when a counterparty misbehaves, BOLT 7 the gossip protocol that builds every node's map of the network, BOLT 9 the feature flags, BOLT 10 DNS bootstrap, and BOLT 11 the invoice format every wallet can scan. Newer work such as BOLT12 offers extends the family with reusable, more private payment requests.

Why specifications matter more than code

Lightning has no central operator and no reference implementation with veto power. The BOLTs are what make it a network rather than a collection of incompatible wallets — any two nodes that implement the specs can transact, regardless of who wrote their software, and no company's roadmap defines the protocol — a guarantee no proprietary payment API has ever offered its users. That plurality is a decentralization property in itself: a bug or a bad decision in one implementation cannot take down the network, and users can switch software without leaving the system. The craftsmanship shows in the details, too. These documents encode years of adversarial thinking — every message ordering, timeout, and fee rule exists because someone worked out how it could be exploited otherwise.

Evolution without breakage

The BOLTs grow through a feature-bit system defined in BOLT 9: nodes advertise optional capabilities — anchor outputs, dual funding, splicing — and negotiate at connection time which extensions both sides support. Odd bits mean "optional," even bits mean "required," so new features roll out gradually across the network while old nodes keep working. Changes land through public review, and in practice a feature ships only after interoperability testing between implementations — a proposal typically lives in the wild, deployed experimentally by two or more implementations, before it is merged into the specification proper. Alongside the BOLTs, the community maintains bLIPs (Bitcoin Lightning Improvement Proposals) as a lighter-weight track for optional features that do not need universal adoption, keeping the core specs lean while still documenting extensions. It is slow by design; money protocols earn trust by being boring.

Why a node runner should care

If you self-host a Lightning node, the BOLTs are your bill of rights. They are the reason your BOLT11 invoice is payable from any wallet on earth, the reason you can migrate between implementations, and the reason no vendor can hold your channels hostage to a proprietary protocol. Reading even one BOLT — start with 11, the invoice format — demystifies a surprising amount of what your node does, and the documents are shorter and clearer than their reputation suggests. Open specifications are the quiet infrastructure of sovereignty: the Lightning Network belongs to its users precisely because its rules belong to everyone.