BOLT (Basis of Lightning Technology)

What Is a BOLT?

BOLT stands for Basis of Lightning Technology. The BOLTs are the formal specification documents that define the Lightning Network protocol: a layer-2 system for off-chain Bitcoin transfers using mutual cooperation, with on-chain transactions as the enforcement mechanism when cooperation fails. Each BOLT covers a specific aspect of the protocol, from how nodes establish encrypted connections to how payments are routed across multiple hops.

The specifications are maintained in an open-source repository at github.com/lightning/bolts (originally named lightning-rfc). The process began at a 2016 developer meeting in Milan where Lightning implementers agreed on a shared specification framework. Since then, the BOLTs have served as the interoperability contract between competing implementations: if two nodes follow the same BOLT, they can open channels, route payments, and close channels together regardless of which software they run.

The Complete BOLT Index

The Lightning specification consists of 12 documents. Each covers a distinct layer of the protocol stack:

BOLT 0: Introduction and Index

The overview document. Defines core terminology (channel, HTLC, funding transaction, commitment transaction) and provides the index to all other BOLTs. This is the starting point for anyone reading the specification.

BOLT 1: Base Protocol

Defines the foundational messaging format for node-to-node communication. Covers message framing (a 2-byte type field followed by a variable-length payload), Type-Length-Value (TLV) encoding for backward-compatible extensibility, and the "it's OK to be odd" rule: odd-numbered feature types may be ignored by peers, while even-numbered ones must be supported. Also specifies init messages, error handling, and ping/pong keepalives.

BOLT 2: Peer Protocol for Channel Management

One of the largest specifications. Covers the full channel lifecycle across three stages: establishment (opening a channel, negotiating parameters), normal operation (sending and receiving HTLCs, updating commitment transactions), and closing (both cooperative and unilateral). This is where the rules for adding, removing, and settling payments within a channel are defined.

BOLT 3: Bitcoin Transaction and Script Formats

Specifies the exact structure of on-chain transactions used by Lightning: commitment transactions that encode channel state, HTLC output scripts, and the funding transaction that creates a channel via a 2-of-2 multisig. Also defines key derivation requirements for the cryptographic keys used in these transactions.

BOLT 4: Onion Routing Protocol

Describes the Sphinx-based onion routing construction that makes Lightning payments private. Each hop in a payment route can only see the previous and next hop, not the full path. The specification covers ECDH-derived shared secrets, ephemeral key blinding, per-hop payloads, HMAC integrity verification, and encrypted error reporting along the reverse path. It also defines route blinding for receiver privacy.

BOLT 5: On-chain Transaction Handling

Provides recommendations for handling on-chain transactions when channels close unexpectedly. Covers unilateral close scenarios, resolution of expired HTLCs, fee bumping strategies, and dispute resolution when participants disagree or fail to respond. This is the guide for what happens when cooperation breaks down and the blockchain becomes the arbiter.

BOLT 7: P2P Node and Channel Discovery

