比特币合约如何在一笔交易结束后，把更新过的信息交给下一笔交易？MATT（Merkleize All The Things）框架提出的路径，是把合约状态承诺写入Taproot输出，再用拟议操作码OP_CHECKCONTRACTVERIFY（OP_CCV）约束状态的传递。这为有状态合约、欺诈证明和金库提供了共同的技术基础，但相关能力仍属于提案设计。
状态延续的关键，是允许下一步动态生成
常规比特币脚本对每笔交易独立求值，本身不保存此前执行的记忆。所谓有状态合约，就是让信息能够跨交易延续，并随着合约执行而更新。这里的“记忆”并非脚本自行存储，而是由交易输出携带可供后续验证的状态承诺。
其他契约约束方案也能在一定程度上携带状态。例如，基于OP_CTV的Sapio可以用地址对应有限状态机中的状态，用交易完成状态切换。不过，这种方式更适合预先安排好的路径，难以简洁地表达数值运算。
MATT的重要区别在于，花费时可以根据当前数据计算新状态，再将其承诺写入下一笔输出。我们的判断是，这一变化的意义在于把合约从“选择既定分支”推进到“验证动态更新”。但动态更新仍须服从脚本规则，并不意味着能够在链上无条件执行任意计算。
OP_CCV同时约束状态承诺与资金分配
Taproot允许通过公钥微调承诺额外信息，通常用于承诺包含不同花费条件的脚本树。OP_CCV方案在内部公钥上先加入合约状态哈希的微调，再叠加标准Taproot脚本树微调，使最终输出公钥同时承诺花费条件与当前状态。
OP_CCV可检查指定Taproot输入或输出的公钥，是否承诺了给定状态数据。脚本读取见证栈中的数据并完成计算后，可要求指定输出正确承诺更新后的状态。状态因此不是附在交易旁边的说明，而是后续花费必须满足的约束。
资金分配则取决于检查模式：默认模式将输入未花费交易输出（UTXO）的全部BTC金额分配给指定输出；扣减模式仅分配与该输出金额相等的部分，余款可供其他输出使用；忽略模式检查脚本和数据承诺，但不约束金额。此外，方案还设有独立的输入检查模式。
默认和扣减模式旨在保持受检查输出之间的价值，手续费须由单独输入承担，并可配套找零输出。这把合约内资金的状态转换与手续费支付分开，为动态调整手续费和部分金库取款留下空间，缓解预签名交易通常提前固定金额的限制。
这种灵活性也有明确边界：忽略模式本身不提供金额约束。评估具体合约时，需要同时检查状态如何更新、资金如何分配；状态承诺有效，并不自动等于全部资金都按预期受到保护。
加入OP_CAT后，争议可缩小到单个计算步骤
OP_CAT提供字节拼接能力，与OP_CCV结合后，可在脚本中构造和验证默克尔证明。此时需要区分两棵树：Taproot脚本树记录花费条件，另一棵独立状态树记录合约数据，例如计算过程中的中间步骤。
脚本可以针对当前状态树根验证证明，计算状态转换后的新树根，再用OP_CCV要求下一输出承诺该树根。由此，较长计算可在链下执行并提交承诺；出现争议时，仅把有争议的步骤及其树中路径提交链上验证，并据此执行相应惩罚条件。
这一机制的直接影响，是改变链上验证工作的范围，而不是让链上重新执行整段计算。它要求计算先被表达为二进制电路或等效的逐步表示，才能纳入默克尔树。按该设计，状态一致性的约束可不再依赖BitVM所使用的Lamport一次性签名和预签名交易图。
因此，欺诈证明能力不能只看操作码是否能验证树根，还要看具体应用是否把计算步骤、争议证据和惩罚条件衔接完整。能够承诺某段计算，与能够有效裁定争议，是两个需要分别验证的环节。
金库可共享底层能力，落地仍取决于具体规则
OP_CCV单独即可用于构建金库；加入OP_CAT后，设计上可实现与OP_VAULT提案基本相当的完整金库功能。OP_VAULT作者James O’Beirne也将OP_CCV评价为更通用、稳健，并可实质替代其早期提案的设计。这是对方案的技术评价，并不代表功能已经部署。
从这些安排看，MATT值得注意的地方，是状态验证、资金分配和争议处理能够建立在可组合的底层能力之上。金库与欺诈证明虽然用途不同，却都需要回答同一个问题：当前状态是否合法，以及下一步允许把状态和资金交给谁。
具体应用仍须分别审视金额检查模式、手续费输入安排，以及链下计算能否被拆解为可验证步骤。后续判断应围绕提案规则如何确定、相关操作码是否获得采用，以及实现能否完整兑现这些约束展开，不能把设计上的可表达性直接视为实际可用性。
