You've just locked 5 BTC into a multisig treasury wallet. The keys are stored carefully. The policy, though, lives entirely in the heads of the signers, and nothing in the protocol itself prevents a compromised key from sending those coins straight to an attacker the moment it produces a valid signature. The script does not care where the money goes. It checks the signature. Full stop.

Covenants change that. They let the script itself care about the destination, the amount, even the structure of the next transaction. But different covenant designs make different promises, and they ask you to trust different things. That gap is the entire argument.

What a Covenant Actually Does to a UTXO

A standard Bitcoin output is a lock: produce the right key, or keys, and the money moves wherever the spender directs. A covenant adds a second constraint layer. Even with the right key, the spending transaction must conform to a template. Maybe the coins can only go to a specific address. Maybe they must be time-locked for another 144 blocks. Maybe a portion must always return to the same script.

The enforcement mechanism is where it gets interesting. Two broad approaches exist: introspection opcodes that let the script inspect the spending transaction directly, and pre-committed hash schemes that compare the transaction against a hash baked in at deposit time. Each carries different trust assumptions, and conflating them is a mistake a surprising number of technically literate people make.

OP_CHECKTEMPLATEVERIFY: Trust the Hash, Nothing Else

OP_CTV (BIP 119, proposed by Jeremy Rubin) takes the pre-commitment route. When you fund a CTV output, you embed a hash of the spending transaction's template: outputs, sequence numbers, the scriptSig hash, the number of inputs. To spend, the transaction must hash to exactly that value. The script verifies the hash. That's it.

Narrow. Explicit. The trust assumption has three components: that SHA256 is collision-resistant, that Bitcoin's consensus rules are enforced by the network, and that you computed the template hash correctly before locking funds. No oracle. No trusted third party. No runtime judgment call made by anyone but you, at funding time.

Consider how this plays out in practice. Alice is building a payment channel factory. She pre-computes ten possible settlement paths and encodes each as a CTV hash in a Taproot script tree. Once the coins are locked, not even Alice can redirect them to an eleventh path she failed to pre-commit. The restriction is baked into the UTXO itself, as immovable as the hash function underlying it. An attacker who steals Alice's private key can only spend into one of those ten pre-approved outputs, which is the kind of constraint that turns a key compromise from a catastrophe into a nuisance.

The cost of this is rigidity, and the cost is real. CTV covenants are static. The template is fixed at funding time. If you need dynamic behavior, you need a different tool.

OP_VAULT: A Recovery Mechanism With a Delay Built In

OP_VAULT (BIP 345, proposed by James O'Beirne) is purpose-built for vaulted cold storage with a recovery path. It introduces two opcodes, OP_VAULT and OP_VAULT_RECOVER, operating on the following logic: a spend from a vault must be triggered first, subject to a mandatory block-count delay, during which a recovery key can sweep the coins back to a safe address.

The trust assumptions here are layered rather than flat. At the base, you trust the same consensus and hash function security as CTV. On top of that, you trust that your recovery key is genuinely safe and that you, or a watchtower service running on your behalf, will monitor the chain during the delay window. If the trigger transaction appears and nobody catches it for 1,008 blocks, roughly a week, the thief completes the spend unchallenged.

That monitoring requirement is a real trust surface. Not a trusted third party in the custodial sense, but an operational assumption: liveness. Think of it like a burglar alarm that requires someone to actually be listening for the signal. A hardware wallet sitting in a drawer does not monitor the chain. A watchtower service does, but now you are trusting that service to be online and willing to broadcast the recovery transaction when the moment arrives. OP_VAULT does not eliminate trust. It relocates trust from the key to the watchtower and the time window.

That relocation is still worth something. A vault with a 1,008-block delay and a cold recovery key is meaningfully more resistant to key compromise than bare multisig. An attacker who steals the hot key still has to wait a week, in public, on-chain, before the coins move.

CHECKSIGFROMSTACK and Delegation's Slippery Surface

OP_CHECKSIGFROMSTACK, CSFS, is the most expressive of the three. Rather than checking a signature against the spending transaction, it checks a signature against arbitrary data placed on the stack. This enables covenant-through-delegation: an external authority signs a message describing the allowed spend, and the script verifies that signature.

Powerful. Also where the trust assumptions expand most visibly, and where readers inclined toward trustless systems should slow down and read carefully.

With CSFS, the spending restriction is only as strong as the key that signs the delegation message. If that key is a hardware security module operated by a company, you now trust that company's operational security, its key management practices, and its continued existence as a going concern. The script's enforcement is mathematically sound. The policy's enforcement depends on the humans holding the delegation key, and those humans are outside the protocol's reach.

For applications where a protocol needs to enforce spending rules that shift with external conditions, CSFS is attractive precisely because of that flexibility. But flexibility and trustlessness pull in opposite directions, and pretending otherwise is the kind of category error that tends to surface later in post-mortems. Every degree of freedom you add to the covenant is a degree of trust you extend to whatever key or oracle controls that freedom.

The Honest Calibration

These opcodes are not interchangeable security upgrades. They sit on a spectrum, and placing them correctly matters.

CTV occupies the minimal-trust end: static, hash-bound, no external dependencies. Its weakness is that you must know the full spending graph at funding time, which suits some use cases and rules out others entirely.

OP_VAULT sits in the middle. It adds liveness assumptions and a recovery-key trust surface, but remains fundamentally non-custodial and well-matched to personal cold storage where someone is willing to run, or pay for, a watchtower.

CSFS sits at the expressive end. It can replicate nearly any policy, but does so by leaning on external signers whose trustworthiness is beyond the protocol's authority to verify or enforce.

None of these opcodes are deployed on Bitcoin mainnet. All are proposals under active technical discussion, and their designs may change before any activation path is finalized. What will not change is the underlying tradeoff: richer covenant logic requires richer trust assumptions. You do not get dynamic, updatable spending rules without someone, somewhere, holding a key that makes those updates possible. That key belongs in your threat model whether you have named it or not.

So ask the right question of any covenant design. Not whether it restricts spending, they all do. Ask what an attacker needs to defeat the restriction. With CTV, they need to break SHA256 or subvert network consensus. With CSFS, they might only need to compromise one signing server. The distance between those two answers is the whole ballgame.