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 platform designed for Bitcoin that facilitates stateful agreements alongside scalable fraud proofs. A state-carrying contract maintains information forward across multiple sequential transactions and updates this data as the agreement develops. Traditional Bitcoin scripts lack this functionality because each transaction is processed independently without retaining any record of past executions.
Every covenant concept accommodates state-bearing UTXOs to a certain degree, as demonstrated by scripting environments such as Sapio, which builds upon OP_CTV. This mechanism functions by employing addresses to signify a finite state machine, where transactions act as the state transitions. Nevertheless, there is no straightforward method to execute arithmetic logic within this framework, a shortcoming resolved by MATT, specifically via its proposed deployment using OP_CCV. Because MATT permits committed information to be evaluated at the moment of spending and re-inserted into the subsequent output, every expenditure can dynamically calculate a fresh state rather than selecting from a predetermined collection of states.
How OP_CCV commits state into a Taproot key
To comprehend the MATT proposal, it helps to first examine how Taproot commits data utilizing public keys. Every Taproot output features a primary public key, designated as the internal key, which can be cryptographically adjusted or “tweaked” to bind additional data. Formally, the tweaked public key is Q = P + t·G, where P represents the internal key, G denotes the generator point of the secp256k1 elliptic curve, and t signifies a tagged hash combining P with the committed information.
Within a standard Taproot output, this commitment typically represents the Merkle root of a taptree, which encompasses concealed spending routes. MATT expands upon this procedure to also integrate contract state into the key. Instead of embedding intricate logic directly inside Bitcoin’s scripting language, MATT translates computation into a series of state commitments, leaving the network to verify exclusively that every state transition remains valid.
MATT can be implemented via different combinations of opcodes. The most direct and clearly defined realization depends on OP_CHECKCONTRACTVERIFY (OP_CCV). OP_CCV supplies the fundamental primitive that renders state-carrying UTXOs practical within Taproot. OP_CCV enables a script to confirm that a Taproot input or output key has undergone tweaking to commit toward a specific fragment of state data. The internal key is initially adjusted using a hash of the current contract state, after which Taproot’s standard taptree tweak is applied on top. Consequently, the resulting output key commits to both the tapscript (the collection of spending conditions) and the active state of the contract.
Following that, OP_CCV can mandate which state is carried forward into the subsequent output. It permits the script to inspect the state information supplied on the witness stack, execute calculations upon it, and demand that the resulting updated state is properly recommitted within a designated output. This mechanism enforces on-chain state transitions. The stack structure is:
<data> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFY
The opcode provides three operating modes for checking an output alongside an independent input mode. Under default mode, the entire BTC balance belonging to the input UTXO gets allocated toward the specified output; under deduct mode, only a portion matching the output value is assigned, leaving the remainder accessible for additional outputs; and under ignore mode, the script and data commitment are verified without restricting the amount. Because default and deduct modes are built to retain value across validated outputs, transaction fees must be settled utilizing separate fee-supplying inputs. A dedicated fee input and change output can be incorporated into the transaction without conflicting with the covenant’s restrictions. This prevents the accidental destruction of funds that can happen in more primitive covenant designs, such as OP_CTV or SIGHASH_ANYPREVOUT. It also resolves a major limitation associated with presigned-transaction-style covenants, which typically predetermine amounts and therefore cannot support dynamic fee adjustments or partial unvaults.
OP_CCV + OP_CAT: Merkle Proofs and Fraud Proofs
When OP_CCV is paired with OP_CAT, the complete MATT framework achieves even greater expressiveness. OP_CAT introduces byte concatenation to Script, making the construction and validation of Merkle proofs directly on-chain feasible. Two distinct Merkle trees associate with a Taproot output in such a configuration. The primary one is the familiar Taproot script tree (the taptree), whose leaves represent the spending scripts of the contract. The secondary one is a separate state tree, whose leaves house the contract data, such as intermediate computation steps. The OP_CCV + OP_CAT script can validate a Merkle proof against the active state tree root, calculate the updated root following a transition, and employ OP_CCV to compel the next output to commit to it.
This arrangement facilitates fraud-proof systems featuring a slashing condition where an extensive computation is committed off-chain, and only the precise disputed step (together with its path inside the binary tree) needs exposition and verification on-chain. Similar architectures operate as optimistic rollups across alternative blockchain networks: the complete computation executes off-chain, and the on-chain contract intervenes solely when a challenge is raised. Fraud proofs demand that the computation be compiled down to a binary circuit or comparable step-by-step model that can be committed inside a Merkle tree. Using OP_CCV and OP_CAT eliminates the necessity for Lamport one-time signatures and pre-signed transaction graphs that BitVM depends on for enforcing state consistency.
Beyond fraud proofs, the combination of OP_CCV and OP_CAT also carries consequences for vaults. OP_CCV independently can establish vaults, but when combined with OP_CAT, it permits fully featured vaults functionally equivalent to the capabilities proposed by OP_VAULT. As James O’Beirne, creator of OP_VAULT, has pointed out, OP_CCV constitutes a more versatile and resilient design that effectively replaces his earlier proposal.
In the upcoming installment of this series, we will transition away from general covenant proposals to examine application-specific opcodes including OP_VAULT, OP_UNVAULT, and OP_EVICT. Each of these opcodes is engineered to resolve a specific challenge rather than offer broad programmability.
Magazine: Bitcoin holders have received eCash — What can you do with it?
Originally published at https://cointelegraph.com/research/bitcoin-covenants-part-5-matt-op-ccv?utm_source=rss_feed&utm_medium=rss&utm_campaign=rss_partner_inbound.
