The Lock That Knows Its Own Key
It's 2 a.m. on a Sunday. You and a stranger named Deshi both need to send Bitcoin. Fees are ugly. A payment processor could batch your transactions together, sure, but that means handing your coins to someone you've never met, for however long the batching window runs. You don't know Deshi. You're certainly not trusting him.
This is the precise problem CHECKTEMPLATEVERIFY (BIP-119) was designed to solve.
CTV is a proposed Bitcoin opcode that commits a transaction output to one specific future spending transaction, defined in advance, with no third party holding funds at any point. The commitment is enforced by the script itself. No custodian, no multisig coordinator, no oracle. The math does the trusting.
What CTV Actually Does (And Why That's Unusual)
Most Bitcoin opcodes verify something about a signature or a time. CTV verifies something about a transaction template: a hash of the future transaction's outputs, input count, sequence values, and scriptSig hash. If the spending transaction doesn't match that hash, the script fails. Full stop.
This is a covenant. Bitcoin historically resisted covenants because they constrain what happens after a coin is spent, not just who can spend it. That constraint cuts both ways: it can restrict fungibility in ways that worry cypherpunks, but it also enables constructs that are currently impossible without a trusted coordinator. I think the tradeoff is clearly worth it for this specific, narrow construction, and I'll show you why.
CTV computes its hash over a carefully chosen subset of transaction fields. It commits to the version, locktime, number of inputs, sequences, number of outputs, the outputs themselves, and the index of the current input. Crucially, it does not commit to the input's outpoint (which TXID and vout is being spent). That omission is deliberate. It means any UTXO whose script contains a given CTV hash can be spent by the same template transaction, regardless of where those coins came from. This is the property that makes payment pools work.
Building a Payment Pool: The Mechanic Step by Step
A payment pool is a shared UTXO that multiple participants can exit from independently, without needing anyone else's cooperation. Here's how CTV makes that possible.
Suppose Amara, Deshi, and a third participant, Kenji, each want to hold 0.1 BTC in a shared pool. They construct a tree of pre-hashed transactions before any funds move on-chain.
The root is a single 2-of-3 multisig output holding 0.3 BTC, with a CTV hash committing to a specific split transaction: 0.2 BTC to a sub-pool for Amara and Deshi, 0.1 BTC directly to Kenji's address. The sub-pool output for Amara and Deshi contains another CTV hash, committing to a further split: 0.1 BTC each.
The entire exit tree is constructed and all hashes computed before a single satoshi moves. Once the root UTXO is funded, any participant can unilaterally exit by broadcasting their branch. Kenji doesn't need Amara's signature. Amara doesn't need Deshi's. Each branch is already valid by construction.
The funds were never held by a coordinator. They sat in a script with the exit instructions already baked into the hash at setup time, like a lockbox that came pre-addressed.
A realistic pool of 1,000 participants would require roughly 10 on-chain transactions per exit in the worst case (log2 of 1,000). Compare that to 1,000 separate on-chain transactions if everyone transacted independently. The savings compound dramatically at scale.
The Soft Fork Question (And Why CTV Is Simpler Than You've Heard)
CTV does require a soft fork to activate on mainnet. That sentence alone makes some readers close the tab.
It shouldn't. A soft fork tightens the rules: previously valid transactions become invalid under specific new conditions. Nodes that don't upgrade still follow the chain because the new rules are a strict subset. CTV, as specified in BIP-119, is unusually narrow. It introduces exactly one new opcode, OP_CHECKTEMPLATEVERIFY, replacing OP_NOP4 (a no-op that currently does nothing). Old nodes see a no-op and accept the transaction. New nodes enforce the template hash.
This is about as minimal as a soft fork gets. Compare it to Taproot, which introduced Schnorr signatures, Tapscript, and a new output type simultaneously. CTV is a single opcode with a well-defined hash function. The activation mechanism is the genuinely controversial part, not the code itself.
The debate over how to activate CTV has been louder than the debate over what CTV does. Proponents proposed a straightforward miner-signaling path; critics wanted more ecosystem review time. That social disagreement is real, but it's orthogonal to the technical validity of the construction. The payment pool mechanic works exactly as described whether activation happens next year or in a decade.
One Honest Caveat: What CTV Cannot Do
CTV is not a general covenant system. It commits to a specific template, not a class of templates. You can't write a CTV script that says "spend to any address, as long as the fee is under a certain rate." You can only say "spend to this exact transaction."
This means the exit tree must be fully constructed before funds are deposited. If Amara changes her mind about her exit address after the pool is funded, she cannot update it unilaterally. The tree is fixed. She'd need cooperation from all other pool members to reconstruct the root output with a new template.
That rigidity is a feature in one frame (the template can't be tampered with after setup) and a genuine limitation in another (the template can't be changed after setup, period). Payment channels on Lightning handle this via revocation keys and penalty transactions. CTV pools handle it by accepting the rigidity and treating unilateral exit as the fallback, not the routine.
There's also no native mechanism in CTV for fee-bumping template transactions if mempool conditions change dramatically between pool creation and exit. Solutions like anchor outputs or SIGHASH_ANYONECANPAY can be composed with CTV, but they add complexity. A pool designed in a low-fee environment might face awkward exit costs in a high-fee environment if the template fee rate wasn't padded generously at construction time. Worth planning for.
How This Fits Into Bitcoin's Scaling Stack
Payment pools built with CTV aren't a replacement for Lightning. Think of them as the on-ramp and off-ramp, not the highway. Lightning handles rapid, repeated payments between known counterparties. CTV pools handle entry and exit from those systems more efficiently, collapsing what would be many on-chain transactions into a tree structure where most participants never touch the chain at all.
Jeremy Rubin, CTV's primary author, estimated that a single on-chain transaction could represent the settlement of thousands of payments if the pool tree is deep enough. The on-chain footprint per participant approaches something logarithmic rather than linear. For a network whose base layer processes roughly 7 transactions per second, that asymptotic improvement matters more than almost any other architectural change on the table.
CTV also composes well with other proposals. Paired with ANYPREVOUT (APO), it enables more flexible payment channel factories. Paired with OP_VAULT (BIP-345), it creates time-locked withdrawal queues for cold storage that require explicit cancellation to reverse. The opcode is small. The design space it opens is not.
What Amara and Deshi Actually Get
Back to our two participants. With a CTV-based pool, they deposit into a shared UTXO once, transact off-chain through whatever coordination layer sits above the pool, and when either wants out, they broadcast their branch of the exit tree. One transaction, or at most a handful chained together, and they're done.
No custodian held their coins. No coordinator could have run away with the funds. The only trust required was in the Bitcoin protocol itself, which both parties already extended the moment they bought their first satoshi.
So ask yourself: if the batching already works technically, and the soft fork is genuinely minimal, what are we actually waiting for?
The argument for CTV isn't that it makes Bitcoin trustless. Bitcoin is already trustless. The argument is that it makes batching trustless, which is a different and genuinely harder problem. Batching has existed for years, always with a coordinator in the middle, holding keys, running servers, occasionally disappearing with both.
CTV removes the coordinator entirely. The template hash takes that seat. And unlike a company, a hash doesn't have a terms-of-service update.