OP_TEMPLATEHASH

What Is OP_TEMPLATEHASH?

OP_TEMPLATEHASH is a proposed Bitcoin opcode defined in BIP 446 that allows a Tapscript to commit to the structure of the transaction spending a given output. When executed, it computes a hash of key transaction fields and pushes that hash onto the script stack. A subsequent opcode (such as OP_EQUALVERIFY or OP_CHECKSIGFROMSTACK) can then check that hash against an expected value, enforcing that only transactions matching a predefined template can spend the output.

The proposal was authored by Gregory Sanders, Antoine Poinsot, and Steven Roose. It entered Draft status in the Bitcoin BIPs repository in March 2026 alongside its companion proposal, BIP 448 (Rebindable Transactions). Together, these BIPs represent a Taproot-native alternative to the CTV plus CSFS soft-fork bundle that has been debated since 2020.

The core design philosophy behind OP_TEMPLATEHASH is reuse: rather than defining a new hash scheme from scratch (as CTV does), it reuses the precomputed sighash components already defined in BIP 341 for Taproot signature validation. This makes OP_TEMPLATEHASH a natural fit for Taproot's existing architecture and reduces the new consensus surface area that reviewers must audit.

How It Works

OP_TEMPLATEHASH redefines OP_SUCCESS206 (opcode 0xce) within the Tapscript execution context. It is not available in legacy Script or SegWit v0 scripts: limiting the change to Tapscript reduces the consensus review surface.

When a node evaluates OP_TEMPLATEHASH during script execution, it performs the following steps:

1. Gathers the relevant fields from the spending transaction: version (nVersion), locktime (nLockTime), the hash of all input sequences (sha_sequences), the hash of all outputs (sha_outputs), the current input index, and annex data if present
2. Serializes these fields into a preimage, using the same precomputed hashes that BIP 341 already computes for Taproot signature validation
3. Computes a tagged hash of the preimage using the tag "TemplateHash"
4. Pushes the resulting 32-byte hash onto the script stack

What the Hash Commits To

The OP_TEMPLATEHASH preimage includes the following transaction fields:

Notably, the hash does not commit to input scriptSigs because Taproot inputs always have empty scriptSigs. It also does not commit to the previous outpoint of the input being spent, which is what makes rebindable transactions (BIP 448) possible.

Stack-Based vs. Verify-Only

A key architectural difference from CTV: OP_TEMPLATEHASH pushes a value onto the stack rather than performing a verify-and-abort check. CTV redefines an OP_NOP opcode, which means it can only assert success or failure. It cannot leave a result on the stack for other opcodes to consume.

Because OP_TEMPLATEHASH redefines an OP_SUCCESS opcode instead, it can freely modify the stack. This makes the opcode composable: the template hash can be checked with OP_EQUALVERIFY for simple template matching, or passed to OP_CHECKSIGFROMSTACK for signature-based authorization of arbitrary templates.

# Simple template enforcement (equivalent to CTV)
OP_TEMPLATEHASH
<expected_hash>
OP_EQUALVERIFY

# Rebindable transaction (BIP 448 pattern)
OP_TEMPLATEHASH
OP_INTERNALKEY
OP_CHECKSIGFROMSTACKVERIFY

Annex Commitment

Unlike CTV, OP_TEMPLATEHASH commits to the Taproot annex when one is present. The annex is a reserved field in Taproot witness data that future soft forks can use for additional per-input data. By committing to the annex, OP_TEMPLATEHASH supports use cases like proof-of-publication in LN-Symmetry channels, where the annex carries state update proofs.

OP_TEMPLATEHASH vs. CTV

Both OP_TEMPLATEHASH and CTV (BIP 119) solve the same fundamental problem: letting a script constrain which transactions can spend a given output. They differ in scope, architecture, and composability.

CTV's advantage is simplicity: it is a smaller, more focused change with a longer review history. OP_TEMPLATEHASH's advantage is Taproot integration: by reusing existing sighash machinery, it avoids introducing a parallel hash domain and composes naturally with the BIP 448 opcode bundle. For a deeper analysis of the competing proposals, see the covenant activation path forward research article.

BIP 448: Rebindable Transactions

OP_TEMPLATEHASH was designed to work alongside BIP 448, which bundles three Tapscript opcodes into a single soft-fork proposal:

