Bitcoin Covenants: Restricting How Bitcoin Can Be Spent

Bitcoin transactions today enforce who can spend a coin, but not how it can be spent afterward. A valid signature unlocks funds to any destination the spender chooses. Covenants would change this by letting a transaction restrict the conditions of future transactions that spend its outputs. This seemingly narrow capability opens up vaults, payment pools, channel factories, congestion control, and entirely new Layer 2 architectures.

The idea has been discussed since at least 2013, when Gregory Maxwell first proposed restricting spending to whitelisted destinations. Since then, multiple proposals have emerged, each with different tradeoffs in expressiveness, complexity, and risk. None have been activated on Bitcoin mainnet. Understanding why requires digging into both the technical mechanics and the political dynamics of Bitcoin consensus changes.

What Is a Covenant?

In property law, a covenant is a restriction on how an asset can be used by future owners. In Bitcoin, a covenant is a spending condition that constrains the outputs of a future transaction. Rather than simply verifying a signature (proving authorization), a covenant-enabled script inspects the transaction that attempts to spend the coin: where it sends funds, how much it sends, and under what conditions.

Today, Bitcoin Script can enforce conditions like “this coin can only be spent by key X” or “this coin can only be spent after block height Y” (using timelocks). But it cannot express “this coin can only be sent to address Z” or “this coin must be split into at least two outputs.” Covenants fill that gap by enabling transaction introspection: the ability for a script to examine fields of the spending transaction itself.

Core distinction: Standard Bitcoin scripts verify who is spending (authentication). Covenants verify what the spending transaction looks like (introspection). This distinction is the foundation of every covenant proposal.

Why Bitcoin Lacks Covenants Today

Bitcoin Script is intentionally limited. Satoshi designed it without loops, with a small opcode set, and with no ability for a script to reference the transaction that spends it. This design philosophy prioritizes predictability and auditability over expressiveness. Every script terminates, every execution is bounded, and no script can create surprising or unbounded state.

Transaction introspection was explicitly excluded. The original opcodes that could have enabled it (like OP_CAT, which concatenates stack elements) were disabled early in Bitcoin’s history due to concerns about denial-of-service vectors. Without the ability to reconstruct and inspect parts of the spending transaction on the stack, scripts cannot enforce output conditions.

The Taproot upgrade in 2021 introduced Schnorr signatures and a new script version (tapscript), but did not add covenant capabilities. It did, however, lay groundwork: tapscript’s versioning system makes it easier to add new opcodes through soft forks without disrupting existing scripts.

Proposed Covenant Opcodes

Several proposals aim to bring covenant functionality to Bitcoin. They differ in scope: some are narrowly targeted at specific use cases, while others provide general-purpose introspection primitives.

OP_CHECKTEMPLATEVERIFY (CTV)

CTV, defined in BIP-119 by Jeremy Rubin, is the most conservative covenant proposal. It allows a script to commit to a hash of the spending transaction’s outputs, version, locktime, and input count. When the coin is spent, the script verifies that the spending transaction exactly matches the committed template.

CTV is non-recursive by design: it commits to a specific transaction structure, not to arbitrary future conditions. The outputs are fully determined at the time the covenant is created. This makes it straightforward to reason about but limits flexibility. You can define a tree of predetermined transactions but cannot create open-ended spending policies.

• Single new opcode replacing OP_NOP4
• Commits to a hash of outputs, version, locktime, sequences, and input count
• Non-recursive: the spending transaction is fully specified at covenant creation
• Enables congestion control, vaults, and batch payouts

SIGHASH_ANYPREVOUT (APO)

APO, specified in BIP-118, introduces new signature hash modes for tapscript. With SIGHASH_ANYPREVOUT, a signature does not commit to the specific input being spent. This means the same pre-signed transaction can be attached to different inputs, as long as the script conditions match.

APO is not a covenant opcode in the traditional sense, but it enables covenant-like behavior. Its primary motivation is enabling eltoo (LN-Symmetry), a simplified payment channel protocol where any later state can override any earlier state without penalty transactions. This eliminates the need for justice transactions and watchtowers in their current form.

• New sighash flags: SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT
• Signatures become reusable across different inputs with matching scripts
• Primary use case: eltoo/LN-Symmetry for simpler Lightning channels
• Also enables certain vault constructions and protocol upgrade mechanisms

