OP_CAT enables covenants when combined with OP_CHECKSIG:

Stack before OP_CAT: [<item_a>, <item_b>]
Stack after OP_CAT:  [<item_a + item_b>]  (concatenation)

# OP_CAT enables covenants when combined with OP_CHECKSIG:
# You can construct the sighash preimage on the stack and verify
# it matches what's being signed — constraining transaction structure

# Example: Force an output to have a specific scriptPubKey
# (simplified, requires OP_CAT + OP_SHA256 + OP_CHECKSIGFROMSTACK or similar)

# Building a Schnorr signature from parts:
<R_x_bytes> <s_bytes>
OP_CAT
# Stack: [<64-byte Schnorr sig>]
OP_CHECKSIG  # Verify this assembled signature

OP_CTV behavior:
Stack input: <32-byte template hash>
Operation: Hash the current transaction's template
           Compare to stack input
           Fail if they don't match, continue if they do

Template hash commits to:

- nVersion

- nLockTime

- input count

- sequence of current input

- output count + outputs hash

- (NOT: which UTXOs are being spent)

// Vault using OP_CTV:
// Initial deposit goes into a "cold" vault output
Cold vault locking script:
<template_hash_to_warm_vault> OP_CTV

// This script can ONLY be spent by a specific transaction
// that sends funds to the warm vault — no other destination allowed
// The warm vault then has a timelock before final spending

Warm vault locking script:
<timelock> OP_CHECKLOCKTIMEVERIFY OP_DROP
<template_hash_to_final_dest> OP_CTV

// If the vault is ever compromised, the covenant structure
// gives the owner time to cancel (clawback) during the timelock

OP_VAULT enables:

- "Trigger" transaction initiates a withdrawal with a mandatory timelock delay

- During the delay period, funds can be "recovered" to a cold key

- After the delay, funds can be sent to the originally specified destination

- Much cleaner than trying to build vaults from OP_CTV primitives