Bitcoin Script has long had the memory of a goldfish. Each transaction is evaluated on its own, with no built-in awareness of what came before or what should follow.
A proposal called MATT, short for Merkleize All The Things, aims to change that. On November 11, 2026, Cointelegraph Research released Part 5 of its Bitcoin covenants series, centered on MATT and its core building block: a proposed opcode called OP_CHECKCONTRACTVERIFY, or OP_CCV, defined in BIP 443.
The idea is easy to describe but difficult to implement. Bitcoin outputs would carry contract state forward, and the network would verify that the state changed according to the rules.
How MATT and OP_CCV actually work
According to Cointelegraph Research, the framework places contract state data directly within Taproot output keys using cryptographic tweaks, so the state travels inside the key itself.
OP_CCV acts as the referee. When an output like this is spent, the opcode lets the script read the state data supplied in the witness stack, and the script can then perform computations on that data.
Next is enforcement. OP_CCV can require that the updated state is correctly committed again in a designated output. If the new output does not carry the correct state, the spend fails.
Put simply, coins can only move in ways the contract permits, and the contract's memory moves along with them. This is how state transitions could be enforced on-chain, something standard Bitcoin Script cannot do because it processes each transaction statelessly.
What it could unlock
Applications linked to the MATT framework include vaults, payment pools, transferable DLCs (discreet log contracts) and optimistic smart contracts.
Fraud proofs are another headline feature. MATT is designed to make them more efficient, especially when combined with OP_CAT, a separate proposed opcode, for Merkle proof verification. In an optimistic setup, a computation is presumed correct unless someone proves otherwise.
Combined with OP_CAT, MATT could facilitate on-chain Merkle proofs and fraud proofs that may support the execution of arbitrary computations.
The research also highlights a design goal that matters greatly to node operators: providing a path to limited state and introspection without adding significant computational overhead to base-layer nodes.
A proposal with a paper trail
MATT is not new. Salvatore Ingala first introduced the idea on the bitcoin-dev mailing list in November 2022, and he also presented it at BTCAzores.
BIP 443, which defines OP_CCV, achieved BIP status in May 2025. Around that transition, OP_VAULT, specified in BIP 345, was withdrawn in favor of the MATT-based approach.
The proposal has also been assigned the identifier BIN-2026-0002 for testing on a signet, a Bitcoin test network where developers can try features without risking real funds.
What this means for Bitcoin and its builders
As of late 2026, no covenant proposal, including BIP 443, has been activated on Bitcoin mainnet. According to the research summary, the technical discussion has no immediate implications for prices.
The bigger obstacle is social rather than technical. Consensus among Bitcoin developers remains the crucial barrier to moving covenant proposals toward implementation.
The pairing with OP_CAT is another thread to watch, since several of MATT's most ambitious use cases depend on that separate opcode for Merkle proof verification.
For now, the practical milestones are clear: watch signet testing under BIN-2026-0002, watch whether developer discussion converges or fragments, and watch whether any covenant proposal makes a credible move toward activation.
Add A Comment
Comments are closed.