Merkleize All The Things (MATT)

Merkleize All The Things (MATT) is an experimental research approach for enabling general smart contracts on Bitcoin, developed by Salvatore Ingala; the name was coined at the BTCAzores unconference. MATT is a proposal, not a consensus feature — it is not part of Bitcoin today, requires a soft fork that has not been scheduled, and carries no activation timeline. It describes a design philosophy that would be unlocked by adding a small number of covenant opcodes to Bitcoin Script. We cover it here for readers following Bitcoin's contracting research, where it stands out for how much expressiveness it targets with how little new machinery.

The core idea

MATT requires no cryptographic primitive beyond the Merkle trees Bitcoin already relies on — hence the name. Contract state is committed as a Merkle root attached to a UTXO; state transitions are enforced by covenants that constrain the spending transaction's outputs to carry a valid next state. Instead of executing a program on-chain, the chain merely verifies commitments to the program's state as it evolves from output to output. Data availability is handled the same way: large state can live off-chain, with only the Merkle root committed on-chain and individual leaves revealed when a transition needs them.

Fraud proofs and the bisection game

The most ambitious part of MATT is how it settles disputes about arbitrary computation. Because any computation can be broken into small verifiable steps, two parties who disagree about a program's result can play an interactive challenge-response protocol: a bisection game that repeatedly halves the disputed computation trace until the disagreement narrows to a single step small enough for Bitcoin Script to check directly. The honest party can always win this game, so in the cooperative case nothing heavy ever touches the chain — the fraud-proof machinery exists as a deterrent. This optimistic, dispute-driven style is shared with systems like BitVM2, which pursues similar goals without waiting for new opcodes.

Design goals and required opcodes

Ingala highlights several intended properties: minimal impact on Layer 1, no application-specific opcodes, a clean fit with the Pay-to-Taproot script structure introduced by Taproot, and no new cryptographic assumptions beyond hash functions. In practice, much of MATT's generality can be reached with just OP_CHECKCONTRACTVERIFY plus OP_CAT. A rough vault design comparable to OP_VAULT-style constructions has been sketched on the MATT model, suggesting the framework is expressive enough for the use cases most often cited in covenant discussions. MATT also relates closely to OP_TXHASH and the broader family of transaction-introspection proposals.

Where the debate stands

As with all covenant work, the community continues to weigh expressiveness against base-layer simplicity. Supporters argue MATT's minimalism — Merkle trees and a couple of opcodes — is exactly the conservative path to contracts; skeptics note that fraud-proof protocols add interaction complexity and that any soft fork carries consensus risk. There is no timeline, no activation plan, and no guarantee MATT ships in any form. For a sovereign Bitcoiner, the honest summary is: MATT is one of the clearest articulations of how far Bitcoin's contracting could go with minimal changes, and it remains research — worth understanding, not worth building on yet.