Bitcoin Covenants — OP_CTV, OP_CAT, and the Programmability Debate

Bitcoin Covenants Explained

Covenants are perhaps the most hotly debated topic in Bitcoin development right now. They would add a new capability to Bitcoin Script: the ability to restrict how a coin can be spent in the future, not just who can spend it. This unlocks powerful new use cases but also raises concerns.

What is a Covenant?

Currently, Bitcoin spending conditions answer: "Who can spend this?" (prove you have the right key). Covenants add: "How can this be spent?" (the spending transaction must have specific properties — outputs, amounts, timelocks, etc.).

Example: A Vault

With covenants, you could create a vault where:

• Funds can only be withdrawn to a pre-specified address
• Withdrawals require a 24-hour delay
• During the delay, a "clawback" path can return funds to cold storage

Without covenants, this requires workarounds (pre-signed transactions). With covenants, it's enforced by the protocol itself.

The Main Covenant Proposals

OP_CHECKTEMPLATEVERIFY (CTV) — BIP 119

Proposed by Jeremy Rubin, CTV is the simplest covenant. It commits to the hash of the spending transaction template — the outputs, amounts, and other fields are predetermined. The spending transaction must exactly match the committed template.

• Enables: Vaults, congestion control (batched channel opens), non-interactive Lightning channels
• Simplicity: One new opcode, minimal attack surface
• Limitation: The template is rigid — no dynamic computation

OP_CAT — Concatenation Opcode

OP_CAT concatenates two stack items. It was in Bitcoin originally but was disabled by Satoshi (likely over concerns about script size). Restoring it (with Tapscript's relaxed size limits) enables surprisingly powerful covenants by allowing scripts to construct and verify transaction data on the stack.

• Enables: General covenants, token protocols, recursive covenants (coins that enforce rules across multiple transactions)
• Flexibility: Much more general than CTV
• Concern: Recursive covenants could create "tainted" coins that are permanently restricted

Other Proposals

• OP_VAULT (BIP 345): Purpose-built vault opcode by James O'Beirne
• MATT (Merkelize All The Things): General covenant scheme by Salvatore Ingala
• OP_TXHASH: Flexible introspection opcode

The Controversy

Covenants are controversial because of recursive covenants — spending conditions that propagate forward indefinitely. Concerns include:

• Government restrictions: Could a government mandate that "all Bitcoin from this exchange must only be sent to KYC addresses"?
• Permanent restrictions: Coins with irremovable spending conditions could reduce fungibility
• Complexity: More script capabilities = more potential for bugs and exploits

Counter-arguments:

• Government-mandated covenants would require the government to control the coins at the point of creation — they can't retroactively add covenants
• The benefits (vaults, better Lightning, scaling) outweigh the theoretical risks
• Without covenants, people build less-secure workarounds anyway

My Position

I'm cautiously in favor of CTV (simple, well-analyzed, limited scope) and optimistic about OP_CAT (more powerful, but needs more analysis). Vaults alone would be transformative for Bitcoin security. The ability to have a "cancel button" on unauthorized withdrawals changes the self-custody equation entirely.

Covenants aren't about adding complexity to Bitcoin. They're about making self-custody safer and scaling more efficient. The Bitcoin that onboards the next billion users will need better tools than what we have today.

Follow Bitcoin development debates on our blog.