Bitcoin Covenants Part 5: Understanding MATT and OP_CHECKCONTRACTVERIFY — Enabling State Persistence Across Bitcoin Transactions
Through OP_CCV, contract state gets embedded into Taproot output keys while valid state transitions are enforced on the blockchain. This enables the implementation of stateful contracts along with compact fraud proofs.
This represents Part 5 within the technical article series covering Bitcoin covenants by Cointelegraph Research. The previous article can be accessed by clicking here.
The MATT framework, which stands for Merkleize All The Things, represents a smart contract architecture designed for Bitcoin that facilitates stateful contracts alongside scalable fraud proofs. When we refer to a stateful contract, we mean one that maintains and carries information forward through multiple transactions while possessing the ability to modify this data as the contract progresses through its lifecycle. Traditional Bitcoin scripts lack this particular capability, given that each transaction undergoes evaluation independently without any recollection of prior executions.
To some degree, every proposal for covenants permits UTXOs to carry state, as demonstrated by scripting languages like Sapio, which is constructed upon OP_CTV. The mechanism operates by utilizing addresses to represent what is known as a finite state automaton, with transactions serving as the transitions between states. Nevertheless, this paradigm lacks an elegant method for implementing numerical logic, which is precisely the void that MATT fills, particularly through its suggested implementation via OP_CCV. The reason MATT stands out is that it permits committed data to undergo computation during the spending process and subsequently be re-embedded into the following output, enabling each spend to dynamically derive a fresh state rather than selecting from a fixed, predetermined collection of possible states.
The mechanism by which OP_CCV commits state into Taproot keys
Understanding the MATT proposal requires first examining the method by which Taproot commits data using public keys. Within every Taproot output exists a base public key, referred to as the internal key, which undergoes cryptographic modification or "tweaking" to commit additional information. From a formal standpoint, the tweaked public key takes the form Q = P + t·G, in which P represents the internal key, G denotes the generator of the secp256k1 elliptic curve, and t constitutes a tagged hash derived from P and the data being committed.
Within a standard Taproot output, this commitment mechanism usually encodes the Merkle root of what is called a taptree, containing concealed spending paths. MATT expands upon this underlying mechanism to additionally embed contract state within the key itself. Rather than embedding intricate logic directly within Bitcoin's scripting language, MATT encodes computational processes as a series of state commitments, with the blockchain verifying solely that each transition between states maintains validity.
Multiple opcode combinations can realize MATT. The implementation that proves most direct and thoroughly specified depends upon OP_CHECKCONTRACTVERIFY (OP_CCV). The primitive that OP_CCV provides makes state-carrying UTXOs practically feasible within the Taproot framework. What OP_CCV enables is script verification that a Taproot input or output key has undergone tweaking to commit to a particular piece of state data. The process begins with the internal key being tweaked using a hash of the contract's present state, followed by the application of Taproot's standard taptree tweak layered on top. Consequently, the resulting output key commits to both the tapscript (representing the collection of spending conditions) as well as the contract's current state.
Subsequently, OP_CCV possesses the ability to enforce which state gets carried forward into the subsequent output. It grants the script the capability to inspect state data presented on the witness stack, execute computations upon it, and mandate that the resulting updated state undergoes correct re-commitment in a designated output. This represents the mechanism through which state transitions receive enforcement on-chain. The format for the stack is as follows:
<data> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFY
Three distinct modes for output checking are supported by the opcode, in addition to a separate mode for inputs. When operating in default mode, the complete BTC value from the input UTXO gets allocated to the output that has been specified; within deduct mode, merely a portion equivalent to the output's amount receives assignment, with the remaining balance staying available for additional outputs; and under ignore mode, verification of the script and data commitment occurs without imposing constraints on the amount. Given that default and deduct modes are engineered to maintain value across outputs that have been checked, transaction fees require payment through separate inputs dedicated to fees. Without creating conflict with the covenant's constraints, a dedicated fee input along with a change output can be incorporated into the transaction. This approach prevents the inadvertent burning of funds that may occur with more rudimentary covenant implementations, including OP_CTV or SIGHASH_ANYPREVOUT. Additionally, it resolves a significant limitation inherent in presigned-transaction-style covenants, which characteristically define amounts in advance and consequently cannot support dynamic fee adjustments or partial unvaults.
Combining OP_CCV with OP_CAT: Merkle Proofs alongside Fraud Proofs
The full MATT framework achieves even greater expressiveness when OP_CCV undergoes combination with OP_CAT. What OP_CAT facilitates is byte concatenation within Script, creating the possibility to construct and verify Merkle proofs directly on-chain. Within such an arrangement, two distinct Merkle trees maintain association with a Taproot output. The first tree is the familiar Taproot script tree (the taptree), with leaves consisting of the contract's spending scripts. The second represents a separate state tree, whose leaves contain the contract's data, including items such as intermediate computational steps. The script combining OP_CCV with OP_CAT possesses the ability to verify a Merkle proof against the root of the current state tree, compute the updated root following a transition, and employ OP_CCV to compel the next output to commit to this updated root.
This particular construction facilitates fraud-proof systems featuring a slashing condition whereby an extensive computation receives commitment off-chain, with only the specific step under dispute (along with its path within the binary tree) requiring revelation and verification on-chain. Similar systems manifest as optimistic rollups within other blockchain systems: the complete computation executes off-chain, with the on-chain contract intervening solely when a challenge arises from someone. Fraud proofs necessitate that the computation undergo compilation into a binary circuit or an equivalent step-by-step representation capable of receiving commitment in a Merkle tree. OP_CCV combined with OP_CAT would eliminate the necessity for the Lamport one-time signatures and pre-signed transaction graphs upon which BitVM relies for enforcing state consistency.
The combination of OP_CCV and OP_CAT carries implications extending beyond fraud proofs into the realm of vaults. While OP_CCV alone possesses the capability to implement vaults, its combination with OP_CAT permits fully featured vaults that prove essentially equivalent in functionality to what OP_VAULT proposes. According to James O'Beirne, who authored OP_VAULT, OP_CCV represents a design that is more general and robust, effectively superseding his earlier proposal.
The next article within this series will transition away from general covenant proposals to examine application-specific opcodes including OP_VAULT, OP_UNVAULT, and OP_EVICT. Rather than providing broad programmability, each of these opcodes is engineered to solve a particular problem.