OP_CHECKCONTRACTVERIFY (CCV)

What Is OP_CHECKCONTRACTVERIFY?

OP_CHECKCONTRACTVERIFY (commonly abbreviated OP_CCV) is a proposed Bitcoin opcode that would allow scripts to verify that a spending transaction's outputs commit to specific data embedded in a Taproot output. By enforcing constraints on what the next UTXO must look like, CCV enables state-carrying UTXOs where each spend can read, update, and forward embedded state to the next output.

The opcode was authored by Salvatore Ingala as part of the MATT (Merklize All The Things) research framework. MATT explored how adding a small number of opcodes to Bitcoin Script could enable arbitrary computation verification through fraud proofs and Merkle-committed state machines. BIP 443 distills those ideas into a single, practical opcode that reuses the OP_SUCCESS187 (0xbb) slot in tapscript.

As of late 2026, BIP 443 remains a draft proposal. It requires a soft fork for activation and has no confirmed activation timeline. A prototype implementation exists in a fork of Bitcoin Inquisition for testing on signet.

How It Works

CCV operates within tapscript execution. It reads five elements from the stack, each constraining a different aspect of the spending transaction's output:

<data> <index> <pk> <taptree> <flags>

• data: an arbitrary-length byte string that gets committed into the output via the Taproot tweak. This is the "state" the UTXO carries forward.
• index: which output of the spending transaction to check. A value of -1 means the opcode checks the input rather than an output.
• pk: the internal public key required for the target P2TR output. An empty value inherits the current input's internal key.
• taptree: specifies the taptree structure that the target output must contain. An empty value means the current script's tapleaf is carried forward.
• flags: a mode byte controlling behavior. Currently defined modes select between checking an input or an output. Undefined flag values make the opcode succeed immediately, reserving them for future soft-fork extensions.

The Verification Process

When CCV executes during script validation, it performs a deferred check rather than an immediate one. The opcode records its constraints (target output index, required key, required taptree, required data) and the transaction validator enforces them after all scripts have been evaluated. This deferred model allows multiple CCV invocations across different inputs to reference the same output, with their constraints combined.

1. The script pushes the five arguments onto the stack and invokes OP_CCV
2. The opcode records the constraint: "output at index N must be a P2TR output with internal key pk, tweaked with data, using taptree T"
3. After all input scripts execute, the validator constructs the expected output script from the recorded constraints
4. If the actual output matches, the transaction is valid. Otherwise, validation fails.

Amount Preservation

CCV includes a deferred amount-checking mechanism inspired by OP_VAULT's design. When multiple inputs use CCV to point at the same output, their amounts are summed and compared against the output's value as a lower bound. This prevents funds from being silently drained when spending a covenant-locked UTXO. The check can be disabled with a flag for cases where exact amount control is not needed or is handled by other means (such as a signature).

One noted limitation: the deferred amount check works well for consolidation (many inputs to one output) and preservation (one input, one output), but it does not natively support arbitrary splitting of amounts across outputs.CoinPool-style constructions that split balances among participants may need additional introspection capabilities or complementary opcodes like OP_TXHASH to fully constrain amounts.

Example: Enforcing a Vault Trigger

A simplified vault construction using CCV might define a tapscript leaf like this:

# Vault trigger script (simplified pseudocode)
# Requires the spending tx to create an output
# that commits to a recovery path with a timelock

<recovery_taptree>   # taptree with recovery + delayed-withdrawal leaves
<vault_internal_key> # the vault's internal key
0                    # output index 0
<withdrawal_data>    # committed data (destination, amount hash)
CCV_FLAGS            # flags byte
OP_CHECKCONTRACTVERIFY

This script enforces that the first output of any spending transaction must be a P2TR output with the specified internal key, taptree, and committed data. The recovery taptree would include a time-locked withdrawal leaf and an immediate recovery leaf, replicating OP_VAULT's two-step withdrawal pattern using general-purpose covenant logic.

Why It Replaced OP_VAULT

