Transaction Introspection

What Is Transaction Introspection?

Transaction introspection is the ability for a Bitcoin script to examine the data of the transaction that is attempting to spend it. When a user creates a transaction that spends coins locked by a script, introspection allows that script to read the spending transaction's fields: its outputs, input amounts, version, locktime, and other structural data. The script can then enforce conditions based on what it sees.

Without introspection, a Bitcoin script can verify that a valid signature was provided and check timelock constraints, but it has no way to know where the coins are actually going. A script locked to a public key can confirm that the key's owner signed the transaction, but it cannot require that the transaction sends a specific amount to a specific address. This limitation is what prevents Bitcoin from supporting covenants: rules that restrict not just who can spend coins, but how and where they can be spent.

Transaction introspection closes this gap. By letting scripts read the spending transaction's structure, it becomes possible to enforce conditions like "this output must pay 0.5 BTC to address X" or "the transaction must have exactly two outputs." This is the key building block for vaults, congestion control, payment pools, and other advanced Bitcoin constructs.

How It Works

In Bitcoin, every transaction input references a previous output and provides a witness (signature data) to satisfy that output's spending conditions. The script interpreter evaluates the spending conditions using a stack-based virtual machine. Today, the interpreter can access only a narrow slice of transaction data during execution.

What Scripts Can See Today

Bitcoin's current opcodes provide two limited forms of introspection:

• OP_CHECKLOCKTIMEVERIFY (CLTV): reads the transaction's nLockTime field and requires it to be at or above a specified value. This enforces absolute timelocks.
• OP_CHECKSEQUENCEVERIFY (CSV): reads an input's nSequence field and enforces relative timelocks based on the number of blocks or seconds since the output was confirmed.

Signature verification with OP_CHECKSIG provides an indirect form of introspection. The opcode hashes certain transaction fields according to a SIGHASH flag and checks a signature against that hash. This commits the signer to a specific transaction structure, but the script itself never sees the individual fields. It only knows whether the signature is valid.

How New Opcodes Would Add Introspection

Several proposed opcodes would give scripts direct access to transaction fields. Each takes a different approach to the tradeoff between power and simplicity:

OP_CHECKTEMPLATEVERIFY (CTV, BIP 119) provides the narrowest form of introspection. It takes a 32-byte hash from the stack and compares it against a hash of a fixed set of the spending transaction's fields: version, locktime, input count, sequences hash, output count, outputs hash, and the input index. If the hash does not match, the script fails. CTV does not let the script choose which fields to inspect: it commits to all of them at once.

# CTV script: spending transaction must match this exact template
OP_CHECKTEMPLATEVERIFY
# The 32-byte hash on the stack commits to:
#   nVersion, nLockTime, scriptSigs hash (if non-segwit),
#   input count, sequences hash, output count, outputs hash,
#   input index

OP_TXHASH (BIP 346) takes a more flexible approach. It pops a TxFieldSelector from the stack: a variable-length byte sequence where each bit specifies which transaction fields to include in the hash. The opcode then pushes a 32-byte hash of the selected fields onto the stack. This allows scripts to commit to specific parts of a transaction while leaving others open. For example, a script could fix the outputs but leave the inputs flexible, allowing anyone to add fees.

# OP_TXHASH with a field selector
<txfield_selector> OP_TXHASH
# Pushes hash of selected fields onto the stack
# The selector bits can target:
#   version, locktime, inputs, outputs, amounts,
#   scriptPubKeys, sequences, annexes
# Individual inputs/outputs can be selected by index

OP_CAT (BIP 347) is not an introspection opcode by itself, but it enables introspection indirectly. OP_CAT concatenates two stack elements. When combined with OP_CHECKSIG or OP_CHECKSIGFROMSTACK, a script can reconstruct a transaction's signature hash from individual components, then verify it against a signature. This effectively lets the script inspect the transaction's fields by rebuilding and checking the hash piece by piece.

OP_CHECKSIGFROMSTACK (CSFS) verifies a signature against an arbitrary message on the stack, rather than against the transaction's built-in signature hash. When paired with OP_TXHASH or OP_CAT, CSFS enables scripts to validate that a specific party signed off on specific transaction fields, opening the door to delegated spending conditions and oracle-based contracts.

Comparing Introspection Approaches

The proposed opcodes span a spectrum from minimal to general-purpose introspection:

