This document proposes a new operation for Tapscript: OP_TEMPLATEHASH. It introduces the ability to\npush on the stack a hash of the transaction spending an output.
OP_TEMPLATEHASH can be used to commit to the transaction spending an output[^commit-exact-tx]. This capability\ncan replace the use of pre-signed transactions in second-layer protocols. By reducing interactivity it makes such\nprotocols simpler, safer, and sometimes notably more efficient. For instance it can remove the need to share HTLC\nsignatures in the Lightning Network protocol's commitment_signed message[^ln-second-stage], make\nreceiving an Ark "VTXO" non-interactive, and reduces roundtrips in the implementation\nof LN-Symmetry. It is also a significant optimisation for Discreet Log Contracts.
OP_TEMPLATEHASH redefines OP_SUCCESS206 (0xce) in the Tapscript execution context with further restrictions.
Upon execution of the opcode, the template hash of the transaction in context is pushed onto the stack as defined below,\nand script execution continues.
\nThe template hash uses a tagged hash as introduced by BIP340 and BIP341. We use a new tag\nfor this purpose: TemplateHash.
\nThe template hash re-uses the sha_sequences, sha_outputs and sha_annex pre-computed transaction data introduced in\nBIP341. Numerical values in 4-byte are encoded in little-endian.
\nThe template hash is the hashTemplateHash of the following transaction fields concatenated:
\nCTxOut format, as per BIP341.The template hash follows BIP341's signature message format, with minimal necessary deviations. This reuses a\ntried-and-proven approach to hashed messages, and importantly makes it possible to reuse the pre-computed subfields\nintroduced by BIP341 to prevent quadratic hashing. Besides the hash tags, this results in at most 109 bytes being hashed\nupon execution of the operation[^hashed-msg-max-size]. This is strictly less hashing than is necessary for other\nexisting operations.
\nThe specific fields from the BIP341 signature message that are ommitted when computing the template hash are the\nfollowing:
\nOP_TEMPLATEHASH is fixed, so there\nis no need for a mechanism to modify the hash composition.OP_TEMPLATEHASH can be used as a building block for rebindable\nsignatures, the utility of committing to spent amounts but not spent scriptpubkeys is\nlimited. Still for rebindable signatures, committing to spent amounts can be justified\nas defense-in-depth against implementation mistakes[^commit-spent-amounts]. However, the lack of flexibility this\nintroduces also makes it harder to recover from a mistake in committing to the next\ntransaction[^no-commit-other-coins]. Furthermore, committing to all spent amounts also makes overcommitting funds to\nsuch a script result in the output being forever unspendable instead of the excess just going to fees at spend time.The design of OP_TEMPLATEHASH was inspired by the design of BIP119 OP_CHECKTEMPLATEVERIFY but differs in\nseveral important ways.
First of all, OP_TEMPLATEHASH is only defined for Tapscript, as modifying legacy Script comes with an unnecessarily\nincreased risk surface. In addition, sticking to Tapscript allows leveraging more powerful upgrade hooks (OP_SUCCESSs\ninstead of OP_NOPs) which make it possible to push the template hash on the stack instead of being constrained to\nstrict assertions with no stack modification. Pushing the template hash on the stack substantially improves the\nefficiency of using OP_TEMPLATEHASH as a building block for rebindable signatures.
Unlike OP_TEMPLATEHASH, OP_CHECKTEMPLATEVERIFY also commits to the scriptSig of all inputs of the spending\ntransaction. OP_CHECKTEMPLATEVERIFY gives txid stability when the committed spending transaction has a single input,\nand when the scriptSig of this single input has been committed by the hash.\nTaproot scriptSigs must be empty and therefore under the single input case OP_TEMPLATEHASH has no requirement\nto commit to scriptSigs to achieve txid stability.
Finally, BIP119 OP_CHECKTEMPLATEVERIFY does not commit to the Taproot annex (or its absence). OP_TEMPLATEHASH does.\nDeviating from other operations which do commit to the annex would be unnecessary and surprising. Committing to the\nannex also makes usage of OP_TEMPLATEHASH forward compatible with potential future meaning that it could be given. Not\ncommitting to it would also prevent using OP_TEMPLATEHASH in conjunction with annex-based proof of publication\ntechniques unless additional signatures are included, as used for instance in the LN-Symmetry demo.
Programmable transaction introspection capabilities have been proposed as an alternative to a primitive which only\nallows committing to the exact next transaction. It remains to be shown that these more flexible capabilities do\nenable important use cases which justify each proposed change's specific semantics and implementation complexity. It\nhas been suggested that the new primitive should have its own upgrade hook from which to softfork in additional\nconsensus meaning for more flexible introspection at some future point. We have not done so due to the fact that Taproot\nand Tapscript already presents plentiful upgrade hooks for the future.
\nThis document proposes to give meaning to a Tapscript OP_SUCCESS operation. The presence of an OP_SUCCESS in a\nTapscript would previously make it unconditionally succeed. This proposal therefore only tightens the block validation\nrules: there is no block that is valid under the rules proposed in this BIP but not under the existing Bitcoin consensus\nrules. As a consequence these changes are backward-compatible with non-upgraded node software. That said, the authors\nstrongly encourage node operators to upgrade in order to fully validate all consensus rules.
For development and testing purposes, we provide a collection of test vectors. The test\nvectors are separated into two JSON files. The first one is a short list of\nsimple test cases exercising the various fields of a transaction committed to when using OP_TEMPLATEHASH. The second\none is a more exhaustive suite of tests exercising OP_TEMPLATEHASH\nunder a large number of different conditions. It reuses the Bitcoin Core Taproot test framework\nintroduced with the implementation of BIP341. Format details and usage demonstration are available\nhere.
Credit to Jeremy Rubin for his leadership and perseverance in defending how a simple primitive which\nallows committing to the entire spending transaction is useful for reducing\ninteractivity in second layer protocols. This BIP draws on the design of BIP119 and is\nheavily inspired by his exploration of the potential uses for such a primitive.
\nThis document is licensed under the Creative Commons CC0 1.0 Universal license.
\n[^ln-second-stage]: Second-stage HTLC transactions are currently enforced through a 2-of-2 multisig between the channel\npartners. Committing to the HTLC transaction directly in the commitment transaction's HTLC output is a drop-in\nreplacement for the multisig, which has the advantage of not requiring Lightning nodes to transmit and store signatures\nfor every HTLC at every state it is still active for.\n[^commit-exact-tx]: All the transaction's fields are committed to except the inputs' prevout. This means the output must\nbe spent by this exact transaction, although the other spent outputs may vary.\n[^no-commit-other-coins]: It is possible to commit to an underfunded transaction to spend a coin. If the transaction\ncommits to more than one input, it is possible to recover from the mistake by creating a separate coin of an appropriate\nvalue and spending it along with the encumbered coin. Committing to other inputs this transaction must spend or their\ninput removes the ability to recover from such a mistake.\n[^commit-spent-amounts]: Adding commitments to the spent amounts may offer extra protection when reusing a public key\npreviously associate with a rebindable signature. See BIP118's rationale for more about this.\n[^hashed-msg-max-size]: If no annex is committed, 77 bytes are hashed: 72 bytes of transaction data + 5 bytes of data\nabout this input. Committing to an annex adds 32 additional bytes of data about this input, bringing the total to 109.
\n","toc":[{"id":"abstract","title":"Abstract","level":2},{"id":"motivation","title":"Motivation","level":2},{"id":"specification","title":"Specification","level":2},{"id":"rationale","title":"Rationale","level":2},{"id":"backward-compatibility","title":"Backward compatibility","level":2},{"id":"implementation","title":"Implementation","level":2},{"id":"test-vectors","title":"Test Vectors","level":2},{"id":"acknowledgements","title":"Acknowledgements","level":2},{"id":"copyright","title":"Copyright","level":2}],"history":{"totalCommits":1,"firstCommit":"2026-03-17T16:01:23-04:00","lastUpdated":"2026-03-17T16:01:23-04:00","events":[{"sha":"2778442c21cef2290ae3e0c843d9f3179aa1cdd0","date":"2026-03-17T16:01:23-04:00","author":"Gregory Sanders","message":"Add BIP446: OP_TEMPLATEHASH, BIP448: Taproot-native (Re)bindable Transactions (#1974)","url":"https://github.com/bitcoin/bips/commit/2778442c21cef2290ae3e0c843d9f3179aa1cdd0","kind":"edit"}]}}