OP_TLUV (Tapleaf Update Verify)

Proposed by Anthony Towns, OP_TLUV allows a script to modify a Taproot output by updating, adding, or removing leaves in the taproot tree without revealing the entire tree. The spending transaction must produce an output whose taproot tree matches the modified version.

This enables a powerful pattern: a group of participants can share a single UTXO and exit individually without requiring cooperation from others. When one participant leaves, the UTXO is updated to remove their leaf while preserving the rest of the tree. This is the foundation for scalable payment pools and coinjoins.

• Modifies taproot trees in-place during spending
• Enables unilateral exit from shared UTXOs
• Requires an internal public key update mechanism (often paired with other opcodes)
• Still in early design stages with no formal BIP

OP_CAT (Concatenation)

OP_CAT is the oldest disabled opcode being reconsidered, formalized in BIP-347 by Ethan Heilman and Armin Sabouri. It concatenates the top two elements on the stack into one. This sounds trivial, but concatenation is a fundamental building block for transaction introspection.

With OP_CAT, a script can reconstruct parts of the spending transaction on the stack, hash them, and compare the result against a Schnorr signature commitment. This enables a general form of transaction introspection: the script can verify properties of the spending transaction’s outputs, inputs, and other fields. Andrew Poelstra has demonstrated that OP_CAT combined with Schnorr signatures enables arbitrary covenant logic, though the resulting scripts are large and complex.

• Restores a disabled original Bitcoin opcode for tapscript
• General-purpose primitive: enables covenants, vaults, and more complex protocols
• Covenant scripts using OP_CAT are verbose compared to purpose-built opcodes
• Also enables STARK proof verification, Merkle proof validation, and other cryptographic checks

Comparing the Proposals

Use Cases

Vaults

A vault is a Bitcoin custody mechanism with a built-in time delay. When someone initiates a withdrawal, the funds move to a staging address where they are locked for a waiting period. During that window, the owner can “claw back” the funds to a recovery address if the withdrawal was unauthorized. After the delay expires, the funds move to the intended destination.

Vaults require covenants because the initial UTXO must enforce that it can only be spent into a transaction with a specific structure: one output to the staging address with a timelock, and one to the recovery address. Without covenants, this structure cannot be enforced by the script itself, only by operational discipline.

James O’Brien and Bryan Bishop proposed OP_VAULT (BIP-345), a dedicated opcode designed specifically for vault semantics. CTV can also construct vaults, though with less flexibility. OP_CAT enables vaults through more general scripting.

Congestion Control

During periods of high on-chain fees, a single transaction can commit to paying many recipients by creating a CTV-locked output. This output encodes a tree of future transactions that distribute funds to each recipient. The initial transaction is small (one output instead of many), so it confirms quickly and cheaply. Recipients can expand the tree later, each claiming their funds in separate transactions when fees drop.

Jeremy Rubin’s original CTV proposal highlighted this as a primary motivation. Exchanges and payment processors doing batch payouts could reduce their on-chain footprint significantly during fee spikes while giving each recipient a cryptographic guarantee of eventual payment.

Payment Pools

A payment pool allows multiple users to share a single UTXO and transact among themselves off-chain. With OP_TLUV or similar constructions, any participant can unilaterally exit the pool by publishing a transaction that separates their balance while keeping the rest of the pool intact.

This is a substantial improvement over current shared-UTXO designs, which typically require all participants to cooperate for any state change. With covenants, the exit path is enforced by the script, not by social agreement. Payment pools reduce the on-chain footprint per user while preserving individual sovereignty.

Channel Factories

Channel factories extend the payment pool concept to Lightning. A group of users opens a single on-chain transaction that creates a pool, and from that pool, individual Lightning channels are established off-chain. Channels can be opened, closed, and rebalanced within the factory without touching the blockchain.

Covenants make channel factories practical by enabling unilateral exits. Without covenants, a factory requires unanimous cooperation for every structural change, which becomes fragile as the number of participants grows. With CTV or OP_TLUV, participants can leave the factory independently, falling back to individual on-chain channels.

