Covenants and Bitcoin Script Extensions: What Comes Next?

Bitcoin covenants are rules in a script that determine where a coin may go next, not just who may spend it. Bitcoin cannot do that today. Proposals such as OP_CHECKTEMPLATEVERIFY (BIP 119), OP_CAT (BIP 347) or the LNHANCE package would make it possible, and with it vault wallets with a clawback window, cheaper batched payouts and simpler Lightning channels. As of November 2026 none of these proposals has been activated or scheduled for activation. The debate is less about whether than about which.

What a covenant is and why Bitcoin has none

A Bitcoin script is a lock on a coin. It can check whether a valid signature is present, whether someone knows the secret behind a hash and whether a certain time has passed. How that works in detail is explained in Bitcoin Scripts and Smart Contracts.

What a script cannot check: the transaction that spends the coin. Whoever has the right key may send the coin to any address at all. The script does not see the destination.

A covenant closes that gap. The term comes from property law: a covenant binds a piece of land whoever buys it. For Bitcoin it would mean, for example: "This coin may only go to address A, or to address B, but only after 144 blocks."

That Bitcoin cannot do this is partly an accident of history. In 2010 Satoshi Nakamoto disabled several opcodes after bugs were found, among them OP_CAT, which was later recognised as a building block for covenants. Since then Script has grown only in small, careful steps, most recently with Taproot in 2021. How such extensions reach the network via soft fork is described in Bitcoin soft fork explained.

What covenants would enable

The proposals differ technically but aim at similar uses.

Vault wallets. Your savings sit in a vault. A withdrawal always goes through an intermediate step with a waiting period first, say a day. During that time you can claw it back with a second, safely stored key. If someone steals your everyday key, they watch their loot disappear on its way to an emergency address. Today this only works with pre-signed transactions and deleted keys, which is error-prone.

Batched payouts (congestion control). An exchange has to pay 500 customers, but fees are high. With a covenant it sends a single small transaction that bindingly fixes how it will later split into 500 payouts. Customers are secured immediately; the split happens when block space is cheap.

Simpler Lightning channels. Covenants plus another extension would make LN-Symmetry possible, formerly called "eltoo". Today Lightning punishes an attempt to publish an old balance with the loss of the whole channel. That forces delicate backups. With LN-Symmetry the newest state simply replaces the old one. How Lightning works today is covered in the article on the Lightning Network.

Shared outputs without everyone's cooperation. Protocols like Ark split one on-chain output among many users. Today a group has to pre-sign for that. A covenant could fix the split directly in the script.

Further ideas: inheritance rules without a trustee, more efficient bets on external events (DLCs) and bridges to systems that verify computations outside Bitcoin (BitVM).

OP_CHECKTEMPLATEVERIFY (BIP 119)

CTV is the oldest and simplest of the serious proposals. Jeremy Rubin presented it in 2019, then under the name OP_SECURETHEBAG.

The idea: a script contains a fingerprint (hash) of a transaction. The coin may only be spent by a transaction that matches exactly this fingerprint, i.e. that has exactly these outputs with exactly these amounts. No signature can change that.

CTV is not recursive: the prescribed transaction is fixed; it cannot pass conditions on over an unlimited number of generations. That makes CTV predictable and less worrying to critics. The flip side: everything must be fixed in advance. A vault with a freely chosen withdrawal address or partial amounts cannot be built with CTV alone.

CTV's history shows how slow Bitcoin upgrades are. In April 2022 Rubin wanted to kick off an activation through his own client and withdrew the plan after heavy criticism. In summer 2025, initially 66 signatories of an open letter by James O'Beirne asked Bitcoin Core developers to review CTV together with CHECKSIGFROMSTACK within six months. In January 2026 a group held an activation meeting and favoured conservative parameters with long periods. As of November 2026 no activation is scheduled.

OP_CAT (BIP 347)

OP_CAT does something very simple: it joins two values in the script, ab and cd become abcd. Satoshi disabled it in 2010 because without a size limit it could blow up memory. BIP 347 by Ethan Heilman and Armin Sabouri brings it back for Tapscript, with the usual limit there of 520 bytes per value.

