Adaptor Signature

What Is an Adaptor Signature?

An adaptor signature (also called a signature adaptor or pre-signature) is a cryptographic primitive that extends digital signature schemes with a conditional completion mechanism. The signer produces a pre-signature that is verifiably bound to an elliptic curve point (the "adaptor point"). This pre-signature is not valid on its own, but anyone who knows the discrete logarithm of the adaptor point (the secret) can "adapt" it into a fully valid signature. Crucially, anyone who has seen both the pre-signature and the completed signature can extract that secret.

The concept was introduced by Andrew Poelstra of Blockstream Research in 2017 under the umbrella of "scriptless scripts": a paradigm where smart contract logic is enforced entirely through cryptographic signature operations rather than on-chain script code. Originally developed for Mimblewimble (a privacy-focused protocol with no scripting language), adaptor signatures proved equally powerful for Bitcoin, especially after the Taproot soft fork activated BIP-340 Schnorr signatures in November 2021.

The formal cryptographic treatment of adaptor signatures was established by Aumayr et al. at Asiacrypt 2021 and further strengthened by Gerhart et al. at Eurocrypt 2024, who refined the security definitions for unforgeability, pre-signature adaptability, and witness extractability.

How It Works

Adaptor signatures exploit the linearity of Schnorr signatures. In a standard Schnorr signature on the secp256k1 curve, a signer with private key x and public key X = xG produces a signature (R, s) where s = k + H(R || X || m) * x. Because this equation is purely linear in the scalar values, it can be algebraically offset by a secret value.

The Four Operations

An adaptor signature scheme defines four operations beyond standard signing and verification:

1. PreSign: the signer creates a pre-signature bound to an adaptor point T without knowing the corresponding secret t
2. PreVerify: anyone can verify the pre-signature is correctly bound to T and will become valid once adapted
3. Adapt: the holder of secret t converts the pre-signature into a valid standard signature
4. Extract: given both the pre-signature and completed signature, anyone can recover the secret t

Step-by-Step Construction

The following describes the Schnorr-based construction used with BIP-340:

