BIP 443 (OP_CHECKCONTRACTVERIFY)

What Is BIP 443?

BIP 443 is a Bitcoin Improvement Proposal authored by Salvatore Ingala that defines a new tapscript opcode: OP_CHECKCONTRACTVERIFY (often abbreviated OP_CCV). The opcode allows a UTXO to carry a commitment to a 32-byte data hash alongside its script tree, and it lets scripts verify that spending transactions produce outputs with the correct combination of key, data, and script tree. In short, it makes Bitcoin outputs "stateful": they can carry data forward from one transaction to the next while enforcing rules on how that data changes.

The proposal grew out of the MATT (Merklize All The Things) framework, which explored how Merkle tree commitments in Taproot outputs could enable arbitrary state machines on Bitcoin. Rather than adding many specialized opcodes for different use cases, BIP 443 provides a single general-purpose primitive that can serve as a building block for vaults, shared UTXO protocols, and programmable spending conditions.

How It Works

OP_CCV builds on Taproot's existing structure. A standard P2TR output has an internal key and a Merkle tree of script leaves (the taptree). BIP 443 adds a data layer by tweaking the internal key with a hash of the committed data. The opcode then verifies that a target output in the spending transaction has the expected combination of naked key, data commitment, and taptree.

Stack Parameters

When executed in a tapscript, OP_CCV reads five values from the stack (bottom to top):

1. data: a 32-byte hash to commit in the target output (or empty for no data commitment)
2. index: which output (or input) to check, with -1 meaning "same index as this input"
3. pk: the naked public key for the target output (empty defaults to a NUMS point)
4. taptree: the script tree for the target output (empty preserves the current taptree)
5. mode: flags controlling amount verification and input/output selection

# Pseudocode: OP_CCV verification logic
# 1. Derive the target internal key
if data is not empty:
    target_internal_key = naked_key + H("CCV/data", naked_key || data) * G
else:
    target_internal_key = naked_key

# 2. Compute the taproot output key with taptree
target_output_key = taproot_tweak(target_internal_key, taptree)

# 3. Verify the spending transaction's output matches
assert tx.outputs[index].scriptPubKey == P2TR(target_output_key)

Mode Flags

The mode parameter controls how OP_CCV behaves:

• Default mode (0): checks that the target output amount is at least as large as the input amount, ensuring no value is lost
• CCV_FLAG_CHECK_INPUT (1): makes the index refer to a transaction input rather than an output, enabling introspection of the spending transaction's inputs
• CCV_FLAG_IGNORE_AMOUNT (2): skips the amount check entirely, useful when the data commitment matters but the amount does not
• CCV_FLAG_DEDUCT_AMOUNT (4): allows a portion of the input amount to be deducted, enabling partial withdrawals from a stateful UTXO

Because the default mode preserves the full input amount in the output, transaction fees must be paid exogenously: typically via an additional input or an ephemeral anchor output. This design keeps the state-carrying UTXO's value intact.

Key Path Spending

The data commitment does not make the UTXO any larger on chain. The committed data is folded into the internal key via a tweak, so the output looks like any other P2TR output. The key path spend remains available to anyone who holds the private key for the naked key and knows the data hash. This means cooperative settlement can bypass the script rules entirely, preserving efficiency for the common case.

Why BIP 345 (OP_VAULT) Was Withdrawn

BIP 345 proposed two opcodes, OP_VAULT and OP_VAULT_RECOVER, specifically designed for vault contracts. These opcodes enforced a two-step withdrawal pattern: a hot key triggers a time-delayed withdrawal, and a cold recovery key can claw funds back at any time during the delay.

In May 2025, BIP 345's author James O'Beirne withdrew the proposal, stating that OP_CHECKCONTRACTVERIFY is a more general version of the vault design. While OP_VAULT could only replace a single tapleaf during the trigger step, OP_CCV can replace multiple tapleaves at once, enabling more flexible vault architectures. O'Beirne confirmed that all OP_VAULT-style vault designs can still be constructed using OP_CCV, making the specialized opcodes redundant.

This consolidation reflects a broader pattern in covenant development: rather than adding many purpose-specific opcodes, the community has gravitated toward fewer general primitives that can serve multiple use cases. For deeper context on vault designs, see the BIP-345 OP_VAULT research article.

Use Cases

Vaults

