BIP446 and BIP448: OP_TEMPLATEHASH Covenant Proposal Gains Formal Numbers | Bitcoin Index

Bitcoin developers Greg Sanders, Antoine Poinsot, and Steven Roose have published formal specifications for two new Bitcoin Improvement Proposals: BIP446 (OP_TEMPLATEHASH) and BIP448 (Taproot-native rebindable transactions). The proposals gained official BIP numbers in February and March 2026, and the full specification merged into the BIPs repository on March 17.

This marks a significant milestone for covenant research. Covenants are script primitives that restrict how Bitcoin can be spent in the future, something currently emulated through pre-signed transactions. The proposals offer a Taproot-native approach to transaction templates that could improve Layer 2 protocols like Lightning Network, Ark, and LN-Symmetry (eltoo).

What OP_TEMPLATEHASH does

OP_TEMPLATEHASH allows a Bitcoin script to commit to the structure of the transaction that will spend it. Instead of requiring pre-signed transactions with all parties’ signatures, the spending constraints are enforced directly by the script itself.

The opcode pushes a template hash onto the stack. This hash commits to specific fields of the spending transaction: version, locktime, input sequences, outputs, and (optionally) the Taproot annex. If the actual spending transaction doesn’t match the committed template, it’s rejected.

This is similar to Jeremy Rubin’s OP_CHECKTEMPLATEVERIFY (BIP119), which has been discussed since 2019. But OP_TEMPLATEHASH makes different design choices optimized for Taproot.

Why Taproot-native matters

Unlike OP_CTV, which works across legacy Script, SegWit, and Tapscript, OP_TEMPLATEHASH only works in Tapscript (Taproot’s scripting environment). This narrower scope reduces complexity and risk.

The opcode also reuses Taproot’s existing signature hashing infrastructure. When a Taproot transaction is verified, Bitcoin nodes pre-compute hashes of input sequences and outputs. OP_TEMPLATEHASH reuses these exact same hashes, making it computationally efficient.

Another key difference: OP_TEMPLATEHASH pushes the template hash onto the stack rather than just verifying it. This makes it composable with other opcodes, enabling more flexible script designs.

What it enables

Lightning Network: Fewer signatures

Every HTLC (Hashed Timelock Contract) in a Lightning channel currently requires both parties to exchange signatures for the second-stage transaction. These signatures must be exchanged at every channel state where that HTLC is active.

With OP_TEMPLATEHASH, the HTLC output in the commitment transaction can commit to the second-stage transaction structure directly, replacing the 2-of-2 multisig. This eliminates the need to exchange and store second-stage HTLC signatures, reducing both communication and storage overhead.

Ark: Non-interactive receipt

Ark is a Layer 2 protocol where users receive off-chain “VTXOs” (Virtual Transaction Outputs). Currently, receiving a VTXO requires real-time coordination between sender and receiver, which is a significant UX limitation.

As documented in a Delving Bitcoin discussion, OP_TEMPLATEHASH enables non-interactive VTXO receipt. The Ark service provider can create VTXOs with covenant-enforced spending paths, and recipients can claim them later without being online during creation. This makes Ark work more like regular Bitcoin addresses.

LN-Symmetry: Simpler state updates

LN-Symmetry (formerly “eltoo”) is a proposed Lightning channel mechanism that replaces penalty-based enforcement with a simpler approach: any later state can replace any earlier state.

This requires rebindable signatures that can bind to different update transactions as the channel evolves. BIP448 bundles OP_TEMPLATEHASH with two other opcodes (OP_CHECKSIGFROMSTACK and OP_INTERNALKEY) specifically to enable this pattern.

The annex commitment in OP_TEMPLATEHASH also helps here. The Taproot annex can be used for proof-of-publication, proving that data was broadcast on-chain without requiring extra signatures.

DLCs: Fewer pre-signed transactions

Discreet Log Contracts currently require pre-signing a large number of transactions to cover all possible oracle outcomes. As Lloyd Fournier noted, OP_TEMPLATEHASH provides a significant optimization by reducing the number of pre-signed transactions needed.

