Skip to content
Back to skills

Adaptor Sigs

ASecurity

Adaptor signatures: pre-signature paired with a "secret" such that publishing a valid signature reveals the secret, and vice versa. Foundational for atomic swaps, scriptless scripts, DLCs, Submarine Swaps trustless variants, PTLCs (Point Time-Locked Contracts). USE WHEN: designing atomic swaps, evaluating PTLCs vs HTLCs, building DLCs, understanding scriptless scripts.

  • 31 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 8, 2026
ai-agentsrustreactapisecurity

Works with

  • api

Security analysis

A100/100

Scanned September 22, 2026

npx -y skills add claude-dev-suite/claude-dev-suite --skill adaptor-sigs --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Adaptor Sigs?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Adaptor Sigs
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/claude-dev-suite-adaptor-sigs/badge)](https://www.skillsdirectory.com/skills/claude-dev-suite-adaptor-sigs)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: bitcoin-adaptor-sigs
description: |
  Adaptor signatures: pre-signature paired with a "secret" such that
  publishing a valid signature reveals the secret, and vice versa.
  Foundational for atomic swaps, scriptless scripts, DLCs, Submarine
  Swaps trustless variants, PTLCs (Point Time-Locked Contracts).
  USE WHEN: designing atomic swaps, evaluating PTLCs vs HTLCs,
  building DLCs, understanding scriptless scripts.
allowed-tools: Read, Grep, Glob
---

# Adaptor Signatures

An adaptor signature is a **modification** of a Schnorr signing
protocol: instead of producing a complete signature, the signer
produces a **pre-signature** that is invalid on its own but becomes
valid once **adapted** with a secret value `t`.

Two key properties:
1. **Witness extractability** — given a complete sig and the
   pre-signature, anyone can compute `t`.
2. **Atomicity** — observing one side of a swap reveals the secret
   needed for the other side.

## Schnorr-based adaptor (BIP340)

Standard Schnorr sig:
```
e = challenge(R, P, m)
s = k + e*d   (where R = k*G)
```

Adaptor variant with adaptor point `T = t*G`:
```
s' = k + e*d           ← same as normal s
σ  = (R, s')           ← pre-signature
```

But the verifier checks against `(R + T)`, not `R`. So `σ` alone fails
verification. To complete:
```
s = s' + t mod n
```

Now `(R + T, s)` verifies as a normal Schnorr sig under public key `P`.

## Properties used

- **Pre-sig verify** — anyone can check that `σ` is "valid except for
  T" by checking `s'*G - e*P == R`.
- **Adapt** — with `t`, anyone can compute `s = s' + t`.
- **Extract** — with both `σ` and `s`, compute `t = s - s'`.

## Scriptless atomic swap

Two parties Alice (BTC) and Bob (LTC) want to swap.

```
Alice creates Tx_A (BTC for Bob), with Alice's signature σ_A as adaptor
  with adaptor point T = t*G (t known only to Alice)
  σ_A: pre-sig — Bob CAN'T spend yet (verifier expects sig over R+T, not R)

Bob creates Tx_B (LTC for Alice), with Bob's signature σ_B as adaptor
  with the SAME adaptor point T

Alice publishes Tx_B by adapting σ_B with t (Alice can do this because
  she knows t)
  → publishing reveals s_B = σ_B + t
  → Bob extracts t = s_B - σ_B (he sees Tx_B on chain)

Bob now adapts σ_A with t to spend Tx_A
```

Both txs publish or neither. **No HTLC, no script, no preimage**. Just
two adaptor sigs over the same secret.

## PTLC (Point Time-Locked Contract)

Lightning's HTLC = "Hash Time-Locked Contract" — locks fund release
on revealing a preimage `r` such that `hash(r) = H`.

PTLC = "Point Time-Locked Contract" — locks fund release on revealing
a scalar `t` such that `t*G = T`. Same atomic guarantees, but:
- **Better privacy**: each hop in a routed payment uses a different `T`
  (derived per-hop), defeating cross-hop correlation.
- **Smaller** on chain — no preimage in script, just an adaptor sig.
- **Compatible with Schnorr** — needs Taproot adoption.

PTLC requires LN-spec updates (BOLT-PTLC drafts in flight).

## DLC (Discreet Log Contract) integration

DLC oracles publish nonce commitments. Bettors construct adaptor sigs
that adapt under specific oracle outcomes:

```
Oracle nonces: R_oracle for upcoming event, will publish (s_outcome, R_oracle)
  where s_outcome = k_oracle + e_outcome * d_oracle

Bettor pre-signs CET (Contract Execution Tx) with adaptor point
  T_outcome = R_oracle + (e_outcome * P_oracle)

When oracle publishes s_outcome for the actual outcome:
  bettor extracts t_outcome = s_outcome
  adapts pre-sig → publishes CET
```

## Other applications

- **Submarine swaps** (LN ↔ on-chain) trustless variants.
- **Cross-chain atomic swaps** without HTLC.
- **Coin-mixing** with PTLC for privacy.
- **Threshold escrow** — n-of-m parties can adapt with their share of `t`.

## Implementations

- `secp256k1-zkp` (Blockstream fork) — `ecdsa_adaptor`, plus BIP340
  adaptor support inside `musig` (`musig_adapt` /
  `musig_extract_adaptor`). No standalone Schnorr adaptor module —
  PR #299 unmerged since Oct 2024, no tagged releases (Sept 2026).
- `schnorr_fun` / `ecdsa_fun` (secp256kfun, LLFourn) — pure-Rust
  `adaptor` modules for BIP340 and ECDSA adaptor sigs; `schnorr_fun`
  0.13.0 (May 2026), `ecdsa_fun` 0.12.0 (November 2025).
- `rust-secp256k1-zkp` (BlockstreamResearch; formerly
  ElementsProject, as of September 2026) — Rust bindings to the C
  `secp256k1-zkp` library; crate `secp256k1-zkp` 0.11.0 (July 2024),
  wraps the C `ecdsa_adaptor` API.
- DLC: `rust-dlc` (Crypto Garage / p2pderivatives) — `dlc` crate
  0.8.0 (December 2025), repo last pushed March 2026.
- Some Lightning impls' `PTLC` branches (LDK research, not mainnet).

## Security caveats

- **Choice of `t`** must be uniformly random in [1, n-1].
- **Reuse of adaptor point** across protocols → cross-protocol leak.
- **Atomic timing**: while atomicity is guaranteed, **timing windows**
  matter: refund paths must give honest party time to react.
- **Fair-exchange impossibility** is sidestepped because adaptor sig
  embeds the unforgeable signing operation.

## Common bugs

- Forgetting parity flip when computing `R + T` (Schnorr's even-y
  rule applies to the resulting point).
- Storing `t` in plaintext between adapt and reveal phases.
- Failing to verify pre-signature before relying on it (someone
  could give you a completely random pre-sig that won't adapt).

## See also

- [schnorr/SKILL.md](../schnorr/SKILL.md)
- [dlcs/SKILL.md](../dlcs/SKILL.md)
- [../../privacy/atomic-swaps/SKILL.md](../../privacy/atomic-swaps/SKILL.md)
- [../../lightning/submarine-swaps/SKILL.md](../../lightning/submarine-swaps/SKILL.md)

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.