Bitcoin Covenant Definition

A Bitcoin covenant is a rule baked into a transaction that limits where or how the coins can be spent later. Think of it as a conditional promise attached to specific coins that only lets them move along preapproved paths.

How it fits into Bitcoin’s script

Standard Bitcoin transactions already use “spending conditions” like proving you have the right key, waiting until a time lock passes, or collecting multiple signatures. Covenants extend this idea by also restricting the destination or structure of future transactions. Instead of “you may spend if you sign,” a covenant can say “you may spend if you sign and the next transaction looks a certain way.” 

What proposals would enable covenants

Two proposals frequently discussed would add covenant-like behavior to Bitcoin Script:

• CheckTemplateVerify (CTV) commits to a template of transaction data by hashing chosen fields and comparing them to a preset value. If the hash matches, the spend is valid, which lets a wallet predefine a set of allowed future transactions. CTV is tracked as BIP-119. 
• CheckTXHashVerify is similar in spirit but can commit to selected parts of the future transaction rather than an entire template, giving more flexibility over which aspects are constrained.

Common designs you might see

• Whitelisted scripts or addresses: A coin can be locked so it only sends to a chosen script or a small set of destinations. It can also be staged to an interim address and only later be allowed to move freely. 
• Vaults: A self-custody setup where funds first move to a pre-set address with a time lock, while a separate “cancel” path can send them back to cold storage during a grace period. This design aims to limit damage if a hot wallet is compromised. 
• Congestion control: An exchange or service can precommit to a big payout transaction, then publish it when fees are cheaper, reducing costs while guaranteeing who gets paid. 
• Channel factories: Groups of users can open multiple Lightning channels with fewer on-chain transactions by coordinating via covenant-enforced transaction shapes.

Recursive covenants and the debate

A recursive covenant requires that each future spend also includes the same kind of restriction. Some community members worry this could enable address whitelists that never end, which might be used to enforce external compliance rules on-chain. Analyses often note that CTV’s design does not enable recursive covenants, while CheckTXHashVerify might, depending on how it is specified. 

Why people want covenants

Supporters point to practical wins: stronger theft mitigation through vaults, predictable batching that helps manage network fees, and building blocks for more expressive contract-like behavior without introducing full smart-contract complexity. These capabilities could also help services scale operations while keeping custody safer.

Risks and trade-offs

Covenants add complexity and influence coin fungibility if used broadly, since some coins would carry extra rules while others would not. Privacy and user experience need careful design so people do not trap funds or leak information about planned transactions. These concerns show up most clearly in discussions around recursive designs.

‍