Cointelegraph Research breaks down MATT and OP_CCV, a Bitcoin covenant proposal for stateful contracts

Bitcoin Script has always had the memory of a goldfish. Every transaction is judged on its own, with no built-in sense of what came before or what should come next.

A proposal called MATT, short for Merkleize All The Things, wants to change that. On November 11, 2026, Cointelegraph Research published Part 5 of its Bitcoin covenants series, focused on MATT and its key building block: a proposed opcode called OP_CHECKCONTRACTVERIFY, or OP_CCV, defined in BIP 443.

The pitch is simple to say and hard to build. Let Bitcoin outputs carry contract state forward, and let the network check that the state changed by the rules.

How MATT and OP_CCV actually work

According to Cointelegraph Research, the framework embeds contract state data directly inside Taproot output keys using cryptographic tweaks. The state rides along inside the key itself.

OP_CCV is the referee. When someone spends one of these outputs, the opcode lets the script read the state data supplied on the witness stack. The script can then run computations on that data.

Then comes the enforcement step. OP_CCV can require that the resulting updated state gets correctly committed again in a designated output. If the new output does not carry the right state, the spend fails.

Put more plainly, the coins can only move forward in ways the contract allows, and the contract’s memory moves with them. That is how state transitions get enforced on-chain, something standard Bitcoin Script cannot handle because it evaluates each transaction in a stateless way.

What it could unlock

Applications tied 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, particularly when paired with OP_CAT, a separate proposed opcode, for Merkle proof verification. In an optimistic setup, a computation is assumed correct unless someone proves otherwise.

Combined with OP_CAT, MATT facilitates on-chain Merkle proofs and fraud proofs that could support the execution of arbitrary computations.

The research also stresses a design goal that matters a great deal to node operators. The aim is to provide a path to limited state and introspection without piling significant computational overhead onto base-layer nodes.

A proposal with a paper trail

MATT is not new. Salvatore Ingala first introduced the idea in November 2022 on the bitcoin-dev mailing list, and he also presented it at BTCAzores.

BIP 443, which defines OP_CCV, gained BIP status in May 2025. Around that shift, 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, Bitcoin’s style of test network where developers can try features without touching real money.

What this means for Bitcoin and its builders

As of late 2026, no covenant proposal, BIP 443 included, has been activated on Bitcoin mainnet. Per the research summary, the technical discussion carries no immediate implications for prices.

The bigger obstacle is social, not 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. Several of MATT’s most ambitious use cases lean 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.