Scriptless Scripts: Doing Smart Contracts Without Bitcoin Script

Bitcoin Script is the language that enforces spending conditions on the blockchain. Every hash time-locked contract, every multisig quorum, every timelock gets written into a script that miners evaluate before accepting a transaction. The system works, but it comes with costs: the script data takes up block space, it reveals the contract logic to every node on the network, and it limits what kinds of contracts Bitcoin can express.

Scriptless scripts flip this model. Instead of encoding contract conditions in Bitcoin Script, they embed the logic directly into the digital signature itself. The blockchain sees only a public key and a signature, indistinguishable from any ordinary payment. The contract enforcement happens in the math of the signature scheme, not in on-chain opcodes. The term was coined by Andrew Poelstra, Director of Research at Blockstream, who first presented the concept at the MIT Bitcoin Expo in March 2017 while working on Mimblewimble.

Why Schnorr Makes This Possible

The key property that enables scriptless scripts is the linearity of Schnorr signatures. In a Schnorr signature, the signer picks a random nonce r, computes a nonce point R = r·G, and produces a signature s = r + e·x, where e is a challenge hash and x is the private key. Because every operation here is addition and multiplication over a finite field, signatures can be added and subtracted algebraically. Two valid Schnorr signatures can be combined into a single signature for the sum of their public keys, and the difference between two signatures reveals the difference in their private components.

This linearity is what makes adaptor signatures, key aggregation, and threshold signing possible. It is also what Bitcoin's previous signature scheme, ECDSA, lacks. In ECDSA, the signature equation includes a multiplicative inverse of the nonce: s = k⁻¹(z + r·x). That inverse destroys the linear relationship. Adding two ECDSA signatures together produces cryptographic nonsense, not a valid combined signature. Researchers have constructed ECDSA-based adaptor signatures with additional cryptographic assumptions, but the constructions are more complex, less efficient, and harder to compose.

Why Taproot matters here: Bitcoin activated BIP-340 (Schnorr signatures) as part of the Taproot soft fork at block 709,632 on November 14, 2021. Before Taproot, Bitcoin only supported ECDSA, making scriptless scripts impractical on mainnet. Taproot's key-path spends produce transactions where the signature and public key are indistinguishable from any other payment, which is exactly the property scriptless scripts exploit.

Adaptor Signatures: The Core Building Block

An adaptor signature is an incomplete signature that can only be completed by someone who knows a specific secret value. Think of it as a locked signature: the math is correct except for one missing piece, and revealing that piece to complete the signature simultaneously reveals the secret to the other party.

How adaptor signatures work

Suppose Alice wants to create a conditional payment to Bob. She picks a secret scalar t (the adaptor secret) and computes the corresponding point T = t·G. She shares T with Bob but keeps t hidden. Alice then constructs an adaptor signature: a value s' that is a valid Schnorr signature tweaked by T. Bob can verify that s' would become a valid signature if he knew t, but he cannot use it to spend funds yet.

When Alice later reveals t (or Bob learns it through another mechanism), Bob computes the complete signature s = s' + t and broadcasts the transaction. Here is the critical part: once the completed signature s appears on-chain, Alice can extract t by computing t = s - s', because she already knows s'. The act of spending reveals the secret.

This two-way information flow is the mechanism that scriptless scripts use to enforce contracts. No hash preimage, no script opcode, no witness data beyond a single signature and public key.

Atomic Swaps Without HTLCs

The canonical example of scriptless scripts in action is the cross-chain atomic swap. Traditional atomic swaps use HTLCs: both parties lock funds behind hash locks on their respective chains, and revealing the preimage on one chain lets the counterparty claim on the other. This works, but it leaves on-chain evidence (the same hash appears on both chains, linking the swap participants) and requires script evaluation on both sides.

Adaptor signature atomic swap step by step

1. Alice and Bob agree on a swap: Alice's BTC for Bob's LTC. Alice generates an adaptor secret t and shares the point T = t·G with Bob.
2. Both parties create transactions on their respective chains. Alice signs an adaptor signature for the BTC transaction (payable to Bob) and sends it to Bob.
3. Bob verifies the adaptor signature is valid relative to T. He then creates an adaptor signature for the LTC transaction (payable to Alice) using the same point T.
4. Alice knows t, so she completes Bob's adaptor signature and broadcasts the LTC claim transaction on-chain.
5. Bob sees the completed signature on the Litecoin chain and extracts t = s - s'. He uses t to complete Alice's adaptor signature and claims the BTC.

The result: both transactions complete atomically (if either party stops, timelocks refund both sides), but the on-chain footprint on each chain is a single key-path spend. No hash appears on either chain. A blockchain observer cannot link the two transactions across chains.

