BIP-446 & BIP-448: OP_TEMPLATEHASH Brings Advanced Covenant Capabilities to Bitcoin | Bitcoin Index

On March 17, 2026, the Bitcoin Improvement Proposal (BIP) repository merged Pull Request #1974, officially publishing two new Draft BIPs that could reshape how second-layer protocols work on Bitcoin.

BIP-446 introduces OP_TEMPLATEHASH, a new Tapscript opcode that allows Bitcoin scripts to commit to the exact transaction that must spend an output. BIP-448 bundles OP_TEMPLATEHASH with two other opcodes to enable rebindable transactions, a key capability for Lightning Network LN-Symmetry (formerly called eltoo) and Bitcoin vaults.

The merge comes after six months of review and positions OP_TEMPLATEHASH as a modern, Taproot-native alternative to the long-debated BIP-119 (OP_CHECKTEMPLATEVERIFY, or CTV).

What covenants do

A covenant is a Bitcoin script that restricts how coins can be spent in the future. Think of it as a contract that travels with the coins: “You can only spend me if you create a transaction that looks like this.”

Current Bitcoin scripts can check signatures and timelocks, but they can’t look at the transaction that spends them and say “this transaction must pay these specific addresses” or “this transaction must have these exact conditions.” Covenants change that.

OP_TEMPLATEHASH enables covenants by computing a hash of the spending transaction and pushing it onto the script stack. A script can then compare this hash to a pre-committed value, effectively saying “you can only spend me with this exact transaction.”

From the BIP-446 specification:

“OP_TEMPLATEHASH can be used to commit to the transaction spending an output. This capability can replace the use of pre-signed transactions in second-layer protocols. By reducing interactivity it makes such protocols simpler, safer, and sometimes notably more efficient.”

How OP_TEMPLATEHASH works

OP_TEMPLATEHASH redefines OP_SUCCESS206 (0xce) in Tapscript. When executed, it computes a tagged hash (using the TemplateHash tag from BIP-340) of the following transaction fields:

Transaction data:

nVersion (4 bytes): transaction version
nLockTime (4 bytes): transaction locktime
sha_sequences (32 bytes): SHA256 of all input sequences
sha_outputs (32 bytes): SHA256 of all outputs

Current input data:

annex_present (1 byte): whether a Taproot annex is present
input_index (4 bytes): index of this input in the transaction
If annex present: sha_annex (32 bytes): SHA256 of the annex

This results in at most 109 bytes being hashed. The BIP notes this is “strictly less hashing than is necessary for other existing operations,” addressing concerns about quadratic hashing attacks that have plagued earlier Bitcoin Script operations.

Critically, OP_TEMPLATEHASH reuses the pre-computed hashes from BIP-341 signature validation (sha_sequences, sha_outputs, sha_annex), making implementation efficient and preventing new attack vectors.

What it doesn’t commit to

OP_TEMPLATEHASH deliberately omits several transaction fields:

sha_prevouts / sha_scriptpubkeys: Committing to the exact coins being spent would create a hash cycle when the hash is in the output itself. Omitting these allows recovering from mistakes and spending multiple template-locked coins in one transaction.

sha_amounts: Not committing to spent amounts improves flexibility for recovery and prevents overcommitted funds from becoming permanently unspendable.

scriptSig: Taproot scriptSigs must be empty anyway, so this is unnecessary.

From BIP-446’s rationale:

“The flexibility of not committing to the specific coins spent is also desirable to recover from mistakes.”

Why not just use CTV?

OP_TEMPLATEHASH is explicitly designed as a Taproot-native alternative to BIP-119’s OP_CHECKTEMPLATEVERIFY. The differences matter:

Tapscript-only: OP_TEMPLATEHASH modifies only Tapscript, not legacy Script. This reduces the attack surface and implementation risk.

Pushes to stack vs. VERIFY: By redefining an OP_SUCCESS opcode instead of an OP_NOP, OP_TEMPLATEHASH can push the hash onto the stack (returning 1 for success, 0 for failure). CTV, as an OP_NOP redefinition, can only VERIFY (mark invalid on failure), requiring extra conditionals in scripts.

Commits to the annex: Unlike CTV, OP_TEMPLATEHASH commits to the Taproot annex (or its absence). This enables “annex-based proof of publication techniques” used in protocols like LN-Symmetry.

Reuses cached hashes: The template hash reuses BIP-341’s pre-computed subfields, preventing quadratic hashing and making implementation straightforward.

Brandon Black, who proposed the similar LNHANCE bundle in January 2024, responded to the initial OP_TEMPLATEHASH proposal in August 2025, noting it was “comparable in most ways” to LNHANCE, though “less efficient in onchain space for congestion control.”

BIP-448: the bundle proposal

BIP-448 is the deployment specification that groups three opcodes together:

OP_TEMPLATEHASH (BIP-446)
OP_CHECKSIGFROMSTACK (BIP-348)
OP_INTERNALKEY (BIP-349)

Together, these enable rebindable transactions, where signatures can be “rebound” to different transaction contexts.

OP_CHECKSIGFROMSTACK (BIP-348): Verifies a BIP-340 (Schnorr) signature over an arbitrary message, not just the transaction itself. This enables delegation, oracle attestations, and rebindable signatures when combined with OP_TEMPLATEHASH.

OP_INTERNALKEY (BIP-349): Pushes the Taproot internal key onto the stack. This saves 8 vBytes in scripts that need to reference the internal key and allows scripts to “automatically re-key” when the internal key is updated.

From BIP-349:

