MATT Proposal Targets Bitcoin (BTC) Stateful Contracts via OP_CCV Pull Request 32080

A State-Carrying Opcode for Bitcoin Script

A proposal now open in the Bitcoin (BTC) Core repository would give the network's scripts something they have never had: a memory. The MATT (Merkleize All The Things) framework enables stateful contracts and scalable fraud proofs on the base layer, and its most direct implementation runs through OP_CHECKCONTRACTVERIFY, or OP_CCV, an opcode carried in pull request 32080. Covenants are script rules that constrain where coins may be spent in future transactions. Standard Bitcoin scripts evaluate every transaction independently, with no record of what earlier spends did, so a contract cannot carry information forward and update it as the contract evolves. Every covenant proposal allows state-carrying UTXOs to some degree. Scripting languages such as Sapio, which builds on OP_CTV, manage it by treating addresses as a finite state automaton in which each transaction acts as a state transition. Covenants have sat for years among active Bitcoin protocol proposals because plain Script stops short of that guarantee. That automaton paradigm leaves no clean way to express numerical logic, and that is the gap MATT fills. Because MATT lets committed data be computed at spend time and re-embedded into the next output, each spend can derive a new state dynamically instead of choosing from a predetermined set of states. The opcode is designed for Taproot outputs, where commitments ride on the public key itself rather than on extra script data. That difference decides whether a contract can adapt to changing balances or only to a fixed tree of pre-agreed outcomes. The proposal concerns the scripting layer beneath the Bitcoin (BTC) price rather than anything visible on a chart, yet it defines what the asset can do beyond simple settlement, from vaults that recompute withdrawal conditions at spend time to fraud-proof systems that verify only a single disputed computation step.

Tweaked Keys, Three Check Modes

Every Taproot output contains a base public key, called the internal key, which can be cryptographically modified, or tweaked, to commit to extra information. The tweaked key takes the form Q = P + t·G, where P is the internal key, G is the generator of the secp256k1 elliptic curve and t is a tagged hash of P and the committed data. In a regular Taproot output, that commitment usually encodes the Merkle root of a taptree holding hidden spending paths. MATT builds on the same mechanism and embeds contract state into the key as well, so the chain verifies only that each state transition is valid rather than executing the contract's logic. The opcode takes state data, an output index, a public key, an optional taptree and a mode. Three modes check an output, and a separate mode checks an input. Default mode allocates the entire value of the input UTXO to the specified output. Deduct mode assigns only a portion equal to the output's amount and leaves the remainder free for further outputs. Ignore mode verifies the script and data commitment without constraining the amount. Because default and deduct preserve value across checked outputs, transaction fees must be paid through separate fee-paying inputs; a dedicated fee input and change output can ride along without conflicting with the covenant's constraints. That prevents the accidental burning of funds possible under more primitive covenant schemes such as OP_CTV or SIGHASH_ANYPREVOUT, and it fixes a limitation of presigned-transaction covenants, which define amounts upfront and cannot accommodate dynamic fee adjustments or partial unvaults. Expressiveness grows again when OP_CCV pairs with OP_CAT, which enables byte concatenation in Script. The pair can construct and verify Merkle proofs on-chain against a second tree, one that holds the contract's data rather than its spending scripts, then force the next output to commit to the updated root. Fraud-proof systems follow: a long computation runs off-chain, and only the disputed step, together with its path through the binary tree, gets revealed and verified on-chain. That computation must first be compiled into a step-by-step binary representation, the problem the elftrace binary circuit tool works on. The construction mirrors Ethereum optimistic rollups, and the same fraud-proof model underpins many cross-chain bridges. It would also drop the Lamport one-time signatures and pre-signed transaction graphs that BitVM relies on to enforce state consistency, and it can reproduce the vault functionality proposed by OP_VAULT, whose author James O'Beirne has described OP_CCV as a more general and robust design that effectively supersedes his earlier proposal.

The Review Road Ahead

The fee-handling design is what separates OP_CCV from earlier covenant sketches. Because default and deduct modes hold value inside the checked outputs while fees travel through separate inputs, stateful designs stay workable in a live fee market where presigned flows break down. Nothing is merged yet. The pull request carries no activation timeline, and any eventual use would require node operators to run software enforcing the new consensus rules, the slow path every Bitcoin (BTC) change takes. For holders, the nearer-term consequence is design space: native vaults could cut reliance on wrapped Bitcoin for self-custody guarantees, and state trees could extend what Bitcoin DeFi settles without trusted custodians. The outstanding action sits with Bitcoin Core reviewers and the wider developer community, who must audit the opcode's consensus behavior before any of this reaches the mainnet.