Why such a small opcode suffices for covenants is surprising. Developers such as Andrew Poelstra showed that with OP_CAT and a trick involving Schnorr signatures, the data of the spending transaction can be assembled and checked in the script. That allows almost any covenant, including recursive ones: rules that carry over to every future owner.

That is both strength and worry. Supporters see a general building block that can also build things nobody thinks of today. Critics fear exactly that: unforeseeable applications, more speculation on the blockchain and, at worst, coins that may only go to approved addresses.

The text of BIP 347 counts as complete in the BIP repository. On the test network Bitcoin Inquisition, a signet for trying out new rules, OP_CAT has been active since 2024. On mainnet it is not.

OP_VAULT (BIP 345)

In 2023 James O'Beirne proposed OP_VAULT, an opcode with exactly one purpose: vaults with a waiting period and clawback, including a freely chosen withdrawal address and partial amounts. Greg Sanders later joined as co-author. The proposal built on CTV.

As of November 2026 the BIP repository lists OP_VAULT as closed. O'Beirne himself most recently campaigned for CTV with CHECKSIGFROMSTACK as a simpler foundation. A comparison of different vault designs from October 2026 concluded that CTV covers simple vaults with fixed destinations well, while another proposal, OP_CHECKCONTRACTVERIFY (BIP 443), better supports partial withdrawals and choosing the destination address when the withdrawal is triggered.

LNHANCE and the CTV plus CSFS packages

Many developers consider CTV alone too little. That is why packages are mainly discussed today:

• CHECKSIGFROMSTACK (CSFS, BIP 348): checks a signature over arbitrary data, not just over the transaction itself. Together with CTV this gives "rebindable" signatures, the basis for LN-Symmetry.
• OP_INTERNALKEY (BIP 349): puts the internal Taproot key on the stack, saving space.
• OP_PAIRCOMMIT (BIP 442): commits to two values together, similar to OP_CAT but restricted so that no recursive covenants arise.

LNHANCE is the package of all four opcodes: CTV, CSFS, INTERNALKEY and PAIRCOMMIT. In December 2025 the developer Moonsettler proposed a soft fork for it, now that revised BIPs and reference implementations existed for all four building blocks. The name gives away the goal: enhancing Lightning.

A competing package came in mid-2025 from Greg Sanders, Antoine Poinsot and Steven Roose: OP_TEMPLATEHASH (BIP 446), a variant of CTV for Taproot scripts only, bundled with CSFS and INTERNALKEY (BIP 448). It changes no old script types and is meant to be easier to review as a result. For BIP 448 there are now implementations on Bitcoin Inquisition, a draft for LN-Symmetry and an Ark demonstration on signet.

Source: BIP repository on GitHub and Bitcoin Optech, retrieved 13.11.2026.

What the debate hinges on

That nothing has been activated after seven years is not for lack of interest. Five points hold things up.

Which proposal? There are at least half a dozen variants, some of them overlapping. Whoever activates one commits for decades, because a soft fork can practically not be undone.

How much expressiveness? A narrow opcode like CTV is easy to understand but can do too little. An open one like OP_CAT can do a lot, but nobody can survey all the consequences. The fear of recursive covenants, which could bind coins permanently to conditions, plays a large part.

Is there real demand? Critics ask who would actually use vaults and batched payouts. Supporters point to Ark, Lightning and BitVM projects that work with detours today.

How to activate? After the SegWit dispute of 2017 and the failure of BIP 110 in August 2026, distrust is high towards any activation not carried by a very broad majority.

Who reviews? The number of developers able to review consensus changes thoroughly is small. In 2025 and 2026 their time was also tied up by the dispute over data in transactions, described in the article on Ordinals and Inscriptions.

What this means for you as a bitcoin holder

In the short term, nothing. A covenant soft fork would create new options you can use but don't have to. Your existing addresses and coins remain valid. The 21 million are not up for debate; no proposal touches the money supply.

In the long term, a covenant could improve two things for savers: vaults that defuse a stolen key, and cheaper ways to use bitcoin without a custodian when on-chain fees rise. How fees and the security budget relate after the halvings is described in What comes after the last halving?.

You have a say through the software you run on your node. A soft fork only succeeds if nodes, miners and the economy go along.