MATT's OP_CCV Proposal Could Give Bitcoin Stateful Contracts

Cointelegraph Research has published Part 5 of its technical series on Bitcoin covenants, detailing how a proposed opcode called OP_CHECKCONTRACTVERIFY (OP_CCV) could let Bitcoin transactions carry state forward across multiple spends. The article explains that OP_CCV is the most direct and well-specified implementation of a broader framework called MATT — Merkleize All The Things — which aims to bring stateful smart contracts and scalable fraud proofs to Bitcoin, according to Cointelegraph Research.

Event: What OP_CCV Actually Does

According to Cointelegraph Research, standard Bitcoin scripts evaluate each transaction independently, meaning there is no built-in memory of previous executions. Every existing covenant proposal allows state-carrying UTXOs to some extent — the piece cites Sapio, a scripting language built on OP_CTV, which represents contract states as a finite state automaton where transactions function as state transitions. But Cointelegraph Research notes this approach cannot elegantly implement numerical logic, a gap MATT is designed to fill.

The mechanism builds on how Taproot already commits data through public keys. Per the source text, every Taproot output contains an "internal key" that can be cryptographically tweaked to commit to extra information, formalized as Q = P + t·G, where P is the internal key, G is the generator of the secp256k1 elliptic curve, and t is a tagged hash of P and the committed data. In a standard Taproot output this commitment typically encodes the Merkle root of a taptree containing hidden spending paths. MATT extends this same mechanism to also embed contract state directly into the key, so that instead of writing complex logic into Bitcoin's scripting language, computation is encoded as a sequence of state commitments, with the chain verifying only that each state transition is valid.

Cointelegraph Research describes the OP_CCV stack format as: <data> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFY. The opcode supports three output-checking modes plus 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; and in ignore mode, the script and data commitment are verified without constraining the amount. Because default and deduct modes preserve value across checked outputs, the article notes that transaction fees must be paid through separate fee-paying inputs, with a dedicated fee input and change output addable without conflicting with the covenant's constraints.

Implications: Fraud Proofs, Vaults, and OP_CAT

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

The article explains that when OP_CCV is combined with OP_CAT — an opcode enabling byte concatenation in Script — the full MATT framework becomes more expressive, because OP_CAT makes it possible to construct and verify Merkle proofs directly on-chain. Two distinct Merkle trees would then be associated with a Taproot output: the familiar taptree, whose leaves are the contract's spending scripts, and a separate state tree, whose leaves are the contract's data, such as intermediate computation steps. According to Cointelegraph Research, an OP_CCV plus OP_CAT script could verify a Merkle proof against the current state tree root, compute the updated root after a transition, and force the next output to commit to it — enabling fraud-proof systems with a slashing condition where a long computation is committed off-chain and only the specific disputed step needs to be revealed and verified on-chain. The source draws a parallel to optimistic rollups on other blockchain systems, where full computation runs off-chain and the on-chain contract intervenes only on a challenge.

Cointelegraph Research further notes that fraud proofs under this design require computation to be compiled into a binary circuit or equivalent step-by-step representation committed to in a Merkle tree, and that OP_CCV combined with OP_CAT would avoid needing the Lamport one-time signatures and pre-signed transaction graphs that BitVM relies on to enforce state consistency. Beyond fraud proofs, the combination also has implications for vaults: OP_CCV alone can implement vaults, but paired with OP_CAT it allows fully featured vaults "essentially equivalent" to the functionality proposed by OP_VAULT. According to the article, James O'Beirne, the author of OP_VAULT, has noted that OP_CCV represents a more general and robust design that effectively supersedes his earlier proposal.

CoinHours analysis: why fee handling and vaults stand out

CoinHours analysis: Two practical points in the Cointelegraph Research explainer stand out. First, OP_CCV's value-preserving modes push fees into separate inputs, which the article says avoids the accidental burning of funds possible with OP_CTV or SIGHASH_ANYPREVOUT and allows dynamic fee adjustments and partial unvaults that presigned-transaction covenants cannot easily handle. Second, the vault comparison matters: if OP_CCV with OP_CAT can deliver vaults essentially equivalent to OP_VAULT, and OP_VAULT's own author regards OP_CCV as the more general design, the debate may centre on one general-purpose primitive rather than several single-use opcodes.

The fraud-proof design is also notable because, per the article, it would not need the Lamport one-time signatures and pre-signed transaction graphs that BitVM relies on. That is a design argument from the research piece, not evidence that the proposal will be adopted.

What Comes Next

Cointelegraph Research signals that its series will continue with a look at application-specific opcodes such as OP_VAULT, OP_UNVAULT, and OP_EVICT, each designed to solve a narrower problem rather than provide the broad programmability that MATT and OP_CCV target. For now, OP_CCV is a proposed opcode described in research, not an active network change. Readers tracking Bitcoin's scripting evolution can follow the next entries in this Cointelegraph Research series.

Further reading / context