Bitcoin’s MATT proposal could carry contract state across transactions

A proposed Bitcoin scripting change, OP_CHECKCONTRACTVERIFY, would allow contract data commitments to pass from one transaction to the next while keeping funds subject to programmed spending rules. The mechanism underpins MATT, an approach to stateful contracts highlighted in Cointelegraph’s Bitcoin covenants series.

The central idea is that an unspent transaction output, or UTXO, could commit to both spending conditions and a changing contract state. When that output is spent, a script could check the committed data and require successor outputs to carry an allowed new state. This would connect successive transactions through enforceable rules rather than treating each payment as an isolated event.

The draft specification, BIP 443, describes how the commitment would fit into Bitcoin’s existing Taproot output structure. A cryptographic key adjustment commits to the data, with a further adjustment incorporating the tree of spending scripts. The output carries a commitment to the state, not necessarily the underlying information in readable form.

That distinction matters for storage and disclosure. According to the specification, the commitment does not enlarge the UTXO, and spending paths that do not need the data avoid the additional witness cost of revealing it. This does not make contract execution cost-free; it separates a compact commitment from information needed when a particular spending condition is exercised.

MATT stands for Merkleize All The Things, referring to its extensive use of Merkle trees to commit to collections of data. Its project documentation describes OP_CHECKCONTRACTVERIFY, together with OP_CAT, as a direct way to implement the approach. OP_CAT supplies data-concatenation functionality useful for constructing and checking those commitments.

One significant application is a fraud-proof protocol for computation performed outside Bitcoin. Rather than requiring the blockchain to repeat an entire calculation, participants could submit a committed result and challenge an incorrect claim. The contract would provide a procedure for resolving that challenge through transactions governed by its spending rules.

The experimental mattlab documentation illustrates how a dispute can narrow a computation trace to a step that Bitcoin Script can verify. It describes a challenge process whose transaction count grows logarithmically with the number of computational steps. The objective is to make a large computation disputable without reproducing its full execution onchain.

This would not turn Bitcoin Script itself into an unrestricted programming environment. MATT’s documentation explicitly distinguishes simple, verifiable state transitions from the potentially complex computations those transitions help adjudicate. The broader capability comes from arranging commitments and challenges around offchain work, not from requiring every Bitcoin node to execute that work directly.

Fraud proofs also introduce conditions that application designers must address. The project’s documentation identifies challenge periods, capital lockup and the need for participants to get challenge transactions confirmed without censorship. Those requirements mean a compact proof mechanism alone does not establish that a particular application is secure or practical.

OP_CHECKCONTRACTVERIFY remains a draft consensus proposal, not an activated Bitcoin capability. Its significance is as a proposed building block for carrying state and enforcing transitions, with broader uses dependent on accompanying functionality and contract design. Further implementation review and agreement on a consensus change would be necessary before these mechanisms could become part of Bitcoin’s live rules.