APO vs CTV (BIP 118 vs BIP 119)
SIGHASH_ANYPREVOUT (APO, BIP 118) is a proposed signature mode for tapscript whose signatures don't commit to the specific coin being spent, so one pre-signed transaction can be attached to any coin with a compatible script; OP_CHECKTEMPLATEVERIFY (CTV, BIP 119) is a proposed opcode that requires the spending transaction to match a hash fixed in advance. Both would make pre-planned chains of transactions easier to build, from different directions, and neither has been activated on Bitcoin.
Updated · 4 min read
At a glance
| BIP 118 | BIP 119 | |
|---|---|---|
| Title | SIGHASH_ANYPREVOUT for Taproot Scripts | CHECKTEMPLATEVERIFY |
| Status | Draft | Draft |
| Type | Specification | Specification |
| Assigned | 2017-02-28 | 2020-01-06 |
| Authors | Christian Decker, Anthony Towns | Jeremy Rubin |
| In plain English | Proposes SIGHASH_ANYPREVOUT, a signature type for Taproot scripts that does not commit to the exact coin being spent, so one signed transaction can be attached to any compatible coin. This would enable designs such as the 'Eltoo' upgrade to Lightning, simplifying channel updates and backups. | Proposes CHECKTEMPLATEVERIFY, a script instruction that restricts coins so they can only be spent in a transaction matching a predetermined template. This 'covenant' could enable vaults that protect against theft, efficient batched payments and other advanced contracts. |
What APO (BIP 118) proposes
BIP 118, by Christian Decker and Anthony Towns, adds a new public key type to tapscript: a 33-byte key starting with 0x01, or the single byte 0x01, which stands for the Taproot internal key. Signatures for these keys may use two new sighash flags:
SIGHASH_ANYPREVOUT(0x40): the signature doesn't cover the outpoint being spent, but still covers its amount, its scriptPubKey and the tapscript leaf.SIGHASH_ANYPREVOUTANYSCRIPT(0xc0): the signature also leaves out the amount, scriptPubKey and leaf hash.
The result is what BIP 118 calls dynamic rebinding: a signed transaction can spend any of several outputs that require the same key. The motivating use is eltoo, also called LN-Symmetry, a Lightning channel design in which a newer channel state can spend any older one. Because APO works only through Taproot script paths, an output opts in by including such a key in one of its leaves. The idea was previously called SIGHASH_NOINPUT.
What CTV (BIP 119) proposes
BIP 119, by Jeremy Rubin, redefines OP_NOP4 (0xb3) as OP_CHECKTEMPLATEVERIFY. Given a 32-byte argument, it fails unless the spending transaction's "DefaultCheckTemplateVerifyHash" matches. That hash commits to the version, locktime, scriptSigs (if any), number of inputs, sequences, number of outputs, all outputs and the index of the input being spent. Everything except which coins are spent is fixed in advance, so for a known input the spending transaction's txid is predictable.
CTV needs no signature: it is a hash comparison. As a NOP upgrade, like CLTV and CSV, it would be available in legacy scripts, SegWit v0 and tapscript. BIP 119 lists uses such as vaults, congestion control (a batch of payments committed in one output and expanded later), payment pools and batched channel creation. It has also been called OP_SECURETHEBAG.
APO vs CTV compared
| APO (BIP 118) | CTV (BIP 119) | |
|---|---|---|
| Type of change | New sighash flags for a new tapscript key type | New opcode replacing OP_NOP4 |
| What is checked | A Schnorr signature over a reduced message | A SHA256 hash of the spending transaction's template |
| Script versions | Tapscript only, script path only | Legacy, SegWit v0 and tapscript |
| What is fixed by the commitment | Outputs, version, locktime, input sequence; optionally amount and script | Version, locktime, input count, sequences, all outputs, input index |
| Paying fees later | Can combine with SIGHASH_SINGLE or SIGHASH_ANYONECANPAY |
Template is fixed; fees via anchors, extra inputs or sponsors |
| Main motivation in the BIP | eltoo channel updates | Vaults, congestion control, payment pools |
| Main risks named in the BIP | Signature replay across outputs that reuse a key; new malleability | Funds frozen or lost to fees when a reused template address gets the wrong amount |
| Earlier names | SIGHASH_NOINPUT |
OP_SECURETHEBAG; earlier design OP_CHECKOUTPUTSHASHVERIFY |
Where APO and CTV overlap
The two can partly imitate each other. BIP 119 shows that a SIGHASH_ANYPREVOUTANYSCRIPT signature made with a key whose secret is public, placed directly in the script, gives "something similar to templates". It then argues CTV is the better fit for that job: such scripts may use "about 2x-3x the bytes", need signature checks instead of a hash, and allow extra inputs or change, which CTV deliberately rules out. In the other direction, BIP 119 describes a variant of LN-Symmetry built from CTV plus OP_CHECKSIGFROMSTACK.
Supporters of each weigh these points differently. APO offers more flexibility for fee handling and channel protocols, at the cost of replay risks that wallets must manage. CTV is narrower and simpler to analyze, which BIP 119 presents as a deliberate choice, at the cost of templates that can't adapt once created.
Which matters to you?
Neither proposal is available on Bitcoin today: each would need a soft fork, and both BIPs leave the activation mechanism out of their specification. For wallet users nothing changes unless one is activated. If you follow the covenants debate, the useful questions are what each enables, what new risks it adds, and how it combines with other proposals such as OP_CAT. The live status of each BIP is shown on its page.
Frequently asked questions
What is the difference between APO and CTV?
APO (BIP 118) is a signature mode: a signature that doesn't commit to the exact coin, so one pre-signed transaction can spend any compatible output. CTV (BIP 119) is an opcode: the output's script fixes a hash of the spending transaction's outputs and other fields, and no signature is needed. APO works only in tapscript; CTV would work in every script version.
Are APO and CTV active on Bitcoin?
No. As of October 2026 neither has been activated on Bitcoin mainnet. Each would require a soft fork, and both BIPs leave the activation mechanism out of their specification. Their BIP pages on this site show the current status of each proposal.
Can APO do what CTV does?
Partly. BIP 119 explains that a SIGHASH_ANYPREVOUTANYSCRIPT signature from a key with a public secret, placed in the script, can commit to a transaction template much like CTV. BIP 119 argues CTV is more compact (APO may take about 2 to 3 times the bytes) and cheaper to verify, while APO can be combined with SIGHASH_SINGLE or ANYONECANPAY for more flexible fees.
What is eltoo (LN-Symmetry)?
Eltoo, also called LN-Symmetry, is a proposed design for Lightning channels in which any newer channel state can spend, and so replace, any older state that reaches the chain. That needs signatures which aren't tied to one specific previous transaction, which is the motivation for BIP 118's SIGHASH_ANYPREVOUT. BIP 119 describes a variant built from CTV and OP_CHECKSIGFROMSTACK.
What were SIGHASH_NOINPUT and OP_SECURETHEBAG?
They are earlier names. SIGHASH_NOINPUT was the original form of BIP 118 before it was rebuilt on Taproot and renamed SIGHASH_ANYPREVOUT, because it still commits to some input data such as nSequence. OP_SECURETHEBAG is an earlier name for BIP 119's OP_CHECKTEMPLATEVERIFY, which itself replaced an earlier CHECKOUTPUTSHASHVERIFY design.