What are Bitcoin covenants?

Bitcoin covenants are proposed changes to Bitcoin's rules that would let a script control how its coins can be spent later. Today, a bitcoin script mainly checks who may spend a coin, for example by requiring a signature. A covenant would also limit the next transaction, such as allowing payment only to certain addresses or only after a delay.

How do Bitcoin covenants work?

Bitcoin Optech, a technical newsletter, describes covenants as consensus changes that let a script restrict the transaction that spends its funds. A common example is a vault. Coins could be sent only to a staging address first, and then to any address after a waiting period, which gives the owner time to react if a key is stolen.

Other suggested uses include payment pools, where many users share one coin, protocols such as Ark, improvements to Lightning and fairer payout schemes for mining pools. Optech also records concerns. These include the risks of recursive covenants that apply to every future spend, possible effects on miner incentives, and how much power to give the script language. Others point to approaches that need no rule change at all.

What is OP_CTV, or CheckTemplateVerify?

OP_CHECKTEMPLATEVERIFY, written by Jeremy Rubin and specified in BIP 119, would reuse an unused opcode, OP_NOP4. It checks that the spending transaction matches a 32-byte hash of a template. That template commits to details such as the version, locktime, number of inputs and outputs, and a hash of the outputs. The BIP says the goal is to cut the trust and storage needed for pre-signed transactions, with uses such as vaults, channels, payment pools and congestion control.

As of November 2026, BIP 119 is listed as a draft. In February 2026 a community member posted an activation client, separate from Bitcoin Core, with miner signaling from March 30, 2026, a 90% threshold and earliest activation around May 2027. Some forum replies argued that the community has not shown it is ready and asked for working demos that compare costs with designs that do not need CTV.

What is OP_CAT in Bitcoin?

OP_CAT joins two pieces of data on the stack into one. It existed in early Bitcoin but was disabled in 2010 along with other opcodes. BIP 347, by Ethan Heilman and Armin Sabouri, would bring it back inside tapscript, the script system added with Taproot, with results capped at 520 bytes. Its listed uses include vaults, simpler covenants, tree signatures and improvements to BitVM. The BIP's status is complete, which means the text is final, not that it is active.

Which Bitcoin soft fork proposals are being discussed?

The BIPs index, as of November 2026, lists several related proposals:

• BIP 118, SIGHASH_ANYPREVOUT, draft.
• BIP 119, CHECKTEMPLATEVERIFY, draft.
• BIP 345, OP_VAULT, closed.
• BIP 346, OP_TXHASH, draft.
• BIP 347, OP_CAT in Tapscript, complete.
• BIP 348, CHECKSIGFROMSTACK, draft.
• BIP 349, OP_INTERNALKEY, draft.

Any of these would need a soft fork, a backward-compatible rule change that requires broad support. See hard fork vs soft fork for how that process works.