Defines the gossip protocol for network topology discovery. Specifies three key message types: node_announcement (advertising a node's existence and features), channel_announcement (proving a channel exists with on-chain evidence), and channel_update (broadcasting routing parameters like fees and capacity). This is how every node builds its map of the network for pathfinding.

BOLT 8: Encrypted and Authenticated Transport

Specifies how all communications between Lightning nodes are encrypted. It implements the Noise Protocol Framework (specifically Noise_XK_secp256k1_ChaChaPoly_SHA256) using a three-act handshake for authenticated key exchange with secp256k1 keys, ChaCha20-Poly1305 encryption, and SHA-256 hashing. Encryption keys rotate every 1,000 messages for forward secrecy.

BOLT 9: Assigned Feature Flags

The central registry for Lightning protocol capabilities. Uses a bitmask system where even bits indicate a required feature and odd bits indicate an optional one. When two nodes connect, they exchange feature flags to determine which protocol features they share. This mechanism allows the protocol to evolve without breaking backward compatibility.

BOLT 10: DNS Bootstrap

Specifies how new nodes discover the network for the first time using DNS seeds. When a fresh Lightning node starts up, it queries DNS seed records to find initial peers to connect to, similar to how Bitcoin nodes bootstrap their peer connections.

BOLT 11: Invoice Protocol

Defines the encoding format for Lightning invoices. Uses bech32 encoding for QR code compatibility. The human-readable part includes a prefix (lnbc for mainnet Bitcoin) and an optional amount with multiplier suffixes. Required fields include payment hash, payment secret, and description. BOLT 11 invoices are single-use: each invoice corresponds to one specific payment.

BOLT 12: Offers

The newest BOLT, officially merged in September 2024: the first new specification added since the original set in 2017. Offers introduce reusable, static payment identifiers that replace the single-use model of BOLT 11. Key features include reusable payment requests (static QR codes that work for multiple payments), receiver privacy via route blinding, recurring and subscription payments, and dynamic pricing with amounts denominated in non-Bitcoin currencies.

How the Specification Process Works

The BOLT process follows a collaborative, implementation-driven approach that prioritizes working code over theoretical proposals:

1. Community discussion: proposals are discussed on the Lightning development mailing list and the Delving Bitcoin forum to gather feedback from implementers and researchers
2. Implementation and testing: developers submit pull requests to implementation codebases to test the proposed changes in practice
3. Interoperability verification: a proposal becomes an official BOLT only after at least two independent implementations have successfully tested interoperability as peers on the Lightning Network

This two-implementation requirement is the critical bar for adoption. It ensures that specifications are not just theoretically sound but practically workable across different codebases.

For experimental or application-level features that do not need to be universal, there is a parallel process called bLIPs (Bitcoin Lightning Improvement Proposals), hosted at github.com/lightning/blips. bLIPs are opt-in specifications: if a feature is intended to become universal, it must go through the full BOLT process.

BOLTs vs. BIPs

BOLTs are often compared to Bitcoin Improvement Proposals (BIPs), the specification process for Bitcoin's base layer. While both serve as technical standards, they differ in important ways:

BOLTs build on BIP-defined primitives. For example, Lightning channels rely on SegWit (BIP 141), BOLT 11 invoices use bech32 encoding (BIP 173), and newer channel types leverage Taproot (BIPs 340-342). The two specification tracks are complementary: BIPs define what the base layer can do, and BOLTs define how Lightning uses it.

Major Implementations

Four major implementations follow the BOLT specifications, each maintained by a different organization:

All four teams actively participate in the specification process, with changes requiring cross-implementation agreement and interoperability testing. This multi-vendor approach ensures the Lightning Network remains an open protocol rather than a product controlled by a single entity.

Use Cases

Interoperability Across Wallets and Nodes

The primary purpose of BOLTs is enabling interoperability. A payment sent from an LND node can route through Core Lightning and Eclair nodes to reach an LDK-powered mobile wallet: all because every implementation follows the same specification for channel management, onion routing, and invoice encoding.

Developer Integration

Developers building on Lightning reference BOLTs to understand protocol behavior. When integrating BOLT 11 invoices into a payment system, for example, the specification defines exactly how to parse the bech32-encoded string, extract the payment hash and amount, and validate the signature. For more on how invoices and offers compare, see our BOLT 11 vs. BOLT 12 deep dive.

# Example: decoding a BOLT 11 invoice with lncli
lncli decodepayreq lnbc1500n1pj...

# Output includes fields defined by the BOLT 11 spec:
# - payment_hash
# - destination (node public key)
# - num_satoshis
# - timestamp
# - expiry
# - description

Protocol Evolution

The feature flag system in BOLT 9 allows the protocol to evolve gracefully. New capabilities (like anchor outputs, splicing, or offers) can be deployed incrementally: nodes that support them advertise the feature flag, and those that do not simply ignore it. This is how the Lightning Network adds functionality without requiring a hard fork or forcing all nodes to upgrade simultaneously.

Recent Developments

The BOLT specifications continue to evolve as the Lightning Network matures:

• BOLT 12 was merged in September 2024, marking the first new specification added since 2017. Core Lightning enabled offers by default in November 2024, with other implementations following.
• Active work continues on dual-funded channels (collaborative channel creation), splicing (resizing channels without closing), and Taproot-based channels that leverage Schnorr signatures for improved privacy and efficiency.
• The quiescence protocol (feature 34/35) enables safely pausing channel operations during protocol upgrades, allowing nodes to transition between channel types without closing and reopening.

For a broader view of where the Lightning Network is headed, see our research on the state of the Lightning Network.

Why It Matters for Spark

Spark operates as a layer-2 protocol for Bitcoin alongside the Lightning Network. While Spark uses a different architecture (statechains with FROST threshold signatures), both protocols exist in the same ecosystem and benefit from the standardization that BOLTs provide. Lightning interoperability through BOLTs means that Bitcoin layer-2 solutions can complement each other: users can move value between Spark and Lightning through atomic swaps and bridge mechanisms, leveraging the strengths of each protocol.

Risks and Considerations

Specification Complexity

The BOLTs collectively run to hundreds of pages of detailed technical prose. Implementing a compliant Lightning node requires correctly interpreting every edge case across all relevant BOLTs. Small misinterpretations can lead to channel failures, fund loss, or security vulnerabilities. This complexity is one reason why only four major implementations exist despite the protocol being open.

Consensus Among Implementers

The two-implementation interoperability requirement means changes move slowly when implementers disagree. BOLT 12 took over seven years from initial proposal to final merge. While this caution reduces the risk of introducing flawed specifications, it also means the protocol cannot respond quickly to emerging needs.

Backward Compatibility

As the protocol evolves, maintaining backward compatibility becomes increasingly challenging. The feature flag system in BOLT 9 helps, but nodes running older software may not support newer payment types or channel features. Network-wide upgrades (like the transition from legacy channels to simple Taproot channels) require significant coordination across the ecosystem.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.