PTLC
A Point Time Locked Contract (PTLC) is a conditional payment that can be claimed by completing a Schnorr signature adaptor (equivalently, by revealing the discrete logarithm of a curve point), or refunded after a timeout. PTLCs are designed to replace hash time locked contracts (HTLCs) in Lightning Network routing and related atomic-swap style protocols so that hops do not share a single payment hash. As of 2026 they remain a design and implementation effort on top of Taproot-capable channels. They are not a completed BOLT that has replaced HTLCs on the public Lightning network.
An HTLC locks coins to the preimage of a hash. Every hop of a routed Lightning payment typically uses the same hash, which can let observers correlate those hops. A PTLC instead locks to a curve point and unlocks via an adaptor signature. Per-hop blinding can give each intermediary a different point, so adjacent hops need not share a common lock value. On-chain, cooperative settlement can stay off chain as with HTLCs. A force-close under Taproot need not reveal a shared payment hash the way a HASH160 HTLC script can.
Adaptor locks
Taproot and BIP340 made Schnorr adaptor constructions practical on Bitcoin. Lightning still routes with HTLCs because interoperable hops, invoices, and proof-of-payment flows are built around preimages. Mixed HTLC and PTLC paths would be needed during any transition.
An adaptor signature is a Schnorr signature encrypted to a point T. Completing the signature reveals the discrete logarithm of T, which the receiver can reuse as proof across a chain of PTLCs. Onion routing can still hide the destination, but each hop's lock point can be derived so intermediaries cannot match payments by a shared hash. Refund paths keep a timeout similar to HTLCs so stalled payments can be cancelled on chain if needed.
Deployment
Deploying PTLCs on Lightning also needs invoice and proof-of-payment formats that are not built solely around preimages, plus channel commitment layouts that can carry point locks. Research prototypes and wallet experiments exist, but public routing still settles with Hash Time Locked Contracts. Related scriptless constructions include atomic swaps that exchange adaptor signatures instead of hash preimages.
Proof of payment under HTLCs is the preimage. Under PTLCs it is knowledge of a scalar tied to the payment point. Accounting systems and watchtowers that key state by payment hash would need parallel identifiers during a migration. Multi-path payments would likewise need point commitments that still allow partial success and failure across shards.
Adaptor-signature PTLCs assume Schnorr and preferably Taproot channel commitments so force-closes do not leak a reusable hash. Legacy HTLC scripts can remain for peers that lack the feature bits. Until BOLTs define those bits and invoice fields, public pathfinding continues to advertise HTLC-based routes.
Interoperable public routing will lag wallet prototypes until BOLT feature bits, invoice fields, and commitment formats are agreed and widely implemented.