BIP 446 (OP_TEMPLATEHASH)

What Is BIP 446?

BIP 446 is a draft Bitcoin Improvement Proposal that defines a new opcode called OP_TEMPLATEHASH for use within Tapscript. When executed, the opcode computes a hash of the transaction that is spending the output and pushes that hash onto the stack. Scripts can then compare this hash against a committed value to enforce that the spending transaction matches a specific template: controlling which outputs it creates, what locktime it uses, and how its inputs are sequenced.

The proposal was authored by Gregory Sanders (instagibbs), Antoine Poinsot (darosior), and Steven Roose. It was submitted as a pull request to the Bitcoin BIPs repository in September 2025 and merged on March 17, 2026 as a Draft specification. OP_TEMPLATEHASH is designed as a soft fork that only tightens block validation rules, meaning no block valid under the new rules would be invalid under current consensus.

The core motivation is to replace pre-signed transactions in second-layer protocols. Rather than requiring all parties to exchange and store signatures for every possible future state, a script can enforce the transaction structure directly. This reduces interactivity, storage requirements, and protocol complexity for systems like Lightning channels, Ark, and Discreet Log Contracts.

How It Works

OP_TEMPLATEHASH redefines the existing OP_SUCCESS206 (opcode 0xce) within the Tapscript execution environment. It is not available in legacy Script or SegWit v0 contexts. When a Tapscript interpreter encounters this opcode, it computes a tagged hash of specific transaction fields and pushes the resulting 32-byte value onto the stack.

The Template Hash Construction

The hash uses a BIP 340/BIP 341-style tagged hash with the tag "TemplateHash". The preimage includes the following fields:

• nVersion (4 bytes): the transaction version number
• nLockTime (4 bytes): the transaction locktime
• sha_sequences (32 bytes): hash of all input sequence numbers, reused from BIP 341
• sha_outputs (32 bytes): hash of all outputs, reused from BIP 341
• annex_present (1 byte): flag indicating whether an annex is attached
• input_index (4 bytes): the index of the input being executed
• sha_annex (32 bytes): hash of the annex data, included only when an annex is present

Without an annex, the hashed preimage is 77 bytes. With an annex, it expands to 109 bytes. All integers use 4-byte little-endian encoding.

What It Omits

Several fields present in BIP 341 signature messages are intentionally excluded:

• sha_prevouts and sha_scriptpubkeys: committing to these would create a hash cycle (the template hash would depend on a txid that depends on the template hash) and introduce quadratic hashing costs. It would also prevent spending two template-encumbered coins in the same transaction.
• sha_amounts: the authors argue this adds limited value and reduces flexibility. Omitting it allows recovery from underfunded commitments without requiring additional inputs to commit to exact amounts.
• hash_type: fixed because the template constrains all relevant fields.
• spend_type: replaced by the simpler annex_present flag since no extension is appended.

Stack Behavior

Unlike CTV (OP_CHECKTEMPLATEVERIFY), which acts as an assertion that verifies and consumes a hash from the stack, OP_TEMPLATEHASH pushes a value onto the stack. This design choice has important implications:

# CTV pattern: verify hash matches (assertion)
<expected_hash> OP_CHECKTEMPLATEVERIFY

# OP_TEMPLATEHASH pattern: push hash, then compare
OP_TEMPLATEHASH <expected_hash> OP_EQUALVERIFY

# OP_TEMPLATEHASH with rebindable signature
OP_TEMPLATEHASH <pubkey> OP_CHECKSIGFROMSTACK

The push-based approach is more composable. The hash can be used as input to other opcodes, enabling patterns like rebindable signatures where a signature covers the template hash rather than the full transaction. This is central to the companion proposal BIP 448, which bundles OP_TEMPLATEHASH with OP_CHECKSIGFROMSTACK and OP_INTERNALKEY to enable next-transaction commitments and rebindable signatures.

BIP 446 vs. BIP 119 (CTV)

Both proposals aim to enable transaction template verification, but they differ in scope, design philosophy, and technical trade-offs:

The Tapscript-only scope is a deliberate design choice. The authors argue that limiting the opcode to Taproot reduces the attack surface and avoids complications with legacy script contexts. Since Taproot scriptSigs must be empty, dropping the scriptSig commitment is safe and still provides txid stability in the single-input case.

