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

This is Part 5 in the technical article series about Bitcoin covenants by Cointelegraph Research. To read the previous article click here.

MATT (Merkleize All The Things) is a smart contract framework for Bitcoin that enables stateful contracts and scalable fraud proofs. A stateful contract carries information forward across multiple transactions and can update this information as the contract evolves. Standard Bitcoin scripts do not provide this capability, because each transaction is evaluated independently with no memory of previous executions.

Every covenant proposal allows state-carrying UTXOs to an extent, as illustrated by scripting languages such as Sapio, which builds on OP_CTV. This works by using addresses to represent a finite state automaton, where transactions function as the state transitions. However, there is no way to elegantly implement numerical logic in this paradigm, a gap filled by MATT, and in particular its proposed implementation through OP_CCV. Because MATT allows committed data to be computed at spend time and re-embedded into the next output, each spend can derive a new state dynamically, instead of choosing from a predetermined set of states.

How OP_CCV commits state into a Taproot key

To understand the MATT proposal, it is useful to first review how Taproot commits data through public keys. Every Taproot output contains a base public key, called the internal key, which can be cryptographically modified or “tweaked” to commit to extra information. Formally, the tweaked public key is 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 regular Taproot output, this commitment typically encodes the Merkle root of a taptree, which contains hidden spending paths. MATT builds on this mechanism to also embed contract state into the key. Instead of embedding complex logic directly in Bitcoin’s scripting language, MATT encodes computation as a sequence of state commitments, and the chain verifies only that each state transition is valid.

MATT can be realized through different opcode combinations. The most direct and well-specified implementation relies on OP_CHECKCONTRACTVERIFY (OP_CCV). OP_CCV provides the primitive that makes state-carrying UTXOs feasible within Taproot. OP_CCV allows a script to verify that a Taproot input or output key has been tweaked to commit to a specific piece of state data. The internal key is first tweaked with a hash of the contract’s current state, and then Taproot’s standard taptree tweak is applied on top. The resulting output key therefore commits to both the tapscript (the set of spending conditions) and the current state of the contract.