Comparing HTLC vs adaptor signature swaps

Point Time-Locked Contracts: Replacing HTLCs in Lightning

The Lightning Network currently routes payments using HTLCs. Each hop in a multi-hop payment uses the same hash lock: the sender creates a hash, and each routing node forwards the payment conditional on receiving the preimage. This design has a privacy weakness: any node that sees the same hash on two of its channels knows those payments are part of the same route.

Point time-locked contracts (PTLCs) replace the hash lock with an elliptic curve point. Instead of requiring a preimage that hashes to a known value, a PTLC requires knowledge of a discrete logarithm: the scalar corresponding to a public point. Each hop uses a different point (the forwarding node adds a random tweak), so an intermediary node cannot correlate payments across its channels.

How PTLCs improve Lightning privacy

In an HTLC-based route from Alice to Dave through Bob and Carol, all four hops share the same payment hash H(x). Bob and Carol can trivially identify they are on the same route. With PTLCs, each hop uses a different point:

• Alice locks to point P₁ for Bob
• Bob locks to point P₂ = P₁ + T_bob for Carol
• Carol locks to point P₃ = P₂ + T_carol for Dave

Each point is unlinkable to the others. When Dave reveals the adaptor secret for P₃, Carol can derive the secret for P₂ (by subtracting her tweak), and Bob can derive the secret for P₁. The payment settles hop by hop, but no shared identifier links the hops together. This is a direct application of Schnorr linearity: the tweak addition and subtraction only work because Schnorr signatures are algebraically composable.

Adoption status: PTLCs have been technically feasible since the Taproot activation in November 2021, but Lightning implementations are still migrating to Taproot-based channels. LND shipped production simple taproot channels in v0.21 (April 2026), and Eclair followed with v0.14.0 (May 2026), though both implementations exclusively use HTLCs in their initial taproot channel deployments. PTLCs remain in specification and development rather than production use.

Discreet Log Contracts Without Oracle Scripts

Discreet Log Contracts (DLCs), first proposed by Tadge Dryja in 2017, allow two parties to make conditional payments based on an oracle's attestation to a real-world event. In the original design, the oracle signs the outcome, and the winning party uses that signature to construct a valid spending transaction from a jointly funded output.

Scriptless scripts, specifically adaptor signatures, improve DLCs in two ways. First, the oracle does not need to know a contract exists: it simply publishes a signed attestation, and the contract parties use the signature's algebraic properties to settle. Second, the on-chain settlement transaction is a plain key-path spend, revealing nothing about the contract terms, the oracle, or even the fact that a DLC existed.

Lloyd Fournier's contribution

In 2019, Lloyd Fournier formalized adaptor signatures as one-time verifiably encrypted signatures (VES) and demonstrated their application to DLCs. His work showed that adaptor signatures could work with ECDSA (not just Schnorr), broadening DLC deployment before Taproot activation. Post-Taproot, Schnorr-based DLCs are cleaner: the oracle's attestation point maps directly to the adaptor point, and settlement transactions are indistinguishable from regular payments.

Payment Channel Updates and Multi-Hop Locks

Beyond swaps and DLCs, scriptless scripts apply to the internal mechanics of payment channels. Each channel update requires both parties to sign a new commitment transaction. With adaptor signatures, channel updates can embed additional conditions without adding script complexity: a payment can be conditional on a secret being revealed, a timeout expiring, or an external event occurring, all encoded in the signature rather than in on-chain script.

Multi-hop locks extend this to payment routing. In a scriptless multi-hop payment, each forwarding node holds an adaptor signature that can only be completed when the next hop reveals its secret. The settlement cascades back through the route, exactly as in HTLC-based routing, but without any hash lock visible on-chain. If any channel force-closes, the on-chain transaction is a standard P2TR spend.

On-Chain Cost and Privacy Comparison

The practical advantages of scriptless scripts become clear when comparing transaction sizes and privacy properties across approaches. Research on Bitcoin transaction composition shows that script data (input scripts and output scripts combined) can account for more than 50% of total transaction size. Scriptless scripts eliminate this overhead entirely for the contract portion of a transaction.

For a concrete example: a standard HTLC-based atomic swap produces on-chain transactions with P2WSH outputs containing the hash lock script, and the spending transaction includes the preimage and the script in the witness. An adaptor signature swap produces two key-path spends that are the same size as sending Bitcoin to a friend: one public key, one 64-byte Schnorr signature, no script data.

Why Schnorr Enables This and ECDSA Does Not

The distinction is algebraic. Here is the Schnorr signature equation:

s = r + e · x

