Bitcoin Covenants Part 5 Explains How MATT and OP_CHECKCONTRACTVERIFY Carry State Across Transactions

Part 5 of Cointelegraph Research’s Bitcoin covenant series examines how MATT and OP_CHECKCONTRACTVERIFY (OP_CCV) could let Bitcoin contracts carry state across transactions. According to Cointelegraph, MATT, or Merkleize All The Things, is a framework for stateful contracts and scalable fraud proofs, allowing contract information to be updated and passed forward as transactions occur. Standard Bitcoin scripts evaluate each transaction independently and do not retain information from earlier executions. Existing covenant designs can represent state through a finite set of addresses and transactions, but this approach does not provide an elegant way to perform numerical logic. MATT instead allows data committed to an output to be computed when it is spent and embedded in the next output, enabling a new state to be derived dynamically. Its proposed OP_CCV implementation builds on Taproot, whose output key can commit to additional data. MATT uses that mechanism to commit to contract state alongside the spending conditions, with the blockchain checking that each transition is valid rather than encoding all computation directly in script. OP_CCV allows a script to check that a Taproot input or output key commits to specified state data, then require an updated state to be committed to a designated next output. Its modes determine how the input’s bitcoin value is handled: default assigns the full amount to the checked output, deduct assigns the output amount while leaving a remainder available for other outputs, and ignore checks the script and data commitment without restricting the amount. Since default and deduct preserve value, separate inputs can cover transaction fees. Combined with OP_CAT, which enables byte concatenation in Script, OP_CCV could verify Merkle proofs, update a state-tree root and enforce that the next output commits to the new root. That could support fraud-proof systems where computation runs off-chain and only a disputed step is checked on-chain, without BitVM’s reliance on Lamport one-time signatures and presigned transaction graphs for state consistency. The combination could also enable more fully featured vaults; the article says OP_CCV alone can implement vaults, while OP_CCV and OP_CAT could provide functionality comparable to OP_VAULT. The series’ next article will examine application-specific proposals including OP_VAULT, OP_UNVAULT and OP_EVICT.