Covenant

What Is a Covenant?

In Bitcoin, a covenant is a proposed mechanism that restricts how a transaction output can be spent in the future. Today, Bitcoin outputs are locked by scripts that verify authorization: typically checking that the spender can produce a valid signature for the correct public key. Once authorized, the spender has complete freedom over where the funds go. A covenant changes this by letting the script inspect and constrain the spending transaction itself: which addresses receive funds, how much goes to each, what timelocks apply, and even what scripts the new outputs must carry.

The term "covenant" comes from property law, where a covenant is a restriction attached to land that binds future owners. Similarly, a Bitcoin covenant attaches spending restrictions that persist across transactions. This concept was first described by Möser, Eyal, and Sirer in 2016 and has since evolved into one of the most actively debated areas of Bitcoin development.

Bitcoin does not currently support covenants natively. All covenant proposals require changes to Bitcoin's consensus rules through a soft fork. The debate centers not on whether covenants are useful, but on which approach best balances functionality, simplicity, and safety.

How Covenants Work

To understand covenants, it helps to understand what Bitcoin Script can and cannot do today. Bitcoin Script can verify signatures, check timelocks, evaluate hash preimages, and combine these with boolean logic. What it cannot do is inspect the transaction that is spending the output. The script has no awareness of where the funds are going.

Covenants bridge this gap by giving scripts the ability to introspect the spending transaction. The mechanism varies by proposal, but the core idea is the same: the script can enforce conditions on the transaction's outputs, amounts, or structure.

Transaction Introspection

At a technical level, covenant opcodes work by making parts of the spending transaction available to the script execution environment. This can happen through several approaches:

• Template matching: the script commits to a hash of the expected transaction structure, and the opcode verifies the spending transaction matches that template
• Direct introspection: the script can push specific transaction fields (outputs, amounts, script hashes) onto the stack and evaluate them with existing opcodes
• Signature hash modifications: changing what data a signature commits to, allowing signatures that are valid for any input spending a particular output pattern

A Simple Vault Example

Consider a vault that protects cold storage Bitcoin. Without covenants, if an attacker obtains your private key, they can immediately sweep all funds to their own address. With a covenant-based vault:

1. Funds are locked in a covenant output that permits only two spending paths
2. Path A (unvault): moves funds to a staging address with a mandatory time delay (e.g., 24 hours)
3. Path B (recover): immediately moves funds to a pre-committed recovery address using a separate recovery key
4. During the delay period, monitoring software detects unauthorized unvaults and triggers the recovery path

Even if an attacker steals the spending key, they cannot bypass the time delay or redirect funds outside the covenant's permitted paths. This is conceptually similar to how a justice transaction punishes protocol violations in Lightning channels, but applied to on-chain custody.

# Pseudocode: covenant-based vault logic
# (Simplified; actual implementation depends on the opcode used)

IF <unvault_key> CHECKSIG
  # Covenant enforces: output must go to staging address
  # with a 144-block (approx. 24h) relative timelock
  <staging_script_hash> OP_CHECKTEMPLATEVERIFY
ELSE
  # Recovery path: immediately sweep to cold recovery
  <recovery_key> CHECKSIG
ENDIF

Major Covenant Proposals

OP_CHECKTEMPLATEVERIFY (CTV)

CTV, proposed in BIP-119 by Jeremy Rubin, is the simplest and most conservative covenant proposal. It adds a single opcode that verifies the spending transaction matches a pre-committed template hash. The hash covers the transaction's outputs, version, locktime, and input count, but not the inputs themselves.

CTV's power comes from its simplicity: it is non-recursive (a CTV output cannot create another CTV output that dynamically changes conditions), easy to reason about, and has a small implementation footprint. Its primary use cases include congestion control (batching many payments into a single on-chain transaction), vaults, and payment pools.

OP_VAULT

OP_VAULT, proposed in BIP-345 by James O'Beirne, is purpose-built for vault constructions. Rather than providing general covenant functionality, it optimizes specifically for the unvault-and-recover pattern described above. It introduces two new opcodes: OP_VAULT for initiating a time-delayed withdrawal and OP_VAULT_RECOVER for emergency clawback.

The advantage of OP_VAULT over implementing vaults with CTV is flexibility: OP_VAULT allows partial unvaulting (withdrawing some funds while keeping the rest locked), fee-rate flexibility at spend time, and a cleaner recovery mechanism. It builds on Taproot to keep the recovery path hidden until needed.

OP_CAT

OP_CAT is a revival of an opcode that Satoshi originally included in Bitcoin but disabled in 2010 due to concerns about memory-exhaustion attacks. It performs a single operation: concatenate two byte strings on the stack. Despite this simplicity, OP_CAT combined with Taproot's Schnorr signatures enables powerful covenant constructions.

By concatenating parts of a transaction and verifying the result against a signature, scripts can effectively introspect transaction data. This makes OP_CAT a general-purpose building block: it can emulate CTV, construct vaults, enable on-chain verification of zero-knowledge proofs, and much more. The tradeoff is complexity: building covenants from OP_CAT requires larger, more intricate scripts compared to purpose-built opcodes. For a deeper look at how Taproot enables these constructions, see the Taproot and Schnorr signatures explainer.

SIGHASH_ANYPREVOUT (APO)

APO, proposed in BIP-118, modifies the signature hashing mechanism rather than adding new opcodes. It allows signatures that do not commit to the specific input being spent, meaning the same signature is valid for any UTXO that carries the same script.