Scaling impact: Channel factories could reduce the on-chain footprint of Lightning channel management by an order of magnitude. Instead of one on-chain transaction per channel open and close, dozens of channels share a single on-chain anchor. This directly addresses Bitcoin’s throughput bottleneck for Layer 2 bootstrapping.

Improved Lightning Channels

APO enables eltoo (LN-Symmetry), a redesign of Lightning’s state update mechanism. Current Lightning channels use a penalty model: if a party broadcasts an old state, the counterparty can claim all funds as punishment. This requires storing every prior state and running watchtowers to detect fraud.

With eltoo, any later state simply replaces any earlier state. There are no penalty transactions, no need to store old states, and no toxic broadcast risk. This simplifies channel management, reduces storage requirements, and makes multi-party channels (more than two participants) feasible. The tradeoff is that cheating attempts are no longer punished financially, only corrected.

Use Case Comparison

Emulated Covenants: Presigned Transactions

Although Bitcoin lacks native covenants, similar behavior can be approximated using presigned transactions. The idea: create a UTXO whose keys are generated collaboratively, pre-sign all allowed spending paths, and then destroy the signing keys. Since no valid alternative transactions can be created after key deletion, the presigned transactions become the only possible spending paths, effectively emulating a covenant.

This is exactly the approach used by protocols like Spark and the original statechain proposal. In Spark, a two-of-two Schnorr-based multisig locks funds, and pre-signed exit transactions ensure users can always reclaim their Bitcoin on L1 without operator cooperation. The operator’s old key share is deleted after each transfer, making prior states unspendable.

Limitations of emulated covenants

• Key deletion cannot be cryptographically proven: trust is required that the signer actually destroyed the key
• All spending paths must be enumerated in advance: no dynamic or state-dependent conditions
• Interactive setup is required: all parties must be online to generate keys and sign transactions
• Scaling is limited: the number of presigned paths grows with the complexity of the intended spending policy

Native covenants would remove the key-deletion trust assumption entirely. The script itself would enforce spending restrictions, verifiable by any full node without trusting any signer.

The Debate

Recursive Covenants

A recursive covenant is one where the spending conditions can perpetuate themselves: the output of a covenant-restricted transaction can itself be covenant-restricted, and so on indefinitely. CTV is explicitly non-recursive: the spending transaction is fully determined at creation. OP_CAT, however, enables recursive constructions because it provides general-purpose introspection.

Proponents argue that recursive covenants enable the most powerful use cases: perpetual vaults (vaulting conditions that survive across transactions), rolling payment pools (participants can join and leave without resetting the pool), and on-chain state machines. Critics worry that recursive covenants make coins “tainted” by permanent spending restrictions, potentially creating fungibility problems and enabling regulatory encumbrances that follow coins across transfers.

MEV Concerns

Some researchers have raised concerns that expressive covenants could introduce miner extractable value (MEV) dynamics to Bitcoin. In Ethereum, MEV arises because smart contracts create complex transaction ordering dependencies. If Bitcoin covenants enabled sufficiently complex on-chain logic, miners might be incentivized to reorder or censor transactions for profit.

The counterargument: Bitcoin’s UTXO model is fundamentally different from Ethereum’s account model (see UTXO model vs account model). UTXOs are independent: spending one UTXO does not affect others. This independence limits the transaction ordering dependencies that create MEV in account-based systems. While covenants could introduce some new ordering sensitivities, the scope would likely be narrower than Ethereum’s MEV landscape.

Activation Politics

Bitcoin consensus changes require broad agreement across miners, node operators, and users. The last soft fork (Taproot) activated in 2021 after years of discussion. Covenant proposals face several political headwinds:

• No single proposal has achieved consensus: the community is split across CTV, APO, OP_CAT, and combinations
• Some developers advocate for a minimal approach (CTV only), while others push for more general primitives (OP_CAT)
• The “do no harm” philosophy favors inaction when risks are uncertain
• Activation mechanism debates (BIP-8 vs BIP-9, flag day vs miner signaling) add process friction

The bitcoin-dev mailing list and various working groups continue to discuss these proposals. Some developers have proposed “combo” soft forks that bundle multiple opcodes (for example, CTV + APO, or CTV + OP_CAT) to address more use cases in a single activation.

Covenants and Layer 2 Design

