CTV vs OP_CAT (BIP 119 vs BIP 347)

OP_CHECKTEMPLATEVERIFY (CTV, BIP 119) is a purpose-built opcode that forces a coin to be spent by a transaction matching a template committed in advance; OP_CAT (BIP 347) is a general-purpose opcode that joins two pieces of data, and covenants are one of several things it could be used to build. CTV is narrow by design and OP_CAT is a broad building block; both are proposed soft forks that have not been activated.

Updated 2026-10-20 · 4 min read

At a glance

What CTV (BIP 119) proposes

BIP 119, by Jeremy Rubin, redefines OP_NOP4 (0xb3) as OP_CHECKTEMPLATEVERIFY. A script containing a 32-byte hash followed by OP_CHECKTEMPLATEVERIFY can only be spent by a transaction whose version, locktime, scriptSigs, input count, sequences, output count, outputs and input index hash to that value. That makes it a covenant: a rule about how coins may be spent next, not only who may spend them.

Each template is fixed when the output is created, so chains of CTV transactions are finite: BIP 119 describes each template as having a "path height" that strictly decreases. Its listed uses include vaults, congestion control, payment pools and batched channel creation. Because it upgrades a NOP, CTV would be available in legacy scripts, SegWit v0 and tapscript.

What OP_CAT (BIP 347) proposes

BIP 347, by Ethan Heilman and Armin Sabouri, would turn OP_SUCCESS126 (0x7e) in tapscript into OP_CAT: pop the top two stack items and push them joined together, failing if the result is larger than 520 bytes. 0x7e is the value the original OP_CAT used before a 2010 commit by Satoshi Nakamoto disabled it along with 15 other opcodes. BIP 347 says the usual explanation is that OP_CAT allowed scripts whose memory use grew exponentially, and that tapscript's 520-byte limit on stack elements removes that concern.

On its own, OP_CAT doesn't restrict transactions. BIP 347 lists what it would make possible: tree signatures, Lamport signatures (hash-based signatures discussed for quantum resistance), vaults, replicating CHECKSIGFROMSTACK, non-equivocation contracts, a fair-exchange protocol called Bitstream, and smaller transactions for BitVM2. Its covenant uses rely on tricks with Schnorr signatures described by Andrew Poelstra, which the BIP cites for building vaults and replicating CHECKSIGFROMSTACK.

CTV vs OP_CAT compared

The trade-off between them

The two proposals reflect different design philosophies. BIP 119 favors a single template type that is simple to analyze and cheap to validate, and says of more powerful covenant opcodes in general that they "come at substantially increased complexity and room for behaviors unintended by the application developer". BIP 347 favors "a simple, modular, and useful opcode in the spirit of Unix" that many protocols can build on, with uses well beyond covenants. Supporters of narrow opcodes value predictability; supporters of general ones value flexibility. The covenants guide sets out the wider debate.

Can CTV and OP_CAT work together?

Yes, in tapscript. BIP 119 orders its committed fields from least to most likely to change, and uses untagged hashes, partly so that scripts using OP_CAT could assemble templates efficiently. Its example lets the spender supply the input index at spend time:

OP_SIZE 4 OP_EQUALVERIFY <nVersion || nLockTime || input count || sequences hash || output count || outputs hash> OP_SWAP OP_CAT OP_SHA256 OP_CHECKTEMPLATEVERIFY

BIP 119 also notes that with a 520-byte limit, templates built this way would be limited to roughly 12 inputs and 12 outputs, depending on script type.

Which matters to you?

Neither is available on Bitcoin today; either would need a soft fork, and BIP 119 leaves activation logic to be "discussed elsewhere". For users nothing changes unless one is activated. For developers and reviewers, the comparison is about what each would allow, how hard that is to analyze, and which applications each serves. See also APO vs CTV, and the opcode reference for the opcodes involved.