A known trade-off is that OP_TEMPLATEHASH cannot be used in the BitVM construction where CTV can, because it does not commit to scriptSigs. For a deeper analysis of how both proposals fit into the broader covenant landscape, see the Bitcoin covenant activation path forward research article.

Use Cases

Lightning Network Optimization

In current Lightning channel designs, second-stage HTLC transactions require both channel parties to exchange and store a signature for every HTLC in every channel state. OP_TEMPLATEHASH can replace the 2-of-2 multisig requirement for these transactions, reducing the number of signatures that must be exchanged per state update.

LN-Symmetry (eltoo)

The LN-Symmetry protocol replaces Lightning's penalty-based revocation with update transactions that can supersede each other. OP_TEMPLATEHASH reduces the round trips required in this protocol by enabling rebindable update transactions when combined with OP_CHECKSIGFROMSTACK.

Ark Protocol

Ark uses shared UTXOs that are divided into virtual UTXOs. Currently, receiving a VTXO requires the recipient to be online to co-sign. With OP_TEMPLATEHASH, receiving becomes non-interactive: the covenant enforces the correct transaction structure without requiring the recipient's signature at creation time.

Discreet Log Contracts

Discreet Log Contracts (DLCs) require pre-signing a large number of possible outcome transactions. OP_TEMPLATEHASH can significantly reduce this overhead by enforcing payout structures through script rather than through stored signatures.

Vaults

Transaction templates can enforce time-delayed spending paths, creating vault constructions where funds must pass through an intermediate unvaulting step before reaching their final destination. This provides a recovery window if keys are compromised.

BIP 448: The Deployment Bundle

BIP 448 proposes deploying OP_TEMPLATEHASH alongside two additional opcodes: BIP 348 OP_CHECKSIGFROMSTACK (CSFS) and BIP 349 OP_INTERNALKEY. The authors argue that OP_TEMPLATEHASH alone may not justify a soft fork, but the bundle enables powerful new patterns:

• Rebindable signatures: CSFS can sign the template hash, allowing a third party to update transaction inputs without invalidating the covenant
• Next-transaction commitments: scripts can constrain not just the current spending transaction but also subsequent transactions in a chain
• Internal key access: OP_INTERNALKEY pushes the Taproot internal key onto the stack, enabling more flexible key-path and script-path interactions

Risks and Considerations

Draft Status

BIP 446 is a Draft proposal with no defined activation timeline or miner signaling parameters. It has been implemented in Bitcoin Inquisition for signet testing, but there is no consensus on when or whether it will be activated on mainnet. Developers should treat it as experimental.

Annex Commitment Debate

The decision to commit to the Taproot annex is controversial. Some developers worry it could conflict with future annex uses, such as cross-input signature aggregation (CISA). Others argue the annex should be committed to consistently with how Taproot sighashes handle it. Future soft forks could introduce a variant opcode that skips the annex commitment if needed.

No Amount Commitment

OP_TEMPLATEHASH does not commit to input amounts. While this provides flexibility for recovering from underfunded commitments, it means the opcode alone cannot enforce that a specific amount is being spent. Use cases requiring amount verification need additional script logic or complementary opcodes.

Tapscript-Only Limitation

Restricting OP_TEMPLATEHASH to Tapscript means it cannot be used in legacy or SegWit v0 scripts. This is intentional to reduce complexity and attack surface, but it means existing non-Taproot outputs cannot use the opcode. All parties must use Taproot addresses to benefit from template verification.

Competing Proposals

BIP 446 exists alongside several other covenant proposals, including BIP 119 (CTV), OP_CAT, OP_TXHASH, and APO. The Bitcoin community has not reached consensus on which approach (or combination) to activate. This uncertainty means developers building on any single proposal face the risk that a different one may ultimately be adopted.

Why It Matters

Transaction template verification is a foundational primitive for Bitcoin's scaling roadmap. Without it, second-layer protocols must rely on pre-signed transactions that require interactivity, storage overhead, and complex state management. OP_TEMPLATEHASH offers a path to simpler, more efficient layer-2 constructions by moving transaction structure enforcement into Bitcoin Script itself.

For protocols like Spark, covenant primitives could enable new design patterns that reduce trust assumptions and improve user experience. Whether through BIP 446 or an alternative, the ability to constrain future transactions at the script level represents a significant expansion of what Bitcoin can enforce trustlessly.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.