Covenant
Also called: covenants, Bitcoin covenants, spending restrictions, transaction introspection, CTV.
A covenant is a script rule that restricts where coins can be sent next, not just who can spend them; several Bitcoin proposals would enable them.
A covenant is a condition on how coins may be spent in the future, such as which outputs the spending transaction must create, rather than only who may spend them. Today's Bitcoin Script mostly checks signatures, hashes and timelocks; it can't inspect the outputs of the transaction spending it. Similar effects are possible with pre-signed transactions and deleted keys, but users must trust that the keys really were deleted.
Covenant proposals
| Proposal | What it adds |
|---|---|
| BIP 119 OP_CHECKTEMPLATEVERIFY (CTV) | Requires the spending transaction to match a committed template hash |
| BIP 118 SIGHASH_ANYPREVOUT | Signatures that aren't tied to one specific coin |
| BIP 345 OP_VAULT | Purpose-built opcodes for vaults |
| BIP 347 OP_CAT | Joins two stack items, a building block for covenants and more |
| BIP 348 OP_CHECKSIGFROMSTACK | Checks a signature over arbitrary data |
| BIP 443 OP_CHECKCONTRACTVERIFY | Lets outputs carry data and constrains the next outputs' scripts |
| BIP 446 OP_TEMPLATEHASH | Pushes a hash of the spending transaction in Tapscript |
Several are designed to be combined, for example a template opcode together with CHECKSIGFROMSTACK. Each would need a soft fork, and most use Tapscript's OP_SUCCESS upgrade hooks.
Why covenants are debated
Supporters point to vaults that guard against key theft, batched payments and congestion control, shared UTXO schemes, and simpler Lightning designs. Critics raise concerns about complexity, unexpected uses such as recursive covenants that restrict coins indefinitely, and effects on fungibility. There is also disagreement about which design is the safest and most useful.
Read more in the covenants guide, and compare designs in BIP 118 vs BIP 119 and BIP 119 vs BIP 347.