Cointelegraph Research released part five of its series on Bitcoin covenants, detailing a new framework called MATT (Merkleize All The Things) and the opcode OP_CHECKCONTRACTVERIFY (OP_CCV). The proposal aims to give Bitcoin the ability to carry mutable contract state across multiple transactions, a capability that standard Bitcoin scripts lack because each transaction is evaluated in isolation.

BTC / USD
Source: CoinGecko. Prices are indicative.

How MATT embeds state in Taproot keys

MATT builds on Taproot’s existing tweak mechanism, where a Taproot output’s public key Q is derived as Q = P + t·G, with P as the internal key and t a tagged hash of data to be committed. Instead of only committing a Merkle root of a script tree, MATT proposes to also embed contract state into the tweak. The state is hashed and included in the tweak, allowing the next output to carry forward a new state that is recomputed at spend time.

OP_CHECKCONTRACTVERIFY enforces state transitions

The core primitive for MATT is OP_CHECKCONTRACTVERIFY. According to the report, OP_CCV lets a script verify that a Taproot input or output key has been tweaked with a particular piece of state data. The opcode’s stack format is <data> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFY, with three operational modes: default (full input value moves to the designated output), deduct (only the output amount is moved, leaving remainder for other outputs), and ignore (verification without amount constraints). These modes preserve value while allowing separate fee inputs, avoiding the fund‑burn issues seen in earlier covenant designs such as OP_CTV or SIGHASH_ANYPREVOUT.

Extending expressiveness with OP_CAT

When OP_CHECKCONTRACTVERIFY is combined with OP_CAT, the framework can construct and verify Merkle proofs on‑chain. Two Merkle trees are associated with a Taproot output: the standard script tree and a separate state tree that stores intermediate computation steps. OP_CAT concatenates byte strings, enabling the script to rebuild a Merkle proof for the current state, compute the new root after a transition, and then use OP_CCV to force the next output to commit to that new root. This design supports fraud‑proof systems similar to optimistic rollups, where most computation occurs off‑chain and only disputed steps are posted on‑chain for verification.

What to watch next

The next steps for MATT will involve formal BIP proposals and community testing of OP_CHECKCONTRACTVERIFY implementations in Bitcoin Core. Watch for updates from the Bitcoin developer mailing list and any test‑net deployments that demonstrate stateful contracts, fraud‑proof vaults, or other use cases highlighted in the series.