PTLC (Point Time-Locked Contract)

What Is a PTLC?

A Point Time-Locked Contract (PTLC) is a conditional payment mechanism that uses elliptic curve points and adaptor signatures instead of hash preimages. Like its predecessor the HTLC, a PTLC locks funds that can only be claimed by satisfying a cryptographic condition before a timeout expires. The difference lies in what that condition is: HTLCs require revealing a hash preimage, while PTLCs require completing an adaptor signature tied to a specific elliptic curve point.

This shift from hashes to points may seem like a minor cryptographic swap, but it unlocks a fundamentally different privacy model. With HTLCs, the same payment hash is visible at every hop along a route, creating a correlation fingerprint that any node in the path (or any observer monitoring multiple nodes) can use to link sender and receiver. PTLCs break this linkability by using a different point at each hop, making multi-hop payments indistinguishable from unrelated single-hop transfers.

PTLCs are widely considered the next major upgrade path for Lightning Network routing. The cryptographic foundations are already available on Bitcoin thanks to Taproot, and protocol-level work is underway in multiple Lightning implementations.

How It Works

To understand PTLCs, it helps to first recall how HTLCs work and where they fall short.

The HTLC Baseline

In an HTLC-based Lightning payment, the receiver generates a secret value (preimage) and shares its SHA-256 hash with the sender via an invoice. The sender constructs a chain of HTLCs along the route, each locked to the same hash. When the receiver reveals the preimage to claim the final hop, that same preimage propagates backward through every intermediate node.

The problem: every node along the route sees the identical payment hash. If any two nodes collude (or a single entity controls multiple nodes), they can confirm they are part of the same payment. This is a structural privacy weakness, not an implementation bug.

Adaptor Signatures

PTLCs solve this using adaptor signatures, a cryptographic technique enabled by Schnorr signatures. An adaptor signature is an incomplete signature that can only be completed by someone who knows a specific secret scalar (a private key corresponding to a known public point). The key insight: given a completed adaptor signature and the original incomplete version, anyone can extract the secret scalar.

The construction works as follows:

1. Alice wants to pay Carol through an intermediary, Bob. Carol generates a secret scalar z and shares the corresponding point Z = z * G with Alice (analogous to sharing a payment hash).
2. Alice creates a contract with Bob: "I will pay you X sats if you can produce a valid signature that reveals a secret corresponding to point Z." Alice provides Bob with an adaptor signature locked to Z.
3. Bob creates a similar contract with Carol, but using a tweaked point. Bob chooses a random scalar b and creates a contract locked to Z + b * G. Bob provides Carol with an adaptor signature locked to this tweaked point.
4. Carol knows z and Bob has privately shared b with her (via the onion routing layer), so she can compute z + b and complete the adaptor signature from Bob, claiming her funds.
5. Bob sees the completed signature and extracts z + b. Since Bob knows b, he recovers z and uses it to complete Alice's adaptor signature, claiming his forwarding fee.

Point Decorrelation

The critical privacy gain: Alice's contract with Bob is locked to point Z, while Bob's contract with Carol is locked to Z + b * G. These are two completely different elliptic curve points. An external observer seeing both contracts cannot determine they are part of the same payment. Each hop in the route uses a different locking point, eliminating the correlation vector that plagues HTLCs.

This is sometimes called "payment decorrelation" or "point randomization." It is not merely obscuring the hash: it is mathematically impossible to link hops without knowing the blinding factors.

Pseudocode Example

The following pseudocode illustrates the adaptor signature flow in a simplified two-hop PTLC:

// Receiver (Carol) generates secret
z = random_scalar()
Z = z * G  // public payment point, shared in invoice

// Sender (Alice) -> Bob: adaptor signature locked to Z
adaptor_AB = partial_sign(tx_AB, alice_key, lock_point=Z)

