Point Time-Locked Contract (PTLC)

A Point Time-Locked Contract (PTLC) is a conditional Lightning Network payment that locks funds to a point on Bitcoin's elliptic curve rather than to the preimage of a hash. It is the privacy-improving successor to the Hashed Time-Locked Contract (HTLC). Like an HTLC, a PTLC still combines a secret condition with a timeout that refunds the sender if the payment fails, but it swaps the hash lock for a cryptographic point that is unlocked by a corresponding signature — a change that looks small and turns out to matter enormously for privacy.

The upgrade sounds arcane on paper, but the problem it fixes is deeply intuitive. Under the older scheme, every hop of a multi-hop Lightning payment is stamped with the same secret hash, rather like a parcel routed through several sorting depots that all bear one identical tracking number. Anyone positioned along the route — or watching the chain, if the payment is ever forced to settle on-chain — can simply match those identical stamps and stitch the separate hops back into a single, traceable journey. PTLCs give each hop its own unlinkable stamp instead, so the depots can still do their forwarding job while no outside observer can reassemble the route from the outside. It is a change deep in the plumbing that pays off directly, and visibly, as privacy for both the sender and the receiver.

Adaptor signatures do the work

Each hop along a route prepares an adaptor signature: a half-finished signature that can only be completed once the payment's secret scalar is revealed. When the final recipient claims the payment, that secret propagates back along the route, and at each hop it lets the intermediary complete its own signature and pull the funds forward. Because every hop is built around a different point — the secret is tweaked at each step rather than shared verbatim — the contracts along a route no longer carry a common identifier that ties them together into a single traceable payment.

The privacy and fungibility gain

This is the crux. With HTLCs, every hop on a route shares the same payment hash, so routing nodes and chain observers can correlate the hops and, in principle, trace a payment end to end simply by matching that shared value. PTLCs eliminate that fingerprint: each hop looks unrelated to the others, and if a PTLC is ever forced on-chain it settles as an ordinary single-signature spend, indistinguishable from any other Taproot payment. That indistinguishability is a fungibility win for the whole network, not just a privacy win for one payer — the fewer distinctive footprints Lightning leaves on-chain, the harder any coin is to taint by association with a particular payment.

Beyond privacy: stuck payments

PTLCs also help with problems that have nothing to do with surveillance. Because each hop uses a distinct secret rather than one shared hash, they open the door to cleaner handling of the "stuck payment" and probing issues that affect HTLC routing, and they compose neatly with proof-of-payment schemes where the payer wants cryptographic evidence that a specific invoice was settled. The move from a shared hash to per-hop points is a small structural change with a surprisingly wide set of downstream benefits, which is why it is treated as a foundational upgrade rather than a niche privacy tweak.

Adoption and dependencies

PTLCs became possible only after Schnorr signatures arrived with the Taproot upgrade, since adaptor signatures are a natural construction over Schnorr but awkward at best over the old signature scheme. They build on the same adaptor-signature primitive used in Discreet Log Contracts, and they pair with on-chain safety mechanisms like the anchor output for reliable fee-bumping when a channel must close unilaterally. The main brake on adoption is coordination: every node along a route must support PTLCs for a payment to use them, so the transition from HTLCs is gradual and proceeds hop by hop as implementations ship support. Related research such as SIGHASH_ANYPREVOUT aims to make the surrounding channel machinery simpler still.