Every Bitcoin Layer 2 protocol must solve a fundamental problem: how to guarantee that users can exit to L1 without relying on counterparties. Today, this is done through presigned transactions (statechains, Spark), HTLCs (Lightning), or federated multisigs (Liquid). Each approach has tradeoffs in trust, interactivity, and scalability.

Native covenants would expand the design space significantly. A Layer 2 protocol could enforce exit conditions directly in the UTXO script, removing the need for trusted key deletion or constant online presence. This does not make existing approaches obsolete: it gives protocol designers more tools to optimize specific tradeoffs.

What Covenants Would Mean for Spark

Spark currently uses presigned transactions and collaborative key management to enable off-chain Bitcoin transfers. This works today without any consensus changes, but covenants would unlock several improvements:

• CTV could enable non-interactive batch settlements, where an operator commits to a set of payouts in a single transaction template without requiring each recipient to be online
• OP_CAT could simplify verification of certain protocol operations by enabling on-chain validation of Merkle proofs and state transitions
• Covenant-enforced exit paths would replace the key-deletion trust assumption with script-enforced guarantees, strengthening Spark’s security model
• Channel factories built with CTV or OP_TLUV could reduce the on-chain cost of Spark’s Lightning interoperability layer

Spark is designed to work within Bitcoin’s current consensus rules, and it does so effectively. Covenants represent a potential future improvement, not a current requirement. The protocol’s architecture is compatible with multiple covenant proposals and would benefit from whichever (if any) gets activated.

Other Covenant Proposals

Beyond the four major proposals, several other approaches have been discussed in the Bitcoin development community:

• OP_CHECKSIGFROMSTACK (CSFS): verifies a signature against arbitrary data on the stack rather than the transaction, enabling a form of introspection when combined with other opcodes
• OP_TXHASH: provides flexible transaction hashing with a field selector, allowing scripts to commit to specific parts of the spending transaction
• MATT (Merkleize All The Things): uses Merkle trees to encode arbitrary state machines in taproot outputs, enabling fraud proofs and optimistic execution
• OP_VAULT (BIP-345): a purpose-built opcode for vault semantics with recovery and unvaulting paths baked into the consensus rules

Each proposal reflects a different philosophy about how much expressiveness Bitcoin Script should gain. Purpose-built opcodes like OP_VAULT solve specific problems cleanly but require new consensus changes for each use case. General-purpose primitives like OP_CAT solve many problems but introduce more complexity and risk.

Practical Considerations

Script Size and Fees

Covenant scripts, especially those built with general-purpose opcodes like OP_CAT, can be significantly larger than standard Bitcoin scripts. Larger scripts mean higher transaction fees. Purpose-built opcodes like CTV and OP_VAULT produce compact scripts because the complex logic is embedded in the opcode itself rather than constructed from primitives.

Taproot mitigates this partially: only the executed script path is revealed on-chain. A vault with multiple spending paths (normal withdrawal, clawback, recovery) only reveals the path actually used. Unused paths remain hidden in the Merkle tree of taproot leaves, saving space and improving privacy.

Wallet and Tooling Support

Covenant-enabled transactions require wallet software that understands the new spending conditions. Users need tools to construct covenant scripts, visualize spending paths, and manage the lifecycle of time-delayed transactions. Miniscript and PSBTs provide existing frameworks for expressing and sharing complex spending policies, but they would need extensions to support covenant opcodes.

The Path Forward

Bitcoin covenant development is active but fragmented. Multiple proposals compete for attention and review cycles. Some developers advocate for activating the simplest useful covenant (CTV) as a first step, then iterating. Others argue for a more comprehensive approach that avoids multiple sequential soft forks.

The Bitcoin Core development process is deliberately conservative. Any soft fork must demonstrate clear utility, minimal risk, and broad community support. The covenant proposals that survive will likely be those that balance expressiveness with simplicity, enable concrete use cases without introducing systemic risks, and achieve rough consensus among a diverse set of stakeholders.

In the meantime, protocols like Spark, Lightning, and Ark continue building within Bitcoin’s current capabilities, using presigned transactions, HTLCs, and multisig constructions to approximate what covenants would provide natively. When covenants arrive, these protocols are positioned to integrate them for stronger security guarantees and more efficient operations.

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.