Bitcoin covenant toolkit: A deep dive into CTV and CSFS

# Bitcoin covenant toolkit: A deep dive into CTV and CSFS ## Introduction Together, CTV (proposed in [BIP-119](https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki)) and CSFS ([BIP-348](https://github.com/bitcoin/bips/blob/master/bip-0348.md)) represent a powerful covenant toolkit. These opcodes have been under discussion for a long time (especially CTV), with extensive review and debate in the technical community. This guide provides an in-depth look at what CTV and CSFS do, how they work in concert, and what existing use cases they improve or new use cases they facilitate. We’ll explore the opcode semantics, consensus rules, and **composability** of CTV and CSFS, then dive deep into major applications: _Lightning “Eltoo” (LN-Symmetry) channels, Ark, Discreet Log Contracts, vaults, payment pools, congestion control_, and more. We also explain key concepts like **transaction templating**, **covenant primitives**, **programmable spending conditions**, and **key delegation** that underlie these proposals. ### An upfront note on the ideas within After sharing this draft with some peers and seeing the discussion around a [CTV + CSFS vault POC](https://x.com/dimahledba/status/1943681657006952844) I built, I realized it's important to add some context upfront. Not all the ideas discussed here carry the same weight, and some are actively debated in the community. Specifically, two points came up that are worth keeping in mind as you read: * **The "vault" debate:** Can CTV-based designs truly be called vaults? Some critics argue they don't offer a significant advantage over existing pre-signed transaction schemes and that focusing on them might distract from more powerful use cases. * **The limits of CSFS introspection:** While `OP_CHECKSIGFROMSTACK` can verify a signature on any data, what a script can *do* with that data is currently very limited. Without a way to parse or split the data on the stack efficiently (e.g with an opcode like `OP_CAT`), the practical applications of this kind of introspection are still more theoretical than proven. This feedback helped me see that I've grouped use cases that are in very different stages of development. * **Proven:** Use cases like **LN-Symmetry** and **Ark** represent more mature, better understood benefits. * **Exploratory:** Implementations like **vaults**, as presented here, are more exploratory and even controversial. * **Research:** Concepts like complex **key delegation** are still closer to the research phase. I'm sharing this reflection because it's part of the journey. Acknowledging these nuances is important, and it motivates me to dig even deeper into the practical, provable benefits of those opcodes (and the various alternatives being discussed) in the future. I hope this context is helpful. ## OP_CHECKTEMPLATEVERIFY (BIP-119) CTV Overview **OP_CHECKTEMPLATEVERIFY** is a proposed new opcode (re-purposing the no-op OP*NOP4) that allows an output’s locking script to commit to the exact template of a spending transaction*. In simple terms, CTV lets a user **predefine which transaction(s) are allowed to spend a given UTXO**. If a spender attempts to spend the UTXO with any transaction that doesn’t match the predetermined template hash, the script will fail and the spend is invalid. This turns Bitcoin’s usual “any spend is okay if you have the key” rule into “only a specific transaction (or set of transactions) can spend these coins,” enabling _covenants_ that constrain _how_ coins can be spent, not just _who_ can spend them. ### CTV semantics and validation When the CTV opcode executes during Script evaluation, it expects a 32-byte hash value on the top of the stack. The opcode then computes the hash of the current spending transaction according to a strict template, as defined in BIP-119’s `DefaultCheckTemplateVerifyHash`. This process involves serializing the transaction’s critical fields, such as version, locktime, input outpoints, sequence numbers, and all output details, in a deterministic order and hashing them. This hash, therefore, acts as a commitment to the exact structure and contents of the spending transaction. If the 32-byte commitment on the stack **matches** the computed hash of the transaction, the script simply continues its execution. However, if the hash does **not** match, the opcode immediately **fails the script**, causing the entire transaction to be rejected. There is no version of CTV that returns a boolean `true` or `false`; its behavior is inherently like a `VERIFY` opcode, always aborting on failure. Consequently, CTV enforces that _only a transaction precisely matching the committed template can spend this output_. The opcode will also fail if the stack is empty. In practice, script authors would typically use `OP_CHECKTEMPLATEVERIFY` directly, typically by pushing the hash commitment onto the stack followed by the opcode itself. CTV’s proposed activation as a soft fork would reuse the `OP_NOP4` slot. This makes it backward-compatible, as older nodes see `OP_NOP4` as a no-operation and will not be forked off the network, while new nodes will enforce the CTV rules. ### Consensus impact CTV does _not_ introduce any new cryptographic assumption or heavy computation, it’s essentially just hashing and comparing. It counts as a **native consensus rule** once activated: any block containing a spending transaction that doesn’t satisfy the CTV covenant (i.e. the transaction hash doesn’t match the committed hash) would be invalid. The design of CTV is intentionally limited to **non-recursive, pre-computed covenants**. Each CTV output fixes the spending transaction(s) in advance, so the covenant _cannot be extended indefinitely_ beyond the predefined steps. This was a conscious safety choice: more general “recursive covenants” (where conditions persist perpetually through each spend) are avoided by CTV to prevent unbounded restrictions on coins. In other words, **CTV covenants are fully enumerated at creation time**, the user must enumerate all possible spending paths up front (for example, by pre-constructing a sequence or tree of transactions). This property ensures that CTV covenants remain tractable and don’t risk unforeseen perpetual encumbrances on coins (a major fungibility concern with more powerful covenants). ### What CTV enables By enforcing _transaction templating_, CTV allows complex smart contract flows that were previously only possible with cumbersome workarounds (like chains of pre-signed transactions). With CTV, a user can commit an output to a _tree of transactions_ or a _specific series of spends_ that will happen in the future. This unlocks a variety of layer-2 and custody constructions: **channel factories and payment pools** (multiple parties sharing a UTXO with pre-planned split transactions), **vaults** (coins that can only be withdrawn via a delay and specific address), **congestion control transactions** (committing to a batch of payments to be executed later when fees drop), **scalable coinjoins** (one on-chain transaction fans out to many outputs through pre-committed sub-transactions), and more. We will explore these in detail later. The key point is that CTV shifts some contract logic from off-chain coordination (storing and exchanging presigned transactons) to on-chain enforcement via a consensus rule, but _without_ introducing arbitrary scripting, it’s a single compact opcode that forces a match against a hash. This simplicity has been a compelling point: CTV is small in scope yet extremely useful. Relying on chains of pre-signed transactions is brittle; it requires storing secrets and depends on the counterparty's cooperation or availability. CTV moves this enforcement to the Bitcoin protocol itself, making it non-interactive and trustless after setup. Beyond these issues, such pre-signed off-chain transaction schemes also necessitate highly complicated client implementations, which significantly narrows their versatility and negatively impacts the developer experience for building advanced use cases. Consequently, CTV not only improves upon trust assumptions and overall security but also dramatically simplifies the architecture of these systems. In others words: OP_CTV creates predetermined spending conditions that are enforced non-interactively, allowing new smart contract behaviors with minimal consensus changes. ### Example, simple CTV usage If Alice wants to ensure that her 5 BTC UTXO can only be spent in a transaction that pays 1 BTC to Bob and 4 BTC back to herself, she can first construct that exact transaction offline and compute its template hash. She then locks her UTXO with a script containing that commitment: ```text <32-byte-hash> OP_CHECKTEMPLATEVERIFY ``` To spend this UTXO, a transaction must be created that **perfectly matches the structure Alice committed to**: using only this UTXO as an input, creating two outputs (1 BTC to Bob, 4 BTC to Alice), and having an identical version, locktime, etc. Any other transaction structure will produce a different hash, causing the script to fail. In effect, Alice has **pre-authorized** the destination and structure of the spend. The transaction still needs to be valid, which typically means it must also include Alice's signature to satisfy a corresponding `OP_CHECKSIG` in the script. Once signed and broadcast, the funds will be transferred exactly as planned. This example illustrates how CTV restricts spending to a pre-approved outcome, a core feature of vault designs and other complex contracts. ## OP_CHECKSIGFROMSTACK (BIP-348) CSFS Overview **OP_CHECKSIGFROMSTACK** is a proposed opcode to enable _generic signature checks on arbitrary data within a script_ (repurposing `OP_SUCCESS204`). In essence, CSFS allows a script to take any message string from the stack, a public key, and a signature, and verify that the signature is valid for that message and key. This is in contrast to Bitcoin’s existing `OP_CHECKSIG`/`OP_CHECKSIGVERIFY`, which always verifies a signature against the _current transaction data_ (specifically, the transaction hash according to the sighash flags). With CSFS, the script itself can specify what message should be signed, enabling use of digital signatures as a general in-protocol authentication mechanism, not only for spending authorization. ### CSFS semantics and validation In script evaluation, `OP_CHECKSIGFROMSTACK` expects **three** items on the stack, in this specific order from top to bottom: **(1) a public key, (2) a message, and (3) a signature**. The opcode then performs a Schnorr signature verification according to BIP-340 rules: it checks if the provided signature is valid for the given message under the provided public key. If the signature is valid, `OP_CHECKSIGFROMSTACK` pops the three items and pushes a `true` value onto the stack. If it is invalid, it pushes `false`. Crucially, this operation does **not** use the transaction’s contents for verification, the “message” is whatever value the script provided from the stack. This distinction makes CSFS a powerful tool for **introspection**, allowing a script to verify arbitrary data or commitments. ### Use cases of CSFS By enabling arbitrary message verification, CSFS functions as a versatile primitive for new contract constructs: - **Oracles and DLCs:** A script can include an oracle’s public key and require a valid signature from that oracle on a given message (e.g. “Team X won the championship”) to unlock funds. This effectively brings the oracle’s attestation on-chain. In Discreet Log Contracts (DLCs), today oracle signatures are used off-chain via adaptor sigs; with CSFS, one could construct on-chain enforcement of payouts by having the oracle sign an outcome and putting that signature in the witness. (This trades some privacy for simplicity, more on this in the DLC section.) - **“Pay for signature” protocols:** CSFS allows one party to pay another **in exchange for a signature** on some data, in a trustless way. For example, Bob needs Alice’s signature on a message; they create a transaction that pays Alice some BTC if and only if a valid signature (by Alice’s key) is provided on that message. The script uses CSFS to check the sig. If Alice doesn’t provide it, she can’t claim the money; if she does, the transaction can go through paying her fee. (Adaptor signatures have largely taken over this use-case off-chain, but CSFS is the on-chain primitive for it.) - **Delegating authority (key delegation):** A wallet can delegate spending power to a second key without directly making it a multisig, by encoding a delegation condition in script. For instance, Alice’s coin could have a script: _“Either Alice’s own signature OR a signature by Bob on a certain message signed by Alice”_. In practice, Alice would create a message stating “I delegate spend of coin X to Bob” and sign it; the script would then verify (via CSFS) that Bob’s signature on that message is present, effectively proving Bob has Alice’s blessing. We’ll see a concrete example script for delegation below. This is like a one-time proxy signature on-chain. Graftroot (a related idea) could achieve this more privately, but would also require a soft fork. CSFS provides a straightforward delegation mechanism with existing keys. - **Fraud proofs and covenants:** A script can use CSFS to _inspect aspects of the spending transaction_ by making the spender provide a signature that covers specific data. For example, a script could require a signature under a known public key on the serialized transaction itself (or certain parts of it). If the same key’s signature appears twice for two different transactions (double-spend proof), a clever script can reveal the private key or penalize the user. Also, you can force the entire transaction data onto the stack (by having it signed) and then enforce arbitrary rules on it within script. This is essentially a general covenant mechanism: using CSFS, scripts could mimic things like CHECKLOCKTIMEVERIFY or even CTV itself by verifying the tx fields (This is heavy in practice because you have to push the whole tx and a signature on it, but it’s possible). - **Layer 2 protocols (Statechains, etc.):** CSFS can help protocols like **Statechains** or **Spacechains** by allowing off-chain state signatures to be verified on-chain. For example, a statechain transfer could be secured by an on-chain script that checks the state transfer message’s signature by the statechain server, allowing non-interactive transfers of UTXO ownership. In summary, OP_CSFS adds a form of programmable signature verification to Bitcoin Script, increasing what contracts can do. It **decouples the notion of a valid signature from the spending transaction**, enabling signatures to be treated as general proofs about arbitrary data. This complements CTV (which deals with _hashes of transactions_) by dealing with _signatures on messages_. ### Example – Delegation script To illustrate `OP_CHECKSIGFROMSTACK` (CSFS), consider a script that allows a coin to be spent in one of two ways: either a direct spend by its owner, **Alice**, or a delegated spend by **Bob**, but only if Alice has pre-authorized him. This logic is perfect for an `IF/ELSE` structure. Here is a conceptual script for this: ```python # A flag (1 for delegated, 0 for direct) provided in the witness selects the path. OP_IF # --- DELEGATED SPEND PATH --- # Witness must provide: <Bob_TX_Sig>, <Bob_Pubkey>, <Alice_Delegation_Sig>, <Delegation_Message> # 1. Verify Alice's off-chain delegation to Bob. <Alice_Pubkey> # Push Alice's known public key from the script itself. # (Stack manipulation opcodes like OP_SWAP are now used # to arrange the top three items into the correct order # for OP_CSFS: <signature> <message> <pubkey>) OP_CHECKSIGFROMSTACK OP_VERIFY # Fail script if Alice's delegation signature is not valid. # 2. Verify Bob's signature on this transaction. # The remaining items on the stack are Bob's public key and signature. OP_CHECKSIG OP_ELSE # --- DIRECT SPEND PATH --- # Witness only needs to provide: <Alice_TX_Sig> <Alice_Pubkey> # Push Alice's key from the script. OP_CHECKSIG OP_ENDIF ``` #### How It Works This script creates two distinct spending conditions, where the spender must provide the correct items in the transaction's witness to satisfy the chosen path. ##### Delegated spend (the `IF` branch) To use this path, the spender (Bob) must provide a witness containing all the necessary proofs, for example: `[Bob_TX_Sig] [Bob_Pubkey] [Alice_Delegation_Sig] [Delegation_Message] 1`. The script then performs two sequential checks: - **First, it verifies Alice's off-chain approval.** The script pushes Alice's hardcoded `<Alice_Pubkey>` onto the stack, which now holds the three required elements for the check (the signature and message having been provided in the witness). Then stack manipulation opcodes (like `OP_SWAP`) are used to arrange these three items into the precise order required by `OP_CHECKSIGFROMSTACK`. The opcode then validates the signature, and `OP_VERIFY` ensures the script fails if the approval is invalid. - **Second, it verifies Bob's approval.** With Alice's delegation confirmed, the script proceeds to a standard `OP_CHECKSIG`, which consumes Bob's signature and public key from the stack to authorize the specific transaction. ##### Direct spend (the `ELSE` branch) This is the simple case. Alice provides a witness like `[Alice_TX_Sig] 0`. The script executes the `ELSE` branch, which performs a standard `OP_CHECKSIG` to verify her signature against her public key, just like a normal single-signature wallet. This example demonstrates **key delegation**: Alice’s coins can be spent by Bob **only if** he can present a valid, off-chain cryptographic approval from Alice, which is then verified on-chain by CSFS. ### Consensus and Safety #### Activation as a soft fork `OP_CHECKSIGFROMSTACK` (CSFS) would be activated as a **soft fork** by repurposing an existing opcode (`OP_SUCCESS204). Like for any soft fork it would tighten the network's consensus rules: - **Old nodes** see the opcode as always succeeding. - **New nodes** require a valid signature for the script to succeed. #### Security and introspection CSFS is considered safe because it **introduces no new cryptographic assumptions**. It simply allows the script to verify standard Schnorr signatures on arbitrary messages, a capability that was previously unavailable to the script interpreter. Its primary function is to enable a limited and targeted form of **introspection**, where the script can validate data provided in the witness. #### Generality vs efficiency The main trade-off with CSFS is its impact on **transaction size and weight**. Using CSFS requires placing additional data, such as a 64-byte signature and a message, directly into the transaction witness. For complex covenants that require verifying large amounts of data, this can significantly increase transaction costs. This highlights the core design choice: - **CSFS** provides incredible **generality** at the cost of **efficiency**. - **Specialized opcodes** like `OP_CHECKTEMPLATEVERIFY` (CTV) are far more compact for their specific jobs but lack this flexibility. Ultimately, proposals like CTV and CSFS complement each other. CTV offers a highly efficient tool for the common use case of transaction templating, while CSFS provides a general-purpose building block for creating novel contracts. ## Using CTV and CSFS together – Composability and new patterns Individually, CTV and CSFS are useful; **combined, they unlock even more powerful constructions.** The two opcodes complement each other perfectly: CTV commits to a **specific transaction structure** (via its hash), while CSFS verifies that a **specific key has approved arbitrary data** (via a signature). By composing them, we can build sophisticated contracts with features like delegated spending, cross-input covenants, and even emulations of other proposed soft forks like `SIGHASH_ANYPREVOUT`. The list of use cases is not exhaustive (for example I am not mentionning here how CTV and CSFS could improve BitVM), and the examples are simplified for clarity. The goal is to provide a high-level understanding of how CTV and CSFS can be used in Bitcoin Script. ### Emulating ANYPREVOUT (Eltoo) A major goal for improving the Lightning Network is creating update transactions that aren't tied to a specific input, a feature proposed in `ANYPREVOUT` (BIP-118). Remarkably, CTV and CSFS can be combined to achieve a logically equivalent result. Consider a script like: `OP_CHECKTEMPLATEVERIFY <PubKey> OP_CHECKSIGFROMSTACKVERIFY` - The `OP_CHECKTEMPLATEVERIFY` part forces the spending transaction to have a specific structure, defined by a hash commitment. - The `OP_CHECKSIGFROMSTACKVERIFY` part then requires a valid signature from `<PubKey>` on that same transaction hash, which is provided as the "message" in the witness. The result is that the transaction's structure is fixed, and a specific party must sign off on that structure. Because the signature is over the transaction's template hash and not a specific input, this authorization can be used to spend **any UTXO** locked with this script. This is the core benefit of `ANYPREVOUT`. This powerful composition is the cornerstone of modern Lightning proposals like **LN-Symmetry**, allowing for punishment-free channel updates. ### General covenant toolkit Composing these opcodes creates a "covenant primitive toolkit" where CTV provides the **structural commitment** and CSFS provides the **signature authorization**. This allows for multi-stage or "cascading" contracts. For example, a CTV output can commit to a spending transaction that, in turn, contains another output with its own set of rules, perhaps requiring a signature from a different key, verified by CSFS. This enables complex, auditable workflows to be encoded directly into Bitcoin's script. ### Advanced key delegation and covenants We previously saw how CSFS enables key delegation. By adding CTV, we can create **delegated covenants**. For instance, a script can be designed with multiple spending paths using `IF/ELSE`: - **Default Path:** A `CTV` check forces funds into a time-delayed vault transaction. - **"Escape Hatch" Path:** An `IF` branch allows this `CTV` restriction to be bypassed, but only if a special delegation signature from the owner is provided and verified with `CSFS`. This allows for programmable spending conditions with fallback options and emergency overrides, all enforced by consensus. ### On-chain introspection A clever trick demonstrates the power of CSFS as a gateway to introspection. If a script requires the **exact same signature and public key pair** to pass both a standard `OP_CHECKSIG` and an `OP_CHECKSIGFROMSTACK`, it creates a powerful implication: the message verified by CSFS **must be** the hash of the current transaction. This forces the spender to place the transaction's unique hash onto the stack as data. Once there, other script opcodes could potentially operate on it, effectively allowing the script to "introspect" its own spending context. While contrived, this shows how CSFS can be a building block for verifying almost any condition about the spending transaction, albeit less efficiently than a dedicated opcode like `OP_TXHASH`. ### Summary: a pragmatic toolkit In summary, **CTV and CSFS together act as a "covenant toolkit."** CTV provides **transaction templating** (commitment to preset transactions), and CSFS provides **signature gating** (requiring certain signatures on arbitrary data). Many advanced contracts can be realized by combining these in creative ways. Importantly, both opcodes are non-Turing-complete and have constrained, analyzable behavior, making them a pragmatic and safe first step toward improving Bitcoin as programmable money. ## Use Case Deep Dive ### Lightning Eltoo / LN-Symmetry Channels One of the most anticipated applications of combining CTV and CSFS is enabling **Lightning Network Symmetry**, a new design for payment channels, also known as **Eltoo**. LN-Symmetry is a proposed upgrade to Lightning that eliminates the need for "penalty transactions" to handle fraud. Instead of punishing a party for broadcasting an old channel state, LN-Symmetry simply allows either party to broadcast the **newest** state they have, making the old one irrelevant. This simplifies channel management, reduces the data a user needs to store, and is a critical stepping stone for innovations like multi-party channels. This functionality was originally designed to rely on a proposed change called `SIGHASH_ANYPREVOUT` (APO), but it can be effectively emulated by combining CTV and CSFS. #### Emulating ANYPREVOUT with CTV and CSFS The core idea of `ANYPREVOUT` is to create a signature that authorizes a specific transaction structure but isn't tied to a particular input (or "previous output"). This allows a pre-signed update transaction to be "re-bound" to spend the output of any previous state. We can replicate this powerful behavior at the script level with a clever combination of the two opcodes: A conceptual script locking a channel's funds would be: `<Update_Template_Hash> OP_CHECKTEMPLATEVERIFY <Update_Key> OP_CHECKSIGFROMSTACK OP_VERIFY` Here’s how it works: - **`OP_CHECKTEMPLATEVERIFY`** enforces that the spending transaction must perfectly match the structure defined by `<Update_Template_Hash>`. This fixes the outputs, amounts, and other details. - **`OP_CHECKSIGFROMSTACK OP_VERIFY`** then requires that the spender provide a valid signature from the `<Update_Key>` on that **exact same hash**. Because the signature is validated against the transaction **template** rather than a specific input, it can be used to spend any UTXO locked with this script. This achieves the "re-bindable" transaction logic of `ANYPREVOUT`. #### Conceptual script example A simplified Taproot script for an LN-Symmetry channel could have two spending paths: - **Key path (cooperative close):** A simple MuSig key held by both channel partners, allowing them to close the channel instantly and collaboratively by creating a standard transaction. - **Script Path (unilateral close):** This path contains the covenant logic to enforce the Symmetry rules. ```script // Enforce a specific transaction structure (the "update" template) <Update_Template_Hash> OP_CHECKTEMPLATEVERIFY // Verify a signature on that template hash from the authorized update key <Update_Key> OP_CHECKSIGFROMSTACK OP_VERIFY // Enforce a relative time delay to allow a counterparty to respond <Dispute_Delay> OP_CHECKSEQUENCEVERIFY ``` ### Ark **Ark** is a Layer-2 scaling protocol designed to allow a large number of users to transact off-chain using "Virtual UTXOs" (vTXOs). It operates via a central party (Ark Service Provider) that coordinates transaction "rounds" without taking custody of user funds. The protocol's efficiency and user experience could be significantly improved by opcodes like CTV and CSFS. ### Covenant-less Ark ("clArk") The current version of Ark operates without new opcodes. This version, known as **clArk**, uses a clever but limiting workaround: - **Mechanism:** Instead of a covenant enforcing the rules of a shared UTXO, clArk uses **MuSig2 multi-signature signing**. To move funds within a shared UTXO, the server and **all participating users** must co-sign the transaction tree. - **The Major limitation:** This approach is **interactive**. A user **must** be online to co-sign if they are receiving funds or if their vTXO is being moved in a new round. This makes it impossible to non-interactively send funds to an offline user or to onboard new users without their active participation. As the Second team noted, this limitation means the current implementation is primarily used for refreshing the expiring vTXOs of existing, online users, rather than for seamless, cash-like payments. #### Ark with CTV Introducing `OP_CHECKTEMPLATEVERIFY` (CTV) would solve the interactivity problem and improve Ark's user experience. - **Mechanism:** With CTV, the shared UTXO is locked by a covenant script. The script enforces that the UTXO can only be spent by a transaction that has a specific, pre-agreed hash. This hash commits to an entire tree of subsequent transactions that correctly distributes the funds to each user's vTXO. - **Non-interactivity:** Because the rules are enforced by the on-chain covenant, individual users no longer need to co-sign each round. This enables several game-changing features: - **Send to offline users:** Alice can send funds to an offline Bob simply by including an output for him in the covenant's transaction tree. Bob doesn't need to be online to receive it. - **Non-interactive onboarding:** A new user can create their own vTXO and join the Ark pool without coordinating with the server or other users. - **Batched payouts:** Services like exchanges can pay out to thousands of users in a single on-chain transaction that creates a CTV-based Ark tree. Users receive their funds as vTXOs, which they can then spend off-chain or redeem on-chain at their convenience. Steven Roose, building Ark at Second team, [summarized](https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/17) the impact: “CTV is a game-changer for Ark… we could remove ~900 lines of code [from our implementation] and improve the user experience.” #### Ark with CSFS ("Erk") While CTV provides non-interactivity, adding `OP_CHECKSIGFROMSTACK` (CSFS) unlocks even more advanced capabilities, leading to a variant nicknamed "Erk." - **Mechanism:** "Erk" uses the `ANYPREVOUT` like behavior that can be emulated with CTV+CSFS. This allows for **re-bindable signatures** on "refund transactions." - **Perpetual offline refresh:** This mechanism allows the Ark server to safely refresh a user's expiring vTXO **even if the user remains offline indefinitely**. The pre-signed refund transaction gives the server permission to move the funds to a new vTXO on the user's behalf, but under conditions that the user can verify and, if necessary, override. #### Summary: The case for covenants Ark could benefit significantly from CTV + CSFS activation on Bitcoin: - **With CTV**, Ark becomes a non-interactive protocol for scalable off-chain payments. - **With CSFS added**, Ark gains advanced features like perpetual offline refresh, making it even more robust and user-friendly. ### Discreet Log Contracts (DLCs) **Discreet Log Contracts (DLCs)** are a powerful smart contract design that uses an external oracle to settle conditional payments, such as bets or financial contracts. In a DLC, parties lock funds into a multisignature output. Later, an oracle provides a digital signature attesting to the outcome of an event. This signature uniquely allows the winning party to claim their funds. The "discreet" aspect of current DLC implementations is a key feature: the oracle's signature is never published on-chain. Instead, participants use a cryptographic technique called **adaptor signatures**. This preserves the oracle's privacy and makes the final settlement transaction look like a standard multi-sig spend on the blockchain. However, the current design requires participants to create and exchange a complete set of pre-signed transactions for every possible outcome. For a contract with thousands of potential outcomes (e.g., a precise price bet), this setup process can be cumbersome. This is where new opcodes can offer significant improvements. #### CTV for DLCs: Streamlining setup `OP_CHECKTEMPLATEVERIFY` (CTV) can drastically reduce the number of signatures and interactive steps needed to establish a DLC with many outcomes. Instead of creating dozens or hundreds of individual outcome transactions, participants could use CTV to commit to a single transaction tree that covers all possibilities. For example, a root transaction, signed only once by all parties, could use CTV outputs to commit to branches of a tree, where each leaf represents a final outcome. When the oracle announces the result, the winning party can broadcast the transaction corresponding to the correct branch of the tree. The on-chain covenant guarantees that only one valid outcome path can be executed. This streamlines the complex setup process into a much simpler, less interactive one. #### CSFS for DLCs: Enabling on-chain oracles and simplifying PTLCs `OP_CHECKSIGFROMSTACK` (CSFS) offers two distinct ways to improve DLCs. - **Direct on-chain verification** CSFS allows for a simpler DLC model where the oracle's signature is verified directly by the on-chain script. The contract could have branches like, "if a signature from the oracle on message 'outcome A' is provided, pay Alice; if on 'outcome B', pay Bob." The winning party would simply include the oracle's signature in the witness to claim their funds. The trade-off is a significant loss of privacy, as the oracle's involvement and the contract's outcome become public. While the current DLC community generally prefers the privacy of adaptor signatures, this on-chain model could be useful for more public use cases, like a transparent prediction market. - **Simplifying Point Time Lock Contracts (PTLCs)** DLCs are often built using PTLCs, which rely on adaptor signatures and elliptic curve point arithmetic. CSFS could simplify these underlying mechanics by providing a more direct way to verify signatures on secret points or other data used in these schemes. While the existing DLC protocol is functional without these changes, **CTV can streamline DLC setup** and **CSFS can enable simpler contract logic**, making DLCs more flexible and easier to build. ### Vaults (secure custody with pre-defined withdraw paths) A **vault** is a smart contract designed to enhance the security of funds by imposing delays and specific rules on withdrawals. The core idea is to prevent the immediate theft of coins even if a private key is compromised. Instead of a simple, instant spend, a withdrawal from a vault is forced into a two-step process, giving the owner a time window to detect unauthorized activity and "claw back" their funds to a secure location. #### The Vault mechanism: a two-step process A typical vault operates with two key transactions that are planned in advance: 1. **The unvault transaction** - This is the **only** transaction that is allowed to spend the funds locked in the vault. It is forced to send the funds to a pre-defined, less-secure (for example "hot wallet", or singlesig hardware wallet) address. Crucially, this transaction includes a time delay (e.g., 24 hours), enforced by `OP_CHECKSEQUENCEVERIFY` (CSV). 1. **The clawback transaction** - This is an emergency recovery transaction. It can spend the funds **during** the 24-hour delay initiated by the unvault transaction. Its sole purpose is to redirect the funds back to the owner's most secure defined address (for example cold storage with multisig). In a normal withdrawal, the owner initiates the unvault, waits for the delay to pass, and then accesses their funds. If a thief initiates the unvault, the real owner is alerted and has 24 hours (or whatever time allowed by the configuration of the vault) to broadcast their clawback transaction, effectively canceling the theft. #### The CTV solution: on-chain enforcement Without new opcodes, implementing this two-step process requires risky and cumbersome pre-signed transactions. `OP_CHECKTEMPLATEVERIFY` (CTV) makes this process robust and secure by enforcing it at the consensus level. - **How it works** - The vault's script contains a CTV commitment to the hash of the unvault transaction. - This covenant guarantees that the vaulted funds can **only** be spent by that exact transaction, which includes the time delay and sends the funds to the pre-agreed hot wallet. - An attacker who steals the vault's key cannot bypass this rule. They are forced to broadcast the time-delayed unvault transaction, giving the owner the window they need to recover their funds. Basically CTV transforms vaults from a fragile off-chain agreement into a trustless, consensus-enforced security mechanism. #### CSFS enhancements: flexible authorization While CTV is the core component for building the vault structure, `OP_CHECKSIGFROMSTACK` (CSFS) can be used to add more flexible and dynamic authorization rules. - **Co-signer approval** A vault could require an additional authorization for withdrawals. For example, a script could demand a signature from a trusted third party or a security service on a message authorizing the withdrawal. CSFS would be used to verify this signature, adding a layer of multi-factor security. - **Dynamic conditions** CSFS could enforce more granular policies, such as "withdrawals over 1 BTC require a signature from a manager's key on a message containing the amount." This allows for enterprise-grade controls to be programmed directly into the vault's spending conditions. **CTV enables simple and secure vaults** by locking funds to a pre-defined, time-delayed withdrawal process. **CSFS can supplement these designs** by adding flexible, signature-based authorization rules. ### Payment Pools (CoinPools) A **Payment Pool**, also known as a **CoinPool**, is a collaborative custody scheme that allows many users to share a single UTXO. The primary goals are to improve scalability and privacy by reducing the on-chain footprint. Crucially, a well-designed pool allows any individual to unilaterally exit with their share of the funds without needing to trust or coordinate with the other participants. #### The current limitation: all-or-nothing pools Without covenants, the only way to create a trustless pool is with a large N-of-N multisignature contract. This approach has a major drawback: if even one participant becomes unresponsive or uncooperative, the entire pool often must be dissolved on-chain. This forces every single user to receive their funds in a separate output, completely negating the scalability and privacy benefits of pooling. #### The CTV solution: logarithmic exits `OP_CHECKTEMPLATEVERIFY` (CTV) offers a significant improvement by enabling a more graceful exit mechanism. - **Mechanism** Instead of a single N-of-N contract, the pool's funds are locked in a covenant that commits to a pre-defined **tree of transactions**. This tree is structured to allow for recursive splits. If a user needs to exit, the covenant directs the funds through a series of transactions that isolate that user's funds into a single branch, which they can then claim. The remaining funds are consolidated into a new, smaller pool UTXO for the other participants. - **The benefit: from linear to logarithmic cost** This structure reduces the worst-case on-chain cost of a single user exiting. - Without CTV: An 8-person pool breaking up requires **8** on-chain outputs. `O(N)` - With a CTV tree: An 8-person pool can be split with as few as **3** on-chain outputs (e.g., one for the leaver, and two for the remaining 7 participants now split into two smaller pools). `O(log N)` By ensuring that only a small part of the pool is affected when one user leaves, CTV helps keep shared UTXOs alive longer, improving both scalability and privacy. ### Congestion control and batch execution One of the most powerful use cases for `OP_CHECKTEMPLATEVERIFY` (CTV) is as a tool for **congestion control**. It allows entities like exchanges, and protocols like bridges, to handle large volumes of payments while remaining insulated from periods of high network fees. The core idea is to **commit now, execute later**. An entity can broadcast a single, small on-chain transaction during a high-fee period that commits to a large batch of future payments. The actual settlement of these payments can then happen whenever it's most economical. #### The CTV mechanism: A transaction tree This strategy is enabled by creating a **tree of transactions** locked by CTV covenants. 1. **Commitment transaction:** During high fees, the sender broadcasts a single root transaction. This transaction locks the total sum of the batch payment into an output with a CTV script that commits to the hash of a second-level distribution transaction. 2. **Distribution transactions:** This next layer of transactions (which are not yet broadcast) splits the total amount into several smaller outputs. Each of these can, in turn, be locked by another CTV script, creating more branches. 3. **Settlement:** This structure continues until the "leaves" of the tree are reached, where each leaf is a final payment to a single recipient. The sender or recipients can broadcast these subsequent layers of the tree later when network fees are low. Because each step is pre-committed by a CTV hash, the entire payout structure is guaranteed. #### Benefits of this approach This model provides several distinct advantages for different parties. - **For senders (e.g exchanges): lower costs** - Services can process large batches of withdrawals reliably without paying peak fees. This is a straightforward cost-saving measure that improves operational efficiency. - **For recipients: fee sovereignty** - Perhaps the biggest benefit is that it gives control back to the user. Instead of the exchange guessing a one-size-fits-all fee for the entire batch, the tree structure **allows each recipient to choose their own fee rate**. A user who needs their funds urgently can broadcast their final transaction with a higher fee (using CPFP), while a patient user can wait for the mempool to clear and redeem at a much lower cost. This allows each individual to decide their own urgency. - **For protocols (e.g bridges): execution isolation** - This mechanism is **critical for bridges** between Bitcoin and other layers. Congestion control **isolates the bridge's on-chain execution from the base layer's prevailing fee rates**. This means a bridge can issue necessary payments to enter or exit the system according to its own protocol rules, without being delayed or made prohibitively expensive by a sudden spike in Bitcoin transaction fees. It makes Layer 2 systems more robust and predictable. - **For the network: smoother demand** - This technique helps to "smooth out" demand for block space. Instead of flooding the mempool with transactions during peak hours, demand is deferred, leading to a more stable and efficient fee market for all participants. Congestion control via CTV is a powerful form of on-chain batching. It gives users and services a way to trade immediate settlement for lower costs, enforced by a trustless on-chain covenant. It is one of the most straightforward use cases for CTV, demonstrating how a simple covenant could potentially improve Bitcoin's efficiency under high load. ## Conclusion As we've explored, `OP_CTV` and `OP_CSFS` could represent a complementary toolkit for Bitcoin. CTV offers a powerful way to enforce a transaction's future **structure**, while CSFS provides the missing piece of verifying signatures on **any data**, decoupling authorization from the transaction itself. This simple combination unlocks a remarkable design space. From new generation Lightning channels with LN-Symmetry and high-security vaults to scalable off-chain protocols like Ark or BitVM and efficient batching for congestion control, the potential for innovation is big. I am personally enthusiastic about the potential of CTV and CSFS together. They would represent a pragmatic evolution of Bitcoin’s scripting capabilities, enabling new applications while preserving the core principles of security and simplicity. In my opinion, their activation would mark a significant, carefully considered step forward, enhancing Bitcoin as programmable money without introducing unnecessary complexity or risk. Thank you for reading, as final words, I'd like to encourage every Bitcoiner to participate in the debate: - **Educate yourself**: Read the specifications for CTV and CSFS. Study the proposals and their implications. Here is a [list of all resources for learning and developing for the CTV+CSFS upgrade](https://github.com/arshbot/awesome-ctv-csfs) that is a good starting point. - **Join the discussion**: Follow and contribute to the technical conversations on platforms like the [Delving Bitcoin forum](https://delvingbitcoin.org/) and the [bitcoin-dev mailing list](https://groups.google.com/g/bitcoindev). - **Test and build**: If you are a developer, experiment with these opcodes on signets (like [Mutinynet](https://mutinynet.com/) or [run your own](https://github.com/arshbot/ctv-csfs-signet-docker). Building proofs-of-concept is one of the most valuable forms of review. --- **Thanks** This article was improved by the sharp eyes and thoughtful feedback of some great people. A special thanks for their review goes out to: - [James O'Beirne](https://github.com/jamesob) - [Harsha Goli](https://github.com/arshbot) - [Salvatore Ingala](https://x.com/salvatoshi) --- **Sources:** - [BIP-119 (OP_CHECKTEMPLATEVERIFY) Specification](https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki) - [BIP-348 (OP_CHECKSIGFROMSTACK) Specification](https://github.com/bitcoin/bips/blob/master/bip-0348.md) - Bitcoin Optech Explainers on [CTV](https://bitcoinops.org/en/topics/op_checktemplateverify/) & [CSFS](https://bitcoinops.org/en/topics/op_checksigfromstack/) - Delving Bitcoin technical threads on [Ark](https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/17) and [LN Symmetry](https://delvingbitcoin.org/t/ln-symmetry-project-recap/359) - [utxos.org](https://utxos.org/) - Bitcoin-Dev mailing list discussions - [Bitcoin dev mail - OP_CTV simplifies and improves performance of DLCs by a factor of a lot](https://gnusha.org/pi/bitcoindev/CAH5Bsr2vxL3FWXnJTszMQj83jTVdRvvuVpimEfY7JpFCyP1AZA@mail.gmail.com/)