// Bob -> Carol: new lock point with blinding factor
b = random_scalar()
lock_point_BC = Z + b * G
adaptor_BC = partial_sign(tx_BC, bob_key, lock_point=lock_point_BC)

// Carol completes adaptor_BC using (z + b)
sig_BC = complete(adaptor_BC, secret=(z + b))
// Carol claims funds from Bob

// Bob extracts (z + b) from sig_BC and adaptor_BC
extracted = extract_secret(sig_BC, adaptor_BC)  // = z + b
z_recovered = extracted - b

// Bob completes adaptor_AB using z
sig_AB = complete(adaptor_AB, secret=z_recovered)
// Bob claims funds from Alice

HTLC vs. PTLC Comparison

The differences between HTLCs and PTLCs span privacy, security, and implementation complexity:

Use Cases

Private Multi-Hop Payments

The primary use case is upgrading existing Lightning payments. Every Lightning payment that currently uses HTLCs would benefit from PTLC routing. Forwarding nodes would no longer be able to determine whether two HTLCs they process are part of the same payment, closing a major probing and surveillance vector.

Stuckless Payments

PTLCs enable "stuckless payments" where the sender can safely retry a payment through an alternative route without risking double payment. The sender can create multiple PTLC attempts with different blinding factors, and the receiver can only claim one. With HTLCs, retry attempts using the same payment hash risk the receiver claiming multiple payments.

Escrow and Conditional Payments

PTLCs can replicate all hodl invoice functionality while adding privacy. Conditional payments, marketplace escrow, and atomic swaps can all be constructed with adaptor signatures. The additional benefit: these conditional payments are indistinguishable from regular payments on-chain and across routing nodes.

Discreet Log Contracts on Lightning

Adaptor signatures integrate naturally with Discreet Log Contracts (DLCs), which use oracle-attested signature points for contract settlement. PTLCs allow DLC outcomes to be settled directly over Lightning without revealing the contract structure to routing nodes, enabling private and instant oracle-based contracts.

Atomic Multi-Path Payments

Atomic multi-path payments (AMPs) split a payment across multiple routes. With HTLCs, all partial payments share the same hash, allowing observers to link them. PTLCs with per-hop decorrelation make each partial payment path unlinkable, improving the privacy of split payments.

Risks and Considerations

Implementation Complexity

Adaptor signatures are more complex to implement correctly than hash locks. The cryptographic operations require careful handling of nonce generation, point arithmetic, and secret extraction. Bugs in adaptor signature implementations could lead to fund loss or privacy leaks. Lightning implementations need thorough auditing before deploying PTLC support.

Transition Period

The Lightning Network cannot switch from HTLCs to PTLCs overnight. During the transition, routes may contain a mix of HTLC and PTLC hops. At the boundary between a PTLC segment and an HTLC segment, the privacy benefits are partially lost because the HTLC portion still uses a shared hash. Full privacy benefits only materialize when the entire route uses PTLCs.

Channel Upgrade Requirements

PTLCs require Taproot-based channel types. Existing pre-Taproot channels cannot support PTLCs without being closed and reopened as Taproot channels (or upgraded via a splice). This creates friction for adoption, as nodes must actively migrate their channel infrastructure. Protocol proposals like eltoo also interact with PTLC adoption plans.

Specification Maturity

As of early 2026, PTLCs are not yet part of the finalized BOLT specifications. While the cryptographic foundations are well-understood and Taproot is active on Bitcoin, the protocol-level details (routing onion changes, invoice format updates, feature bit allocation) are still under active development. Production deployment timelines remain uncertain.

No Hash-Based Proof of Payment

HTLCs provide a natural proof of payment: the revealed preimage proves the receiver claimed the funds. PTLCs do not produce the same kind of universally verifiable receipt. Alternative proof-of-payment schemes need to be designed and standardized, which adds specification work before PTLCs can fully replace HTLCs in all use cases.

This article is for informational purposes only and does not constitute financial or investment advice.