SignorCrypto note · CRYPTO
PQLN Explained: Post-Quantum Security for Lightning
What the September 2026 research prototype changes across Lightning’s off-chain layers—and what still depends on Bitcoin consensus.
PQLN is an experimental hybrid extension to Bitcoin’s Lightning Network that applies post-quantum cryptography to five off-chain surfaces: gossip, peer transport, invoices, offers and payment onions. The September 2026 research implementation uses NIST’s ML-DSA signatures and ML-KEM key encapsulation in a fork of rust-lightning. It does not change Bitcoin consensus or replace the classical signatures inside channel-funding and commitment transactions. PQLN is therefore a research prototype for part of Lightning’s security model—not a post-quantum upgrade for Bitcoin as a whole.
What PQLN is—and when it appeared
Researchers Ahmet Kurt and co-authors submitted the PQLN paper to arXiv on 12 September 2026. Kurt presented the design in a public Bitcoin protocol discussion on 16 September. The paper describes a hybrid design: existing elliptic-curve cryptography remains alongside post-quantum mechanisms, so the system does not have to bet on only one family of algorithms.
The distinction between the two named algorithms matters. ML-DSA creates digital signatures used to authenticate messages; ML-KEM establishes shared secrets that can be used to protect communications. NIST standardized them as FIPS 204 and FIPS 203 in August 2024. NIST says both are believed secure against adversaries with a large-scale quantum computer; that is a security assessment, not a guarantee that any implementation or protocol integration is flawless.
The PQLN code is an experimental rust-lightning fork with a post-quantum feature. The authors describe it as a prototype, not an activated Bitcoin or Lightning standard. They say BOLT assignments for message types and feature bits, and rigorous interoperability testing against Core Lightning, LND and Eclair, remain future work.
Which Lightning layers the proposal changes
PQLN targets the protocol surfaces that nodes use away from Bitcoin’s base-layer consensus:
| Lightning surface | Proposed change | Why it matters |
|---|---|---|
| Gossip (BOLT 7) | Nodes publish post-quantum identity keys and signatures; peers pin keys on first use. | Helps authenticate node announcements, but trust-on-first-use does not protect peers that first meet only after a quantum-capable attacker appears. |
| Peer transport (BOLT 8) | A hybrid Noise handshake combines classical key agreement with ML-KEM. | Protects the peer connection against future decryption of recorded traffic while retaining a classical component. The prototype uses a separate port rather than negotiating the change in-band. |
| Invoices (BOLT 11) | ML-DSA signatures are split across invoice fields to fit existing field limits. | A post-quantum signature is much larger than the current signature format. |
| Offers (BOLT 12) | Each offer commits a fresh ML-DSA key that the payer checks against the returned invoice. | Provides an authentication anchor when the offer’s recipient is not discoverable through public gossip. |
| Payment onions (BOLT 4) | Hybrid key-establishment data travels beside the existing onion packet. | The design avoids putting a large ML-KEM ciphertext inside the fixed-size onion itself. |
These are design choices, not five independent guarantees. The authors’ proposal leaves some channel-announcement signatures classical because they depend on Bitcoin keys. It also relies on key pinning: first contact is a weak point if an attacker can substitute keys before two nodes have established trust.
What PQLN does not protect
PQLN changes Lightning’s off-chain messages and transport; it does not replace the signatures used by Bitcoin consensus. Funding, commitment and penalty transactions still depend on the base layer’s existing cryptography. Those protections require a separate consensus-level change. A future post-quantum Bitcoin output would not automatically secure every Lightning message exchanged off-chain, just as this Lightning prototype cannot make Bitcoin’s on-chain signatures post-quantum.
The distinction also affects what “interoperable” means. The authors report 12 scenarios mixing their prototype with unmodified nodes. They say payments completed without getting stuck, but traffic could fall back to classical protection when a non-PQ node was on the route. A require-PQ option instead fails closed if the route cannot maintain the required protection. That is useful prototype evidence, not proof of network-wide quantum security or interoperability among the major Lightning implementations.
The measured trade-off is bandwidth, not signing time
In the authors’ evaluation, ML-DSA signing took at most 0.33 milliseconds. Under an emulated connection with 50 ms round-trip latency and 10 Mbit/s bandwidth, they report an added 19–53 ms per hop, largely from transmitting the larger key-establishment data rather than performing the cryptographic operations.
The bigger systems cost is gossip. The authors estimate about ten times as much gossip download and roughly nine times the storage for their ML-DSA design. Using a network of 33,000 public channels as their scenario, they estimate an initial download of about 270 MB rather than 26 MB. These are results and estimates from the authors’ prototype and test setup, not independent measurements of a deployed network. They report that using the smaller FN-DSA signature design would reduce gossip growth, but that alternative is not the basis for the main measurements summarized here.
What to watch next
The most useful next evidence is not a headline claim that Lightning is “quantum-proof.” It is whether the proposal resolves first-contact key authentication, receives the necessary BOLT assignments, and can be tested across independent implementations without downgrading to classical protection. Operators should also watch the size limits that affect gossip relay and the storage and bandwidth burden for nodes joining the network.
The paper frames a future cryptographically relevant quantum computer as a threat model; it does not establish when such a machine will exist. The practical point is narrower: protocol designers can investigate post-quantum protection for off-chain traffic separately from consensus upgrades, while being explicit about the surfaces left uncovered.
Frequently asked questions
Does PQLN make Bitcoin quantum-resistant?
No. PQLN focuses on selected Lightning off-chain surfaces. Bitcoin’s on-chain signature rules and the cryptography in channel transactions are outside its scope and require separate work.
Is PQLN a Lightning standard or ready for production?
The material available is a research paper, a public design discussion and an experimental rust-lightning implementation. The authors list BOLT assignments and cross-implementation testing as future work, so the prototype should not be described as a deployed or approved standard.
Which post-quantum algorithms does PQLN use?
The design uses ML-DSA for signatures and ML-KEM for key establishment, in a hybrid system that also retains classical cryptography. NIST describes the relevant standards in FIPS 204 and FIPS 203.
Sources
- PQLN: Post-Quantum Security for the Bitcoin Lightning Network’s Off-Chain Surfaces, arXiv, submitted 12 September 2026.
- PQLN design discussion, Delving Bitcoin, 16 September 2026.
- PQLN rust-lightning implementation, source repository.
- Bitcoin Optech Newsletter #424, 25 September 2026.
- NIST FIPS 204: ML-DSA and FIPS 203: ML-KEM, published 13 August 2024.
If you are evaluating a security-sensitive payment or protocol architecture, contact SignorCrypto to discuss technical architecture, integration and implementation.