Bitcoin covenants are increasingly moving from theoretical proposals to more concrete mechanisms, and Cointelegraph Research’s latest installment digs into what that evolution could look like when state is carried across transactions. The focus of Part 5 is MATT (Merkleize All The Things), a smart contract framework aimed at enabling stateful Bitcoin contracts and scalable fraud proofs.

Rather than trying to express computation directly through Bitcoin Script alone, MATT’s core idea is to commit contract state into the cryptographic structure of Taproot outputs—then verify that the next transaction updates that state correctly. The mechanism depends on OP_CHECKCONTRACTVERIFY (OP_CCV), with additional flexibility gained when paired with OP_CAT.

Key takeaways

MATT treats contract state as something that must be cryptographically committed in each Taproot output, allowing validation of state transitions on-chain.
OP_CCV enables state-carrying UTXOs by allowing scripts to require that an output key has been tweaked to commit to specified state data.
Combining OP_CCV with OP_CAT makes Merkle proofs feasible on-chain, supporting more advanced fraud-proof designs.
The framework can also strengthen vault-like behavior, with the OP_CCV approach characterized as more general than earlier vault proposals.

From Taproot commitments to contract state

To understand MATT, it helps to start with how Taproot commits data. Under Taproot, each output has an internal key that can be tweaked to include additional committed information. Formally, the tweaked key is expressed as Q = P + t·G, where P is the internal key, G is the secp256k1 generator, and t is a tagged hash that depends on both the internal key and the committed data. This data commitment can include the Merkle root of the Taproot script tree that hides alternative spending paths.

MATT leverages this same tweak mechanism, but uses it to commit not only to spending conditions (the Taproot tree) but also to the current state of the contract. The important shift is that verification focuses on checking that each step in a state transition is valid, while the actual state evolution can be derived dynamically at spend time and then re-embedded into the next output.

Cointelegraph Research frames the approach as a way to avoid a common limitation in covenant designs: when contracts are expressed purely as state machines whose transitions are chosen from a fixed set, it can be difficult to implement numerical logic or other computations elegantly. MATT aims to close that gap by letting each spend compute the next state and then enforce that the resulting output commits to it.

OP_CCV: committing state into the next output key

The most direct and specified route to realizing MATT, according to the research piece, uses OP_CHECKCONTRACTVERIFY. The opcode is described as a primitive that makes state-carrying UTXOs feasible within Taproot by allowing a script to verify that a Taproot input or output key has been tweaked to commit to a particular state value.

In the described flow, the internal key is first tweaked with a hash of the contract’s current state, and then the standard Taproot taptree tweak is applied on top. The resulting output key therefore commits to both:

the Taproot spending conditions (the tapscript set), and
the contract’s current state.

OP_CCV can then enforce state transition rules by inspecting state data provided on the witness stack, performing computations over it, and requiring that the updated state is re-committed in a specified output. In other words, the witness carries the claimed state and transition, while the opcode ensures the transaction actually produces the correct next commitment on-chain.

The research notes that OP_CCV supports multiple amount-checking modes, each affecting how value semantics work for the checked outputs:

Default mode assigns the full BTC value of the input UTXO to the specified output.
Deduct mode assigns only the output amount, leaving the remainder available for additional outputs.
Ignore mode verifies script and data commitments without constraining the amount.

A key operational detail is that transaction fees must be paid using separate fee-paying inputs when default or deduct modes are used. The research suggests adding a dedicated fee input and a change output to the transaction so the covenant constraints don’t accidentally “burn” funds—an issue attributed to more primitive covenant patterns such as OP_CTV or SIGHASH_ANYPREVOUT.

This fee-handling approach is also positioned as a response to a broader limitation in presigned-transaction-style covenants, where amounts may be fixed up front. Those designs may struggle to adapt to dynamic fee adjustments or partial unvault behavior, whereas the MATT-style framework is described as more flexible in practice.

OP_CCV plus OP_CAT: Merkle proofs and fraud-proof architecture

While OP_CCV provides the commitment and enforcement backbone, Cointelegraph Research highlights that the MATT framework becomes even more expressive when OP_CCAT is added. OP_CAT enables byte concatenation in Script, which can be used to construct and verify Merkle proofs on-chain.

In the proposed arrangement, a Taproot output is associated with two related Merkle structures:

the usual Taproot script tree (taptree) that contains spending conditions, and
a separate state tree whose leaves represent contract data such as intermediate computation steps.

Using an OP_CCV + OP_CAT script, the system can verify a Merkle proof against the current state root, compute the updated root for the next step, and then compel the next output to commit to that new root via OP_CCV. The practical implication is that fraud-proof systems can be built in a way that doesn’t require every step of a long off-chain computation to be posted on-chain.

Cointelegraph Research connects this design to fraud-proof architectures with slashing, where a computation is run off-chain and challengers only need to reveal the specific disputed step—along with its proof path—rather than the entire trace. The piece draws parallels to “optimistic rollups” on other blockchain systems, where on-chain verification is triggered only when someone challenges.

It also notes that fraud proofs generally require the computation to be compiled into a binary circuit or equivalent step-by-step representation that can be committed in a Merkle tree. In that context, OP_CCV + OP_CAT is positioned as potentially reducing reliance on the Lamport one-time signature mechanisms and pre-signed transaction graphs that BitVM uses to enforce state consistency.

Vault implications: a more general design than earlier proposals

Beyond fraud proofs, the research piece argues that OP_CCV has important implications for vault-like contract designs. It states that OP_CCV alone can implement vault behavior, and that coupling OP_CCV with OP_CAT enables “fully featured” vaults that are described as essentially equivalent to the functionality proposed by OP_VAULT.

Cointelegraph Research references commentary from James O’Beirne, author of OP_VAULT, who is quoted (via the linked discussion) as noting that OP_CCV presents a more general and robust design that effectively supersedes the earlier proposal. The point isn’t that vaults disappear, but that a more flexible primitive for committing and enforcing state transitions could unify multiple use cases under a broader covenant toolset.

The series’ next installment, per the research piece, is expected to shift from general covenant building blocks toward application-specific opcodes such as OP_VAULT, OP_UNVAULT, and OP_EVICT—each designed to solve a specific problem rather than provide broad programmability.

For investors, developers, and protocol designers, the immediate watch item is how these primitives—especially OP_CCV and its interaction with OP_CAT—translate into implementable covenant patterns with clear fee semantics, verifiable state transitions, and practical on-chain verification costs; the remaining uncertainty is how these designs will be shaped by the ongoing evolution of Bitcoin’s scripting capabilities.