Una propuesta abierta en el repositorio de Bitcoin Core le daría a los scripts de la red algo que nunca han tenido: una memoria. El framework detrás de ella, conocido como MATT (Merkleize All The Things), habilita contratos con estado y fraud proofs escalables en la capa base de Bitcoin, y su implementación más directa se realiza mediante el opcode OP_CCV establecido en el pull request #32080 de Bitcoin Core. El desarrollo fue reportado por COINOTAG el 11 de noviembre de 2026.

Qué busca lograr MATT

El lenguaje de scripting actual de Bitcoin evalúa cada entrada de transacción de forma independiente, sin un mecanismo integrado para que un script determine cómo se pueden gastar esas monedas después. MATT, descrito por primera vez por el desarrollador Salvatore Ingala en la lista de correo Bitcoin-Dev a finales de 2022, apunta exactamente a esa brecha: su objetivo es permitir que los scripts de Bitcoin transporten estado entre transacciones —en efecto, darles una memoria a los contratos— con solo una adición mínima al lenguaje de scripting. Las construcciones de este tipo, comúnmente llamadas covenants, restringen cómo se puede gastar una moneda en transacciones futuras y permiten diseños como bóvedas y otras reglas de gasto autoejecutables, en las que las condiciones de recuperación y gasto se adjuntan directamente a las propias monedas.

Las propuestas tipo covenant han circulado en la comunidad de Bitcoin durante años, y MATT se une a esfuerzos relacionados como OP_CHECKTEMPLATEVERIFY (OP_CTV), propuesto por el desarrollador Jeremy Rubin, en la búsqueda de ampliar lo que la capa base puede expresar.

Fraud proofs y verificación en la capa base

Un segundo objetivo del framework son los fraud proofs escalables: esquemas de verificación en los que un cálculo fuera de cadena se verifica en la cadena solo cuando se plantea una impugnación, en lugar de volver a ejecutarse por completo —un patrón utilizado, por ejemplo, en diseños de optimistic rollups de otras plataformas, donde el cálculo ocurre fuera de cadena y solo los resultados disputados requieren escrutinio en la capa base. Como el esfuerzo de verificación está vinculado a las impugnaciones y no al tamaño del cálculo en sí, estos esquemas se describen como escalables. En el diseño de MATT, esta verificación está pensada para ejecutarse directamente en la capa base de Bitcoin, con OP_CCV (abreviatura de OP_CHECKCONTRACTVERIFY) como el opcode central para hacer cumplir la lógica de los contratos.

Revisión, no activación

Los cambios que afectan el consenso de Bitcoin avanzan mediante pull requests públicos en el repositorio de GitHub de Bitcoin Core, donde la revisión técnica y las pruebas suelen extenderse por largos periodos. Dado que las reglas de consenso de Bitcoin en última instancia las aplican los operadores de nodos completos de toda la red, una revisión favorable del código es solo un paso; es la adopción amplia por parte del ecosistema lo que convierte un cambio propuesto en una regla activa de la red. La actualización de consenso más reciente de Bitcoin, Taproot, se activó en noviembre de 2021 tras un proceso de varios años, una trayectoria que ilustra cuánto pueden prolongarse estos esfuerzos. El pull request #32080, como todas las propuestas de este tipo, requeriría una revisión extensa y un amplio acuerdo comunitario antes de que se pudiera considerar cualquier activación; el informe de origen no indica una fecha límite. Su hilo de revisión público en GitHub, donde se acumulan los comentarios técnicos y revisiones de los colaboradores, ofrece una forma directa de seguir si la propuesta avanza.

Este contenido se publicó por primera vez en COINOTAG: https://en.coinotag.com/matt-op-ccv-bitcoin-covenant-pull-request-32080