“Were the internal key to be updated from X to Y, the resulting program would be: TR(Y, {CTV OP_INTERNALKEY CSFS <S+1> CLTV}). The leaf would automatically re-key.”

What you can build with this

The BIPs enable or improve several important Bitcoin use cases:

Lightning Network LN-Symmetry (eltoo)

LN-Symmetry is a proposed Lightning channel update mechanism that allows any later channel state to replace any earlier one, without penalty mechanisms.

Current Lightning channels use penalty-based enforcement: if you broadcast an old state, your counterparty can claim all your funds. This makes backups dangerous and multiparty channels complex.

With LN-Symmetry:

No penalty risk: Publishing an old state just costs transaction fees, not all your funds
Simpler backups: Nodes only need to store the latest state
Multiparty channels: Three or more parties can share a single channel
Reduced message overhead: Eliminates the need to exchange HTLC signatures in every commitment_signed message

Combined with OP_CHECKSIGFROMSTACK and OP_INTERNALKEY, OP_TEMPLATEHASH enables rebindable signatures that can commit to update transactions while allowing the actual state to be updated without re-signing. The annex commitment is critical for LN-Symmetry’s proof-of-publication mechanism.

Bitcoin vaults

Vaults are a security mechanism where funds are locked with conditions that enforce a delayed withdrawal, giving the owner time to detect and cancel theft attempts.

By committing to the exact withdrawal transaction upfront, vaults can enforce a mandatory delay period before funds move, a “watchtower” mechanism to detect unauthorized withdrawals, and recovery paths that don’t require pre-signing with hot keys.

BIP-446 notes this reduces the need for “pre-signed transactions” that must be carefully managed.

Congestion control and payment batching

During high-fee periods, a sender can pay a single output that commits (via OP_TEMPLATEHASH) to a follow-up transaction paying multiple receivers. Once confirmed to suitable depth, all receivers are guaranteed payment without needing the sender to remain online.

BIP-446 notes this can “make receiving an Ark ‘VTXO’ non-interactive,” referring to the Ark protocol’s use of Virtual UTXOs.

Discreet Log Contracts

DLCs are smart contracts on Bitcoin that use oracles to settle bets or conditional payments based on real-world events. They currently require extensive pre-signing of all possible outcomes.

OP_TEMPLATEHASH can “significantly optimise” this by reducing the number of signatures needed, according to Lloyd Fournier’s analysis.

No new attack vectors

BIP-446 includes a detailed analysis showing that OP_TEMPLATEHASH does not introduce new DoS vectors via hashing attacks.

Baseline (existing SHA256 opcode): With clever scripting, an attacker can force a verifier to hash up to 41,600 bytes with a 763-byte script.

OP_TEMPLATEHASH: With the same 763-byte script, an attacker can force hashing of only 8,709 bytes.

From the BIP:

“At the limit of script size, the SHA256 script will be worse. … the result of TEMPLATEHASH would be trivial to cache, while the result of DUP SHA256 DROP would be more difficult.”

The BIP also includes comprehensive test vectors in two JSON files (basics.json and script_assets_test.json) that reuse Bitcoin Core’s Taproot test framework.

What happens next

Both BIPs are currently in Draft status. To progress toward activation, they would need:

Reference implementation in Bitcoin Core (already exists: instagibbs/bitcoin #op_templatehash)
Community consensus on the proposal’s merits and activation parameters
Activation mechanism (likely a BIP-9 style soft fork with miner signaling)
Testing on signet/testnet to prove out the concepts

BIP-348 (OP_CHECKSIGFROMSTACK) already has a regtest-only implementation in Bitcoin Core PR #32247. BIP-349 (OP_INTERNALKEY) has a reference implementation in Bitcoin Core PR #29269.

Gregory Sanders has been working on a research implementation of LN-Symmetry (Delving Bitcoin post, covered in Bitcoin Optech Newsletter #387).

Competing proposals

OP_TEMPLATEHASH isn’t the only covenant proposal in flight.

BIP-119 (CTV): The “older” covenant proposal that OP_TEMPLATEHASH aims to replace. CTV has more history and testing but modifies legacy Script and uses an OP_NOP (less flexible).

BIP-346 (OP_TXHASH): A more flexible alternative that allows programmable selection of transaction fields to hash. The BIP-448 authors argue this complexity is unnecessary:

“As the additional capabilities have not been demonstrated to enable new important use cases or substantially improve existing ones beyond this proposal, we favour the minimal approach.”

Why it matters

Covenants have been debated in Bitcoin development for years. The core tension is between flexibility (what new things can we build?) and safety (what new risks do we introduce?).

OP_TEMPLATEHASH takes a deliberately minimal approach: it commits to a specific set of transaction fields, reuses existing hashing infrastructure, and only modifies Tapscript. This makes it easier to reason about and harder to misuse than more flexible alternatives.

But minimal doesn’t mean weak. By enabling LN-Symmetry alone, OP_TEMPLATEHASH could make Lightning channels safer and simpler for millions of users. Add vaults, payment batching, and DLC improvements, and you have a compelling case for activation.

The hard part isn’t technical. The hard part is consensus.

BIP-446 acknowledges this in its acknowledgements section:

“Credit to Jeremy Rubin for his leadership and perseverance in defending how a simple primitive which allows committing to the entire spending transaction is useful for reducing interactivity in second layer protocols. This BIP draws on the design of BIP119 and is heavily inspired by his exploration of the potential uses for such a primitive.”

Getting a BIP merged is progress. Getting it activated is the real work.

Sources

Data as of March 23, 2026.