APO's primary motivation is enabling eltoo, a proposed upgrade to Lightning Network payment channels that simplifies state management and eliminates the need for revocation keys and justice transactions. With eltoo, any later channel state can override any earlier state, dramatically simplifying channel implementations and enabling more efficient channel factories. For background on how payment channels work today, see the research article on payment channels from concept to implementation.

Use Cases

Vaults and Custody

Vaults are the most frequently cited covenant use case. They add a time delay and recovery mechanism to Bitcoin custody, making key theft significantly less catastrophic. Institutional custodians and individual holders both benefit from having a window to detect and respond to unauthorized spending.

Congestion Control

During periods of high on-chain fees, a single payer (such as an exchange processing withdrawals) can commit to hundreds of future payments in a single transaction using CTV. Each recipient can later claim their payment individually when fees are lower. This reduces immediate block space demand while giving recipients a trustless guarantee of future payment.

Channel Factories

Channel factories allow multiple Lightning channels to be opened from a single on-chain transaction. Covenants (particularly APO-enabled eltoo) make factories more practical by simplifying the state update mechanism and reducing the penalty complexity that current channel designs require. This could significantly reduce the on-chain footprint of the Lightning Network, lowering costs for participants. For more on Lightning Network economics, see the research on Lightning Network liquidity.

Inheritance and Rate Limiting

Covenants can enforce time-based spending policies. For inheritance planning, a covenant can allow a beneficiary to claim funds only after a specified period of inactivity from the primary key holder: if the holder stops refreshing a timelock, the inheritance path activates.

Rate limiting is another application: a covenant can restrict a hot wallet to spending a maximum amount per day. Any attempt to exceed the limit requires a separate recovery key, limiting the damage from a compromised hot wallet.

Improved Layer 2 Protocols

Beyond channel factories, covenants enable entirely new Layer 2 designs. Protocols like Spark and other next-generation Bitcoin layers benefit from improved on-chain expressiveness. Covenants could allow more flexible exit mechanisms, shared UTXO pools, and trust-minimized bridges, strengthening the security assumptions of off-chain protocols built on the UTXO model.

The Recursive Covenant Debate

A recursive covenant is one where a spending condition can perpetuate itself indefinitely: the output script requires the spending transaction to create a new output with the same (or similar) covenant. This means the restriction follows the coins forever.

Recursive covenants are controversial in the Bitcoin community. Proponents argue they enable powerful constructions like on-chain autonomous entities, perpetual vaults that never need to be re-created, and sophisticated multi-party protocols. Critics raise several concerns:

• Fungibility risk: coins permanently locked in recursive covenants could become less fungible than unrestricted coins, creating a two-tier system
• Censorship vectors: covenants that enforce specific spending patterns could be used to implement on-chain blacklists or whitelists
• Complexity and auditability: recursive scripts are harder to analyze for correctness and could contain subtle bugs that lock funds permanently
• Unintended consequences: once activated, consensus changes cannot be easily reversed; recursive covenants may enable use cases that are difficult to foresee

CTV explicitly avoids recursion: its template hash commits to specific outputs, so the chain of constrained transactions always terminates. OP_CAT, by contrast, is expressive enough to construct recursive covenants, which is both its greatest strength and the source of most opposition.

Current State of Covenant Proposals

As of early 2026, no covenant opcode has been activated on Bitcoin mainnet. Several proposals have gone through extensive review:

• CTV (BIP-119) has a complete implementation and has been tested on signet, but consensus on activation has not been reached
• OP_CAT has seen renewed interest and has an active BIP (BIP-347), with growing support from developers building applications that would use it
• OP_VAULT (BIP-345) has a working implementation and strong support from the custody community
• APO (BIP-118) remains tied to the eltoo proposal and has a smaller but dedicated group of advocates

The Bitcoin community's cautious approach to consensus changes means covenant activation will likely take significant additional time. Some developers advocate for activating the simplest proposal (CTV) first and iterating, while others prefer waiting for a more general solution (OP_CAT) that could subsume multiple proposals. The debate reflects a broader tension in Bitcoin development: minimizing risk by keeping changes small versus maximizing utility by enabling more powerful primitives.

Risks and Considerations

Consensus Risk

Any covenant proposal requires a Bitcoin soft fork, which carries inherent risks. A poorly designed opcode could introduce vulnerabilities, and once activated, it cannot be easily removed. The Bitcoin community's high bar for consensus changes exists precisely because mistakes at this level affect all users.

Script Complexity

Covenants increase the complexity of Bitcoin scripts. More complex scripts are harder to audit, more likely to contain bugs, and more expensive to execute. Users who interact with covenant-locked outputs must understand the restrictions or risk losing funds by constructing invalid spending transactions.

MEV and Ordering Concerns

Some covenant constructions (particularly those involving shared UTXO pools or auction mechanisms) could introduce miner extractable value (MEV) dynamics to Bitcoin. If miners can profit by reordering or censoring covenant-related transactions, it may change Bitcoin's incentive structure in undesirable ways.

Fungibility Implications

If covenants become widely used to enforce spending restrictions, Bitcoin's fungibility could be affected. Coins carrying restrictive covenants may be valued differently than unrestricted coins, potentially fragmenting the monetary base. This concern is especially acute for recursive covenants that permanently constrain how coins can move.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.