A Point Time Locked Contract combines a point lock with a timed refund path: completing an adaptor signature reveals the corresponding scalar, which the previous participant uses to complete its own signature, while funds can be recovered after the timelock expires; it is a protocol building block, not a standard Lightning payment type today.
An HTLC makes the success branch depend on knowing the preimage of a shared hash; a PTLC instead uses a point T = t·G and a signature adaptor that can be completed only with knowledge of scalar t. The timed branch remains: if settlement fails, the sending side can recover the funds after the timeout. [1]
The receiver chooses a secret scalar and publishes the corresponding point. Each pair of neighboring nodes prepares incomplete signatures bound to its point lock; when the receiver completes the final signature, the difference between the adaptor and valid signature reveals the scalar and lets settlement propagate backward along the route. [1]
The sender can add different random scalars for individual hops, and nodes progressively subtract their points. Two colluding routing nodes then do not see the same payment hash as they do with a conventional HTLC; correlation through amount, timing, expiry or topology still remains. [4]
BIP 340 gives Schnorr signatures a linear equation that makes signature adaptors more natural to compose than with ECDSA. With an aggregated key, a successful on-chain spend can resemble an ordinary signature, but actual space savings depend on the channel construction, multisignature protocol and emergency path. [2]
Security depends on more than the point and timelock. An implementation must verify the adaptor, bind the signature correctly to the message and key, protect nonces, extract the scalar safely, preserve the refund path and handle an interrupted peer; a mistake can leak a key or lose funds. [1]
The current base BOLT #2 still specifies update_add_htlc, update_fulfill_htlc and htlc_signature. A PTLC therefore cannot be described as an interoperable feature of ordinary Lightning Network nodes merely because Taproot and BIP 340 are active on Bitcoin; it needs agreed messages, channel states and compatible implementations. [3]
Developer discussion from 2025 points to missing standardized, mature tooling for signature adaptors with MuSig2 and for standalone Schnorr adaptors in common libraries. PTLC is a technically developed proposal, but the public state of tooling and specifications still prevents claims of broad deployment. [5]
PTLC can improve routed-payment decorrelation, proof of payment, atomic multipath payments and some swaps. It does not by itself solve channel availability, liquidity management, state loss, malicious timing or complete anonymity; its benefit must be evaluated together with onion routing and channel design. [4]
For the clearest picture, read this entry together with HTLC, Schnorr Signature, Lightning Network, Taproot, Payment Channel, Lightning Routing. The reverse links also lead from Trampoline Routing.
01Does the ordinary Lightning Network use PTLCs instead of HTLCs today?+
Not as a common interoperable baseline. Current BOLT specifications still define HTLC messages and signatures. PTLC needs additional cryptographic tooling, protocol messages, state transitions and implementation agreement; active Taproot alone did not perform that migration.