CTV is the most conservative: it commits to an entire transaction template and cannot be combined to create recursive covenants (where an output's script constrains its own future spending script). OP_TXHASH and OP_CAT are more expressive and can enable recursive covenants when combined with other opcodes, which is both their strength and the source of controversy.

For a detailed comparison, see the Bitcoin Covenant Proposals Compared tool and the Bitcoin Covenants Explained research article.

Bitcoin vs. Ethereum: Introspection Models

Ethereum's smart contracts have full introspection by default. A Solidity contract can read msg.value (the amount sent), msg.sender (the caller), block.number, and essentially any state in the system. Contracts can call other contracts, read their storage, and enforce arbitrary conditions on any transaction field.

Bitcoin takes a fundamentally different approach. Its script language is intentionally limited: no loops, no persistent state, and no access to external data. This design keeps validation fast and predictable, but it means every new introspection capability must be explicitly added through a consensus change (a soft fork).

The proposed Bitcoin introspection opcodes are narrowly scoped compared to Ethereum. Even OP_TXHASH, the most general proposal, only lets scripts read fields of the current transaction. There is no way to read other transactions, query the UTXO set, or access block data. This keeps Bitcoin's security model simpler: validators only need the transaction itself to verify spending conditions.

Use Cases

Transaction introspection unlocks several categories of applications that are impossible with Bitcoin's current script capabilities:

Vaults

A vault is a custody mechanism where spending requires a two-step process: first announce the withdrawal, then complete it after a delay. If the owner detects unauthorized access during the delay, they can claw back funds to a recovery address. Introspection makes this possible because the vault script needs to enforce that the spending transaction creates an output with the correct time-delayed script: something that requires reading the transaction's outputs.

Congestion Control

When block space is expensive, a single transaction can commit to a tree of future transactions using CTV hashes. Each leaf of the tree represents a payment to a final recipient. The payments expand on-chain only when fees drop. The initial transaction's script enforces the tree structure by requiring that its spending transaction match a specific template: a form of introspection.

Payment Pools and Shared UTXOs

Multiple users can share a single UTXO and exit individually without requiring all participants to sign. The shared UTXO's script uses introspection to enforce that exit transactions preserve the remaining participants' funds. Protocols like CoinPool and Ark rely on this pattern for scalable off-chain ownership.

Trustless Bridges and Layer 2 Protocols

Layer 2 systems benefit from introspection because settlement transactions can enforce specific output structures. For example, a bridge contract could require that withdrawal transactions send funds to specific addresses with specific amounts, reducing trust assumptions. The covenant activation path forward explores how these proposals could reshape Bitcoin's layer 2 landscape.

The Introspection Debate

Transaction introspection is one of the most actively debated topics in Bitcoin development. The core tension is between enabling new functionality and preserving Bitcoin's simplicity and security guarantees.

Arguments for Introspection

• Enables covenants, which unlock vaults, congestion control, payment pools, and more efficient layer 2 protocols
• Reduces trust assumptions in multi-party protocols by letting scripts enforce output structures without requiring all parties to be online
• Improves capital efficiency: shared UTXOs and batched expansions reduce the on-chain footprint per user
• Every proposed opcode has been designed with specific safety limits: CTV commits to a fixed template, OP_TXHASH is restricted to tapscript, and OP_CAT retains the existing 520-byte stack element limit

Arguments Against Introspection

• General-purpose introspection could enable recursive covenants, where a script permanently restricts how its coins can be spent across all future transactions, raising concerns about fungibility and censorship
• More expressive scripts increase the attack surface for MEV on Bitcoin: miners could extract value by reordering or inserting transactions that interact with covenant-locked outputs
• Complex introspection opcodes add implementation burden to Bitcoin Core and increase the risk of consensus bugs
• Some developers argue that Bitcoin's limited scripting is a feature, not a limitation, and that pushing programmability to higher layers is the safer path

For a deeper analysis of the OP_CAT side of this debate, see OP_CAT and the Great Covenant Debate.

Current Status

As of late 2026, none of the introspection proposals have been activated on Bitcoin mainnet. CTV (BIP 119) and OP_CAT (BIP 347) have the most community attention, with OP_CAT reaching "Complete" BIP status in March 2026 and accumulating over 74,000 test transactions on the Bitcoin Inquisition signet. OP_TXHASH (BIP 346) remains a draft BIP with a reference implementation and open Bitcoin Core pull request (#29050). A newer proposal, OP_TEMPLATEHASH (BIP 446), aims to be a Taproot-native successor to OP_TXHASH.

The activation path remains uncertain. Each proposal has vocal supporters and skeptics, and the community has not reached consensus on which form of introspection (if any) should be added first. The covenant activation path forward research article tracks the latest developments in this ongoing discussion.

Risks and Considerations

• No introspection opcode is live on Bitcoin mainnet: all proposals are in draft or review stages and require a soft fork to activate
• Recursive covenant risk: general-purpose introspection could create spending conditions that persist indefinitely, potentially reducing coin fungibility if certain UTXOs become "tainted" by restrictive scripts
• Implementation complexity: more powerful opcodes mean more potential for subtle consensus bugs, and Bitcoin's conservative development process reflects this concern
• MEV introduction: introspection-enabled scripts could create transaction ordering dependencies that incentivize miner extraction strategies currently absent from Bitcoin
• Ecosystem fragmentation: competing proposals with different tradeoffs have divided developer attention, and choosing the wrong approach could require difficult corrections later

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.