Design decisions

Why not commit to inputs or amounts?

A key design choice in BIP446 is not committing to the prevouts (inputs being spent) or their amounts. This differs from signature hash semantics and might seem surprising.

The rationale is about flexibility and avoiding hash cycles. If an output commits to a hash that includes its own scriptPubKey, you create a circular dependency. By not committing to all inputs, users can recover from mistakes by adding another input with appropriate value.

As Greg Sanders noted in a mailing list discussion, attempting to commit to other inputs without proper authentication doesn’t meaningfully improve security.

The annex commitment controversy

The decision to commit to the Taproot annex is the most debated aspect of BIP446. All other Taproot operations commit to the annex, so deviating would be inconsistent. The annex commitment also enables proof-of-publication techniques needed for LN-Symmetry.

However, some developers worry this could conflict with future uses of the annex (like CISA key ordering for cross-input signature aggregation). If the annex gains structured meaning later, committing to it now might prevent those features.

The BIP446 authors decided that if annex commitment proves problematic, a future OP_TEMPLATEHASH_NO_ANNEX could be added. But for initial deployment, consistency with existing Taproot semantics justifies including it.

Security and performance

A common concern with new opcodes is whether they enable denial-of-service attacks through expensive hashing. The BIP446 specification includes detailed analysis showing that OP_TEMPLATEHASH causes strictly less hashing than existing SHA256 operations at Bitcoin’s script size limit.

The template hash result is also trivial to cache (same transaction structure = same hash), while arbitrary SHA256 results are harder to cache. The authors conclude that OP_TEMPLATEHASH poses no new DoS risk.

How it compares to other proposals

vs. OP_CHECKTEMPLATEVERIFY (BIP119)

OP_CTV works across all script contexts (legacy, SegWit, Tapscript), while OP_TEMPLATEHASH is Tapscript-only. OP_CTV uses an OP_NOP redefinition (verify-only), while OP_TEMPLATEHASH uses an OP_SUCCESS redefinition (stack-based).

The annex commitment is another key difference. OP_CTV doesn’t commit to the annex, while OP_TEMPLATEHASH does.

vs. LNHANCE

Brandon Black previously proposed a bundle called “LNHANCE” consisting of OP_CTV + OP_CHECKSIGFROMSTACK + OP_INTERNALKEY. BIP448 (this proposal) uses OP_TEMPLATEHASH instead of OP_CTV.

As Brandon noted in his reply, the proposals are “comparable in most ways,” though they make different trade-offs around efficiency and complexity.

vs. More flexible introspection

Some proposals offer more programmable transaction introspection, like BIP346 OP_TXHASH, which allows scripts to selectively hash different transaction fields using a bitfield selector.

The BIP446/BIP448 authors argue for a minimal approach: start with a simple, well-understood primitive that solves known problems. If future use cases justify more complexity, Taproot provides upgrade hooks to add capabilities later.

Authors and status

Greg Sanders is a Bitcoin Core contributor at Blockstream, known for work on LN-Symmetry, ephemeral anchors, and covenant research. Antoine Poinsot is a Bitcoin protocol developer who contributed to Miniscript and vault architectures. Steven Roose has worked on Blockstream’s Elements platform, which powers the Liquid Network.

BIP446 was assigned its number on February 6, 2026. BIP448 was assigned on March 11, 2026. Both are currently in Draft status with a reference implementation and comprehensive test vectors available.

The proposals do not specify an activation mechanism or timeline. Community discussion will likely focus on the annex commitment trade-offs, whether to activate the bundle together or separately, and how this compares to OP_CHECKTEMPLATEVERIFY.

Covenant proposals have been debated for years without reaching consensus. Having a formal specification with assigned BIP numbers, test vectors, and implementation-ready code is a significant step forward for Lightning developers, Ark researchers, and Layer 2 builders.

Sources

Data as of March 19, 2026.