BOLTs (Basis of Lightning Technology) are the interoperability specs for Lightning. LND, Core Lightning, and LDK aim to speak the same protocol so heterogeneous nodes can route.
Complete Step 1 // Required reading in the study plan above, then continue here.
Step 2 — Core idea: shared plugs, different products
Without shared specs, every implementation would be an island. Builders reading BOLTs can debug wire mismatches and evaluate new features (offers, splicing) before they are universal.
Analogy: BOLTs are the electrical code for Lightning. Different manufacturers (LND/CLN/LDK) ship distinct products, but plugs must still fit.
You do not need to read these cover-to-cover now — each gets a dedicated lesson later:
| BOLT | Focus | Later lesson |
|---|---|---|
| 2 | Channel management / HTLCs | Channels & HTLCs |
| 3 | Transactions | Commitment Transactions |
| 4 | Onion routing | Onion Routing |
| 7 | Gossip | Routing & Pathfinding |
| 11 | Invoices | BOLT11 Invoices |
| 12 | Offers (evolving) | BOLT12 Offers |
Loading diagram…
Done when: You can name LND, CLN, and LDK as implementations that target the same BOLTs.
Step 3 — Map three BOLTs (lab)
Fill a three-row map from the table (or BOLTs intro). Optional: note one open bolts PR title — feature or clarification?
Common mistakes
- Assuming a feature in one implementation is already a ratified BOLT everywhere
- Treating blog posts as authoritative over the spec text
- Ignoring feature bits / negotiations between peers
Done when: Lab evidence (BOLT map + authority sentence + source link) is complete.
Next lesson
Invoices — the BOLT11 payment requests wallets actually scan.