Bitcoin Covenants Part 5: MATT and OP_CHECKCONTRACTVERIFY - How Bitcoin could carry state across transactions

OP_CCV embeds contract state directly into Taproot output keys and enforces valid state transitions onchain. This makes it possible to achieve stateful contracts and compact fraud proofs.

OP_CCV can then enforce what state is carried forward into the next output. It allows the script to inspect the state data provided on the witness stack, perform computations on it, and require that the resulting updated state is correctly re-committed in a specified output. This is how state transitions are enforced on-chain.

The stack format is: OP_CHECKCONTRACTVERIFY

Verification Modes

The opcode supports three modes for checking an output as well as a separate input mode.

• In default mode, the entire BTC value of the input UTXO is allocated to the specified output
• In deduct mode, only a portion equal to the output's amount is assigned, leaving the remainder available for further outputs
• In ignore mode, the script and data commitment are verified without constraining the amount

Because default and deduct modes are designed to preserve value across checked outputs, transaction fees must be paid through separate fee-paying inputs. A dedicated fee input and change output can be added to the transaction without conflicting with the covenant's constraints.

This prevents the accidental burning of funds that can occur in more primitive covenant implementations, such as OP_CTV or SIGHASH_ANYPREVOUT. It also addresses a major limitation of presigned-transaction-style covenants, which typically define amounts upfront and therefore cannot accommodate dynamic fee adjustments or partial unvaults.

Combining OP_CCV with OP_CAT

When OP_CCV is combined with OP_CAT, the full MATT framework becomes even more expressive. OP_CAT enables byte concatenation in Script, which makes it possible to construct and verify Merkle proofs directly on-chain.

Two distinct Merkle trees are associated with a Taproot output in such an arrangement.

• The first is the familiar Taproot script tree (the taptree), whose leaves are the contract's spending scripts.
• The second is a separate state tree, whose leaves are the contract's data, such as the intermediate steps of a computation.

The OP_CCV + OP_CAT script can verify a Merkle proof against the current state tree root, compute the updated root after a transition, and use OP_CCV to force the next output to commit to it.

This construction enables fraud-proof systems with a slashing condition in which a long computation is committed off-chain, and only the specific disputed step (with its path in the binary tree) needs to be revealed and verified on-chain.

Similar systems exist as optimistic rollups on other blockchain systems: the full computation runs off-chain, and the on-chain contract only intervenes when someone raises a challenge. Fraud proofs require that the computation be compiled down to a binary circuit or equivalent step-by-step representation that can be committed to in a Merkle tree.

OP_CCV + OP_CAT would avoid the need for the Lamport one-time signatures and pre-signed transaction graphs that BitVM relies on to enforce state consistency.

Implications for Vaults

Beyond fraud proofs, the OP_CCV and OP_CAT combination also has implications for vaults. OP_CCV alone can implement vaults, but when combined with OP_CAT, it allows fully featured vaults that are essentially equivalent to the functionality proposed by OP_VAULT.

As James O'Beirne, the author of OP_VAULT, has noted, OP_CCV represents a more general and robust design that effectively supersedes his earlier proposal.

In the next article in this series, we will move on from general covenant proposals to review application-specific opcodes such as OP_VAULT, OP_UNVAULT, and OP_EVICT. Each of the opcodes are designed to solve a specific problem rather than provide broad programmability.

Magazine: Bitcoin holders have received eCash - What can you do with it?