Setup:
  G  = generator point of secp256k1
  x  = signer's private key
  X  = xG (signer's public key)
  t  = adaptor secret (unknown to signer)
  T  = tG (adaptor point, known publicly)
  k  = random nonce
  m  = message to sign

PreSign (signer creates pre-signature):
  R_hat = kG              // raw nonce point
  R     = R_hat + T       // adapted nonce (offset by adaptor point)
  c     = H(R || X || m)  // challenge hash using adapted nonce
  s_hat = k + c * x       // pre-signature scalar
  Output: (R_hat, s_hat)

PreVerify (anyone checks validity):
  R = R_hat + T
  c = H(R || X || m)
  Check: s_hat * G == R_hat + c * X

Adapt (secret holder completes signature):
  s = s_hat + t
  Valid signature: (R, s) where R = R_hat + T

Extract (recover secret from both signatures):
  t = s - s_hat

The adapted signature (R, s) is a standard Schnorr signature that passes normal BIP-340 verification: sG = (s_hat + t)G = R_hat + cX + tG = R + cX. To any blockchain observer, it looks identical to an ordinary Taproot payment.

Why Schnorr Is Essential

The construction works because Schnorr's signature equation is linear: adding a scalar offset to the pre-signature scalar produces a valid signature with a correspondingly offset nonce point. ECDSA's equation (s = k⁻¹(z + r*x)) includes a non-linear inverse term, making adaptor signatures significantly more complex. While ECDSA adaptor signatures are possible (as shown by Lloyd Fournier in 2019), they require two-party computation protocols and additional security assumptions. This is one reason Bitcoin's adoption of BIP-340 Schnorr signatures was so significant for enabling next-generation protocols.

Scriptless Scripts

Adaptor signatures are the core building block of scriptless scripts: a paradigm where protocol conditions are enforced entirely through signature math rather than on-chain script code. The blockchain serves only as a verification engine for standard signatures, not as a computation engine.

The key insight is that if a protocol's conditions can be encoded as "knowledge of a secret scalar," adaptor signatures enforce those conditions without any on-chain script. This provides three advantages over script-based approaches:

• Privacy: no contract details appear on-chain, and transactions are indistinguishable from ordinary single-key payments
• Efficiency: a standard 64-byte Schnorr signature replaces what would otherwise require hundreds of bytes of script and witness data
• Universality: the approach works on any blockchain supporting Schnorr signatures, even those without a scripting language

Use Cases

Atomic Swaps

Adaptor signatures enable trustless cross-chain atomic swaps without hash locks. The protocol works as follows:

1. Alice creates a pre-signature on her Bitcoin transaction to Bob, bound to adaptor point T = tG (she knows secret t)
2. Bob verifies the pre-signature and creates his own transaction on a second chain, also bound to T
3. Alice claims Bob's funds by completing her signature, which reveals t on-chain
4. Bob extracts t from Alice's published signature and completes his own signature to claim Alice's Bitcoin

Unlike HTLC-based swaps where the same hash appears on both chains (making transactions linkable), adaptor signature swaps leave no common on-chain identifier between the two transactions.

PTLCs: Next-Generation Lightning

Point Time-Locked Contracts (PTLCs) are the adaptor signature-based replacement for HTLCs in the Lightning Network. Current HTLCs share the same hash preimage across every hop in a payment route, creating a critical privacy weakness: any node controlling two points on a route can correlate payments by observing the shared hash.

PTLCs solve this through payment decorrelation. Each hop uses a unique adaptor point created by adding random blinding factors: T_i = T + r_i * G. When the final recipient completes their adaptor signature, each intermediary can extract their specific secret and complete their own signature, propagating settlement back along the route. No two hops share any common value. For a deeper analysis, see the research article on PTLCs as the next evolution of Lightning.

Discreet Log Contracts

Discreet Log Contracts (DLCs), proposed by Thaddeus Dryja in 2017, use adaptor signatures for private oracle-based contracts. Two parties exchange adaptor signatures on conditional execution transactions, each bound to a possible oracle attestation. When the oracle publishes its signature on the outcome, it reveals the secret needed to adapt exactly one transaction into a valid signature. The oracle never learns about the contract or its participants. For technical details, see the deep dive on Discreet Log Contracts.

Multi-Signature Integration

Adaptor signatures compose naturally with multi-party Schnorr signing schemes like MuSig2 and FROST. This means adaptor signature protocols can be used in multisig contexts where the resulting transaction is indistinguishable from a single-key spend. The libsecp256k1 v0.6.0 release in November 2024 added the MuSig2 module with adaptor signature support to Bitcoin's core cryptographic library. For more on how these schemes work together, see the research on MuSig2 multisignatures and FROST threshold signatures.

Adaptor Signatures vs. HTLCs

The following comparison highlights why adaptor signatures represent a significant upgrade over hash-based HTLC approaches:

For a broader view of how these privacy improvements fit into the Lightning landscape, see the research on Lightning Network privacy.

Why It Matters

Adaptor signatures are foundational to the next generation of Bitcoin protocols. By moving conditional logic entirely off-chain and into pure signature math, they enable trustless atomic operations with superior privacy, lower fees, and smaller transaction sizes compared to script-based alternatives.

For Layer 2 protocols built on Bitcoin, adaptor signatures unlock capabilities that were previously impossible or impractical. PTLCs will bring payment decorrelation to Lightning, eliminating one of the network's most significant privacy weaknesses. DLCs enable private financial contracts that settle on Bitcoin without revealing contract terms. Cross-chain atomic swaps become private by default. Protocols like Spark and other Bitcoin Layer 2 solutions benefit from these cryptographic advances as they build scalable, private payment infrastructure on top of Bitcoin's security model.

Risks and Considerations

Implementation Complexity

Adaptor signatures require careful cryptographic implementation. Nonce reuse in pre-signatures is catastrophic, leaking the signer's private key, just as with standard Schnorr signing. Deterministic nonce derivation (RFC 6979) mitigates this risk but must be correctly integrated with the adaptor signature protocol.

Security Model Maturity

While the cryptographic foundations are well-established, the formal security model for adaptor signatures continues to evolve. Gerhart et al. at Eurocrypt 2024 identified gaps in the original Aumayr et al. definitions that could render certain protocols (such as private coin-mixing and oracle-based payments) insecure under the original model. The Blockstream scriptless-scripts repository notes that many presented schemes are ad-hoc constructions without formal security proofs.

Deployment Status

As of 2026, PTLCs remain in the specification phase for major Lightning implementations. Production PTLC support has not yet shipped in LND, Core Lightning, or Eclair, though Taproot channel support (a prerequisite) continues to advance. The gap between cryptographic readiness and production deployment means the full benefits of adaptor signatures in Lightning are still forthcoming.

Cross-Curve Limitations

Adaptor signatures between chains using the same elliptic curve are straightforward. Cross-curve constructions (for example, swapping between Bitcoin's secp256k1 and Monero's Ed25519) require additional cryptographic proofs and more complex protocols, as demonstrated in the Bitcoin-Monero atomic swap research by Joel Gugger in 2020.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.