• OP_TEMPLATEHASH (BIP 446): pushes the transaction template hash onto the stack
• OP_CHECKSIGFROMSTACK (BIP 348): verifies a Schnorr signature against an arbitrary message on the stack
• OP_INTERNALKEY (BIP 349): pushes the Taproot internal key onto the stack

Together, these three opcodes enable "rebindable" transactions: a signature commits to the transaction template (via OP_TEMPLATEHASH) rather than to a specific input outpoint. Because the template hash omits the previous outpoint, the same signature remains valid when the transaction is "rebound" to spend a different UTXO with the same script.

This is the key primitive needed for LN-Symmetry (eltoo), where each channel state update must be able to spend any prior state's output. With rebindable transactions, each update transaction carries a signature that works against any previous state, eliminating the need for per-state revocation keys and justice transactions.

Use Cases

LN-Symmetry (Eltoo)

The primary motivation for the BIP 446/448 bundle is enabling LN-Symmetry, a proposed upgrade to Lightning Network channel mechanics. Current Lightning channels use asymmetric state: each party holds a different version of the commitment transaction, backed by revocation keys and justice transactions. LN-Symmetry replaces this with symmetric state updates that can override any prior state, simplifying channel management and reducing the risk of accidental fund loss from publishing an outdated state.

Vaults

OP_TEMPLATEHASH can enforce that funds move through a predefined sequence of transactions, creating vault-like custody patterns. A vault script could require that a withdrawal first moves funds to a staging address with a timelock, giving the owner a window to claw back funds if their keys are compromised.

Channel Factories and Multiparty Channels

Rebindable transactions simplify channel factories: constructions where multiple parties share a single on-chain UTXO and open Lightning channels among themselves off-chain. With symmetric state updates, factory participants can rebalance channels without closing and reopening the factory.

Statechains and Ark

Statechains transfer UTXO ownership off-chain by swapping signing authority. Rebindable signatures simplify the backup transaction scheme, because each new owner can carry a single update transaction that remains valid regardless of the chain of prior transfers. Ark variants also benefit from template-constrained outputs for connector outputs and virtual UTXO constructions.

Current Status

As of November 2026, OP_TEMPLATEHASH remains a Draft BIP. It has not been activated on Bitcoin mainnet, and no activation client exists for it. The BIP was merged into the official Bitcoin BIPs repository (PR #1974) in March 2026.

For testing purposes, Bitcoin Inquisition (a signet-based fork for evaluating soft-fork proposals) activated OP_TEMPLATEHASH alongside the BIP 448 bundle at signet block 314,928 on July 27, 2026. Developers can experiment with the opcode on this signet without risking real funds.

The proposal competes with the CTV (BIP 119) plus CSFS (BIP 348) activation bundle, which has a longer review history but has also not achieved mainnet activation. CTV has an activation client but reported 0% miner signaling. The Bitcoin covenant landscape remains in active debate, with no clear consensus on which proposal will activate first.

Risks and Considerations

Consensus Review Burden

Any new opcode requires extensive review because it permanently changes Bitcoin's consensus rules. While OP_TEMPLATEHASH reuses existing sighash components to reduce new surface area, the BIP 448 bundle introduces three opcodes simultaneously. Some community members argue that activating a single, well-reviewed opcode like CTV is safer than a three-opcode bundle, even if the bundle offers more functionality.

Tapscript-Only Limitation

OP_TEMPLATEHASH works exclusively in Tapscript. It cannot be used in legacy or SegWit v0 scripts. This is a deliberate design choice to reduce risk, but it means existing pre-Taproot wallets and protocols cannot use it without migrating to P2TR outputs.

Competing Proposals

The Bitcoin covenant design space includes multiple competing approaches: CTV, APO, OP_CAT, OP_TXHASH, and now OP_TEMPLATEHASH. Community disagreement on which approach to prioritize has delayed activation of any covenant opcode. Developers building on covenant assumptions should treat all proposals as experimental until one achieves mainnet activation. For a broader comparison of these proposals, see the covenants explained research article.

Recursive Covenant Risk

Because OP_TEMPLATEHASH can constrain spending transactions, it can in theory create recursive covenants: outputs that can only be spent into scripts that impose the same constraint indefinitely. Whether recursive covenants are a risk or a feature is debated. Proponents argue they enable vaults and other useful constructions. Critics worry they could create "tainted" coins that are permanently restricted, reducing fungibility.

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.