OP_VAULT (BIP 345), authored by James O'Beirne, introduced two purpose-built opcodes for time-delayed recovery vaults. In May 2025, O'Beirne withdrew BIP 345 in favor of CCV, stating that OP_CCV is a more general version of the vault design.

The key technical difference: OP_VAULT could only swap out one tapleaf when triggered, while CCV can replace the entire taptree structure. This makes CCV strictly more flexible for vault architectures while also enabling entirely different contract types. Community analysis on Delving Bitcoin concluded that there is virtually nothing you can build with OP_VAULT that you cannot also build with CCV, and the MEV concerns are essentially identical between the two approaches.

For a deeper look at vault designs and the OP_VAULT proposal, see BIP-345 OP_VAULT: Time-Delayed Recovery Vaults.

Use Cases

Vaults

Bitcoin vaults enforce a time-delayed withdrawal process: when funds are spent, they first move to an intermediate UTXO with a timelock. During the delay period, a recovery key can claw back the funds. CCV enables this pattern by constraining the spending transaction's output to commit to a specific taptree containing both the delayed-withdrawal path and the recovery path. For a broader overview, see Bitcoin Covenants Explained.

CoinPools

CoinPools allow multiple users to share ownership of a single UTXO, each maintaining a verifiable balance within the pool. CCV can enforce that when a participant exits, the remaining pool UTXO correctly carries forward the updated state (reduced balances, modified participant set). The data commitment tracks the Merkle root of all participant balances.

Timeout Trees

Timeout Trees are tree-structured transaction arrangements where leaves expire at a predetermined time. CCV can constrain how the tree unfolds: each node in the tree commits to its children's structure via the data field, ensuring that intermediate states cannot be manipulated by any single participant.

Ark and VTXO Trees

The Ark protocol uses virtual UTXOs (VTXOs) organized in tree structures managed by an Ark service provider. CCV could enforce the correct construction of these VTXO trees at the consensus level, reducing trust assumptions. Each tree node would commit to its children via the Taproot data tweak, and CCV would verify that any unilateral exit correctly reveals the expected branch.

General State Machines

Combined with OP_CAT for data manipulation, CCV can express arbitrary state machines on Bitcoin. Ingala has stated that the full generality of the MATT framework, including fraud proofs for off-chain computation verification, requires only OP_CHECKCONTRACTVERIFY and OP_CAT. This could enable optimistic execution of complex contracts where disputes are settled on-chain through bisection-style fraud proofs.

Comparison with Other Covenant Proposals

CCV is one of several competing covenant proposals for Bitcoin. Each takes a different approach to constraining how UTXOs can be spent:

For a detailed comparison of these proposals and their tradeoffs, see Spark's Bitcoin Covenant Proposals Compared tool.

Risks and Considerations

Activation Uncertainty

BIP 443 is a draft with no activation timeline. Bitcoin's consensus change process is deliberately conservative, and no covenant proposal has been activated on mainnet as of late 2026. Protocols that depend on CCV cannot launch on mainnet until a soft fork is successfully deployed. For context on the covenant activation landscape, see Bitcoin Covenant Activation: The Path Forward.

Amount Introspection Limitations

The deferred amount check provides a lower-bound guarantee but cannot enforce exact output amounts or arbitrary splits. Protocols requiring precise amount distribution (like CoinPool exits that divide balances among participants) may need complementary opcodes or signature-based enforcement. This is an active area of research and discussion on the bitcoin-dev mailing list.

Complexity of Recursive Covenants

CCV enables recursive covenants: UTXOs that constrain their successors, which in turn constrain their successors, indefinitely. While powerful, recursive covenants raise concerns about creating "poisoned" UTXOs that can never be freely spent, or about enabling MEV-style extraction in Bitcoin. These concerns are shared with other recursive covenant proposals and are not unique to CCV.

Interaction with Existing Opcodes

CCV is designed to compose with existing tapscript opcodes and future proposals. Its full potential depends on complementary opcodes like OP_CAT for data manipulation and potentially OP_TXHASH for transaction introspection. The optimal combination of opcodes remains an open design question in the Bitcoin development community.

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.