The original motivating use case. A vault built with OP_CCV uses state-carrying UTXOs to enforce withdrawal delays. The UTXO's data commitment tracks the vault state (locked, triggering, or recovering), and the taptree encodes the allowed transitions. A hot key triggers withdrawals by moving the vault to a "triggering" state with a timelock. If no recovery action occurs before the timelock expires, the funds can be claimed. If unauthorized activity is detected, a recovery key sweeps everything to cold storage.

CoinPools and Shared UTXOs

CoinPools allow multiple users to share a single UTXO while each controlling their own balance. The pool's state (who owns what) is committed as data inside the UTXO. When a participant wants to withdraw, OP_CCV verifies that the spending transaction correctly updates the pool state and produces outputs reflecting the remaining participants' balances. This approach reduces on-chain footprint because many users can transact off-chain, touching the blockchain only when entering or exiting the pool.

Ark and Timeout Trees

Ark is an off-chain protocol that uses virtual UTXOs (vTXOs) organized in tree structures. OP_CCV enables the construction of Timeout Trees, where a shared UTXO branches into individual outputs through a Merkle tree of pre-committed transactions. Each leaf in the tree represents a participant's balance, and the tree can be unwound non-interactively if the Ark service provider goes offline. Without OP_CCV, these constructions require pre-signed transaction trees with inherent limitations around interactivity and state updates.

Channel Factories

Channel factories group multiple Lightning channels under a single on-chain UTXO. State-carrying UTXOs simplify the construction by allowing the factory's membership and channel allocations to be encoded as committed data. Participants can update the factory state cooperatively via key path spends and fall back to script path enforcement if cooperation breaks down.

BIP 443 vs. CTV (BIP 119)

CTV (OP_CHECKTEMPLATEVERIFY) and OP_CCV represent two different philosophies in covenant design:

CTV is intentionally minimal: it locks coins so they can only be spent in one specific pre-defined transaction. This simplicity makes it easier to analyze and review, but it cannot express state transitions or recursive spending conditions. OP_CCV trades simplicity for expressiveness: it can do everything CTV does (by committing to a specific output structure) and also supports stateful protocols that require data to evolve across multiple transactions.

The tradeoff is clear. CTV supporters argue that its narrow scope reduces the risk of introducing new attack surfaces. OP_CCV supporters counter that deploying a single general primitive avoids the need for multiple narrow soft forks over time. For a detailed comparison of covenant proposals, see the covenant activation path forward research article and the covenant proposals comparison tool.

Risks and Considerations

Activation Uncertainty

BIP 443 is a draft proposal with no activation timeline as of 2026. It would require a soft fork to deploy, and the Bitcoin community has not reached consensus on any covenant proposal. Protocols designed around OP_CCV cannot be used on mainnet until activation occurs, and there is no guarantee it will be the covenant primitive that ultimately activates.

Complexity and Review Surface

OP_CCV is significantly more complex than proposals like CTV. The mode flags, taptree manipulation, and key tweaking mechanics create a larger review surface. Bugs in consensus code can be catastrophic, so the additional expressiveness comes with proportionally higher scrutiny requirements. The reference implementation exists in Bitcoin Core PR #32080 and the Bitcoin Inquisition test fork, but neither has undergone the level of review needed for mainnet deployment.

Recursive Covenant Concerns

Unlike CTV, OP_CCV supports recursive covenants: outputs that can enforce the same (or similar) spending conditions indefinitely. Some developers worry that recursive covenants could enable permanent spending restrictions that undermine Bitcoin's fungibility. Proponents argue that the key path spend always allows cooperative override, preventing truly permanent locks unless all key holders agree to maintain them.

Incomplete Tooling

At the time of BIP 345's withdrawal, its author noted that some of the supporting documentation and tooling for OP_CCV had not yet emerged. Building protocols like CoinPools or Ark on OP_CCV requires not just the opcode but also descriptors, wallet support, and higher-level abstractions that remain under active development.

Why It Matters

BIP 443 represents one of the most significant proposals for expanding Bitcoin Script's capabilities since Taproot. If activated, it would unlock a class of protocols that are currently impossible or require trust assumptions on Bitcoin: shared UTXO schemes, stateful contracts, and non-interactive off-chain constructions. For Layer 2 protocols like Ark and for Bitcoin scaling more broadly, state-carrying UTXOs could reduce on-chain footprint while preserving self-custodial guarantees.

For builders working on Bitcoin infrastructure today, OP_CCV is worth understanding even before activation. Its design philosophy (general primitives over specialized opcodes) is shaping how the community evaluates all future covenant proposals. For more context on how covenant proposals fit into Bitcoin's scaling roadmap, see the research article on Bitcoin covenants.

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.