Cov

Covenants and the coin that cannot redirect

Updated 22 October 2026

That is a covenant. It is not a key. The distinction matters, because every proposal to bolt a covenant opcode onto Bitcoin has been sold as if it changed who can spend, when in fact it only changes where the next box lands.

What a covenant actually constrains

A covenant is a script rule that constrains the next transaction a UTXO can land in. It does not introduce a new signer. It does not relax the signature check. It writes a destination into the box itself, so that whoever eventually spends the box must, in the same breath, point the coins at a transaction the covenant has already pre-approved.

OP_CTV (BIP-119) does this with a 32-byte hash commitment. The spending transaction must hash to a value the covenant reveals. OP_CAT does it by letting script glue two public keys together, so the spend must prove control of a child key derived from a parent. Both are sold as 'programmable money'. Both are really just narrower boxes. The lock on the lid is unchanged.

This is why the quantum threat and the covenant debate are unrelated in the way most coverage implies. Shor's algorithm targets the signature. A covenant changes the script, which sits behind the signature. You can bolt every opcode Taproot allows onto Bitcoin and Shor's machine still gets the same shot at the one elliptic curve point your keypair is built on.

OP_CTV, OP_CAT, and the difference that survives every cycle

OP_CTV commits to a single template. The covenant reveals a hash; the spending transaction must template-match. This is the cleanest covenant, and the most restrictive: it forces a specific amount to a specific script. It is the version most often proposed for Lightning channels, vault constructions, and congestion control, because the parties can agree once, lock the agreement into the box, and let the chain enforce the rest.

OP_CAT is messier and more general. By concatenating two stack items, it lets a script ask 'is this public key a known child of a known parent?'. That is enough to build covenants recursively, layer by layer. It is also enough to build non-covenants, which is why the conversation around it has been louder, longer, and less resolved.

Neither opcode, separately or together, is a 'quantum fix'. Neither is a 'quantum vulnerability' either. The box that holds your coins is opened by a signature. A covenant is a label on the inside of the lid. The label can say 'this box can only land on the table by the window'. It cannot say 'and only John may pick it up'. The signature is still John, or nobody.

Why the watch-only case is unchanged

A watch-only wallet, the kind this site has covered at length, holds the box's address. It can see the lid close. It can see the lid open. It cannot open the lid. No covenant opcode changes that, because the covenant lives in the script, not in the signature path.

If a covenant opcode were activated tomorrow, the question for watch-only users would still be the same one it is today. Where is the key? A passphrase does not become redundant because a covenant commits the destination. A hardware signer does not become redundant because OP_CTV restricts where the next UTXO can go. The signer is still the only thing that can produce a valid signature against the script, and the script, even with a covenant pre-commit, still requires that signature.

You will see threads on social media that conflate these. The argument goes: if OP_CTV pre-commits a template, the holder does not need to sign at the moment of broadcast, only at the moment of agreement. That is true and unrelated. The moment of broadcast still needs a signature. The moment of agreement still needs a key. The box still has a lock.

Covenants and the quantum runway counter

Earlier this year this site has tracked the quantum runway counter, the running estimate of how many bitcoin sit in addresses whose public key is exposed on chain. The current tier-1 figure has been falling, slowly, as old P2PKH coins move or get merged. A covenant opcode would not change that figure, because a covenant does not move coins. It conditions where coins go when they do move.

There is a more subtle interaction, and it is worth naming. Some proposed vault constructions use OP_CTV to pre-commit a recovery path that would, in theory, let a user rotate from a vulnerable key to a post-quantum key before the deadline lands. The argument is structurally clean: lock the coins today, with a covenant that already names the post-quantum address they must move to. When BIP-360 activates, the coins follow the covenant rather than the original key.

The argument breaks in the obvious place. The original key is still the key. Until the box is opened and routed through the covenant, the lid stays shut under the original key. If a quantum adversary reaches the public key first, the covenant is irrelevant. The adversary is not bound by it; the covenant is part of the script, and the script is what the signature unlocks, not what the attacker obeys. The vault pattern is a recovery primitive for honest users, not a defence against a capable attacker. Both can be true.

What the BIP-360 conversation has not yet said about covenants

BIP-360, in its current form, defines a new witness version for post-quantum signature schemes. It does not define a covenant opcode. It does not need to, because the question BIP-360 is answering is not 'where does the next UTXO go' but 'who is allowed to move this one'. A post-quantum signature scheme is the second; a covenant is the first.

There is a reading of the BIP-360 drafts that does mention covenants, in passing, as a recovery primitive for early movers. The reading is reasonable and out of scope for the main flag day. The reasoning is straightforward. A user who knows their current key is exposed can, today, construct a vault that pre-commits a post-quantum spend. The vault sits dormant until the user is ready to migrate. The covenant, in this construction, is a kind of clock. The clock reads 'not yet' until the user signs the trigger transaction.

The clock still needs a key. The trigger is still a signature. The trigger spends the box into the covenant-locked UTXO, and the covenant-locked UTXO then enforces the migration path. If the user waits too long, the same adversary that was a theoretical risk when the vault was built is now a practical risk against the trigger key. The covenant does not move the runway; it just gives a tidy landing strip for when the user finally does.

The pattern to keep in your head

Covenants are a script feature. Quantum is a signature feature. Watch-only is a tooling feature. None of the three substitute for any of the others. A box that is held by a covenant still has a lock. A lock that is held by a key can still be picked. A tool that watches the box still cannot open it.

When a Bitcoin proposal lands on your desk, sort it by which of those three features it touches. If it touches the script but not the signature, the quantum question is not changed. If it touches the signature but not the script, the covenant question is not changed. If it touches neither, the watch-only question is not changed. The proposals that touch more than one are usually the ones that are easiest to oversell, because the marketing collapses three separate questions into a single slogan.

That is the slogan, and it is the answer: covenants lock the lid shut on a specific destination. The lock is still the key, and the key is still the thing you have to keep off a watch-only field, off a phone, and out of every paste buffer a browser can read.