Where r is the nonce, e is the challenge (a hash of the message and nonce point), and x is the private key. Every operation is linear: addition and scalar multiplication over a finite field. Given two signatures s₁ and s₂ for keys x₁ and x₂, the sum s₁ + s₂ is a valid signature for the key x₁ + x₂. The difference s₁ - s₂ reveals x₁ - x₂ (modulo nonce adjustments).

Now compare the ECDSA signature equation:

s = k⁻¹ · (z + r · x)

The k⁻¹ term (the modular inverse of the nonce) makes the equation non-linear. Adding two ECDSA signatures does not produce a valid signature for the sum of the keys. This non-linearity means that key aggregation, signature aggregation, and adaptor signatures all require complex workarounds when built on ECDSA. Crypto Garage and others have demonstrated ECDSA adaptor signatures, but the constructions require additional interactive rounds and stronger cryptographic assumptions.

BIP-340, authored by Pieter Wuille, Jonas Nick, and Tim Ruffing, brought Schnorr signatures to Bitcoin with the Taproot activation in November 2021. Since then, the full suite of scriptless script constructions has been available on Bitcoin mainnet. Protocols like MuSig2 for multi-party signing and FROST for threshold signing build directly on this linearity.

Threshold Scriptless Scripts with FROST

FROST (Flexible Round-Optimized Schnorr Threshold Signatures), designed by Chelsea Komlo and Ian Goldberg and standardized as RFC 9591 in June 2024, extends Schnorr to t-of-n threshold signing: any t participants from a group of n can produce a valid signature, and the result is indistinguishable from a single-signer Schnorr signature. Because FROST preserves Schnorr's linearity, adaptor signatures compose naturally with threshold signing.

This means a group of signers can collectively create an adaptor signature: the completed signature requires both the threshold quorum and knowledge of the adaptor secret. Applications include threshold-signed atomic swaps (where a custodial group participates in a swap without any single member controlling the funds) and conditional payments in protocols that use threshold key management.

Spark uses FROST for its operator key management, with multiple independent operators collectively holding one side of a 2-of-2 multisig via threshold signing. Because FROST produces standard Schnorr signatures, Spark's architecture is compatible with adaptor signature constructions. This opens a path to scriptless conditional payments on Spark: atomic swaps, conditional transfers, and oracle-based settlements that settle as ordinary-looking transactions without requiring any on-chain script complexity.

Applications Beyond Finance

Scriptless scripts extend to any protocol where one party needs to prove faithful execution of a condition without revealing the condition itself:

• Selling digital signatures: a party can prove they will sign a particular message by constructing an adaptor signature, and the buyer pays only when the real signature is published
• Lottery and gambling protocols: outcomes can be conditioned on oracle attestations via DLCs, with settlement transactions revealing nothing about the bet
• Contingent payments for data: a buyer pays for encrypted data, and the decryption key is revealed atomically through the adaptor signature when payment confirms
• Cross-chain DEX settlement: adaptor signatures enable trustless settlement across any two chains that support Schnorr (or compatible) signatures

Current Limitations and Open Research

Scriptless scripts are not a universal replacement for Bitcoin Script. Several limitations remain:

• Two-party restriction: most adaptor signature constructions are inherently two-party. Multi-party contracts require combining adaptor signatures with threshold schemes (like FROST), adding protocol complexity
• Interactivity: constructing adaptor signatures requires multiple rounds of communication between participants, unlike hash locks where the hash can be shared non-interactively
• Composition limits: while individual scriptless script constructions are well-understood, composing multiple conditions (AND/OR logic across several adaptor secrets) remains an active research area
• Half-aggregation incompatibility: adaptor signatures are not compatible with Schnorr half-aggregation techniques, which could limit future optimization paths
• Tooling maturity: developer libraries for adaptor signatures are less mature than standard Schnorr or ECDSA tooling, and few production wallets implement scriptless script protocols today

The Road Ahead

The trajectory of scriptless scripts depends on several concurrent developments. Lightning's migration to Taproot channels is the prerequisite for PTLC deployment, which would be the largest real-world application of adaptor signatures. DLC implementations are gradually adopting Schnorr-based constructions as Taproot adoption grows. And protocols like Spark, which already use FROST and Schnorr natively, are positioned to integrate adaptor signature constructions without the migration overhead that legacy systems face.

The broader significance is architectural: scriptless scripts represent a shift from putting contract logic where everyone can see it (on the blockchain) to putting it where only the participants need it (in the signature scheme). This improves privacy, reduces costs, and expands the design space for Bitcoin-based protocols. For developers building on Bitcoin Layer 2s, the Spark SDK provides a starting point for working with Schnorr-based signing infrastructure. For a deeper look at related cryptographic primitives, see our research on PTLCs and FROST threshold signatures.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.