Saltar al contenido principal

El renacimiento de los covenants de Bitcoin: Cómo OP_CTV, LNHANCE, OP_CAT y BitVM2 podrían finalmente traer contratos inteligentes a Bitcoin L1

· 16 min de lectura
Dora Noda
Dora Noda
Software Engineer

Durante quince años, el lenguaje de scripting de Bitcoin ha sido deliberada y agresivamente aburrido. Sin bucles. Sin recursividad. Sin estado. Una pila pequeña, un puñado de opcodes y una cultura que trata cada propuesta de expansión como una potencial guerra civil. Ese conservadurismo es la razón por la que Bitcoin nunca ha sido explotado con éxito en la capa de consenso — y la razón por la que los desarrolladores que querían construir algo más allá de "enviar monedas de A a B" finalmente se rindieron y se mudaron a Ethereum.

Ese cálculo está cambiando en 2026. OP_CHECKTEMPLATEVERIFY tiene parámetros de activación concretos sobre la mesa por primera vez desde que se redactó el BIP-119. OP_CAT tiene un número oficial de BIP. LNHANCE se está discutiendo activamente como una alternativa centrada en Lightning. Y BitVM2 — que no requiere ningún soft fork en absoluto — ya está funcionando en producción, impulsando el puente de la red principal de Citrea que se lanzó en enero. Después de años de "los covenants llegarán pronto", Bitcoin se encuentra finalmente en la fase en la que múltiples propuestas creíbles se ejecutan en paralelo, cada una resolviendo una parte diferente del problema.

Qué son realmente los Covenants (y por qué han sido tan polémicos)​

Un covenant, en términos de Bitcoin, es una restricción sobre cómo se puede gastar un UTXO en el futuro. El script normal de Bitcoin solo puede responder a la pregunta "¿está autorizado este gasto ahora mismo?". Un covenant amplía eso a "¿está autorizado este gasto y coincide la siguiente transacción con estas condiciones?".

Esa pequeña extensión desbloquea una cantidad sorprendente de funcionalidad. Bóvedas (vaults) que imponen un retraso de tiempo obligatorio antes de que los fondos puedan salir a un destino específico. Compromisos de control de congestión que permiten que una transacción en cadena financie miles de pagos fuera de la cadena. Pools de pagos. Canales no interactivos. Puentes de ZK-rollup que no dependen de federaciones multifirma. La lista de cosas que se vuelven posibles es lo suficientemente larga como para que los desarrolladores hayan estado discutiendo sobre los covenants durante la mayor parte de una década.

¿Por qué la pelea? Dos preocupaciones reales, una cultural. Técnicamente, los covenants recursivos — covenants que se imponen a sí mismos en cada gasto subsiguiente, para siempre — podrían teóricamente usarse para crear monedas restringidas permanentemente, socavando la fungibilidad de Bitcoin. Culturalmente, el espíritu de desarrollo de Bitcoin trata cada nuevo opcode como una superficie de ataque potencial, y habilitar covenants después de Taproot es, para algunos desarrolladores, una expansión inaceptable del presupuesto de complejidad del protocolo. La cobertura de Bitcoin Magazine sobre el debate del BIP-119 capturó esta dinámica sin rodeos: "Habilitar covenants en Bitcoin es un gran cambio con apenas investigación existente sobre el tema, y el intento de forzarlo por la puerta trasera tan pronto después de la activación de Taproot debería ser resistido".

Tres años de investigación adicional después, esa crítica de "apenas investigación" es más difícil de sostener.

OP_CTV (BIP-119): La propuesta de bóveda minimalista​

OP_CHECKTEMPLATEVERIFY es la propuesta de covenant más cercana a la activación real. Escrito por Jeremy Rubin, el BIP-119 añade un único opcode que compromete un UTXO a ser gastado en una plantilla de transacción específica y predeterminada: la versión, el locktime, el recuento de entradas, las secuencias, el recuento de salidas, las salidas y la posición de la entrada de gasto. Si coincide con la plantilla, puedes gastar. Si no coincide, no puedes.

Eso es todo. OP_CTV es no recursivo por diseño: puedes comprometerte con una transacción futura, pero esa transacción futura no puede a su vez comprometerse con transacciones posteriores de una manera que cree una restricción perpetua. Esta limitación deliberada es la razón por la que los defensores de CTV lo consideran el covenant "seguro" — permite bóvedas, control de congestión y ciertas mejoras de Lightning, pero no puede usarse para construir monedas permanentemente manchadas.

La noticia concreta para 2026: los parámetros de despliegue de CTV ahora especifican una fecha de inicio del 30 de marzo de 2026, un tiempo de expiración del 30 de marzo de 2027, una altura mínima de activación en mayo de 2027, un umbral de señalización de mineros del 90% y un período de señalización de 2016 bloques. Esto no es consenso — es una propuesta de parámetros de activación. Pero es la primera vez desde 2022 que hay un cronograma concreto sobre la mesa, y representa al bando de CTV planteando la cuestión: activarlo o rechazarlo formalmente.

La aplicación estrella práctica para CTV es la bóveda (vault). Hoy en día, si un usuario quiere autocustodiar 1 millón de dólares en Bitcoin con protección contra el compromiso de una sola clave, sus opciones son complicadas: multifirma con distribución geográfica de claves (operativamente doloroso), transacciones bloqueadas por tiempo (frágiles) o servicios de custodia (anula el propósito). Una bóveda CTV permite a un usuario comprometerse a que cualquier gasto desde su almacenamiento en frío debe pasar primero por una dirección intermedia bloqueada por tiempo, durante la cual el usuario puede detectar actividad no autorizada y activar una recuperación de fondos (clawback). Este es el tipo de primitiva que cambia materialmente el perfil de riesgo de las grandes tenencias de Bitcoin.

OP_CAT (BIP-347): El camino maximalista del covenant recursivo​

OP_CAT es casi la propuesta opuesta filosóficamente. Mientras que CTV es un opcode cuidadosamente delimitado y diseñado para habilitar un conjunto específico de casos de uso, OP_CAT es una primitiva — concatenación de cadenas en la pila (stack) — que ya estaba en el lenguaje de scripting original de Bitcoin antes de ser desactivada en 2010 por preocupaciones de DoS que ya no se aplican con los límites de tamaño de script posteriores a Taproot.

Reactivar OP_CAT no parece gran cosa a simple vista: solo permite que los scripts concatenen dos cadenas de bytes. Pero la concatenación, combinada con las firmas Schnorr introducidas por Taproot, es suficiente para construir introspección — la capacidad de un script para examinar la transacción que lo está gastando. Y la introspección es suficiente para construir covenants recursivos, máquinas de estado y, por extensión, casi cualquier contrato inteligente que se podría escribir en una cadena de estilo EVM.

StarkWare publicó un covenant de puente de prueba de concepto sobre Bitcoin con OP_CAT habilitado que demuestra exactamente esto: puentes con confianza minimizada desde Bitcoin a las L2, aplicados enteramente por el script de Bitcoin, sin requerir una multifirma federada o una cadena de puente separada. El equipo de sCrypt ha publicado una serie de varias partes que muestra cómo OP_CAT permite contratos UTXO con estado, comercio de ordinales al estilo NFT y bóvedas recursivas.

El compromiso es exactamente lo que preocupa a los defensores de CTV. La expresividad de OP_CAT incluye la capacidad de crear monedas restringidas permanentemente. En la práctica, esto ya existe en formas más débiles (multifirma con claves perdidas, bloqueos de tiempo con vencimientos imposibles), y los defensores de OP_CAT argumentan que la preocupación por la fungibilidad es teórica más que operativa. Pero la división filosófica es real: OP_CTV dice "habilitemos los covenants para estos casos de uso específicos"; OP_CAT dice "habilitemos la primitiva y dejemos que los desarrolladores descubran los casos de uso".

El hecho de que OP_CAT recibiera el BIP-347 en 2024 fue importante menos por su sustancia técnica — CAT es un opcode de cuatro bytes — que por señalar que el camino maximalista de los covenants tenía suficiente credibilidad entre los desarrolladores como para superar el proceso BIP.

LNHANCE: El compromiso centrado en Lightning​

LNHANCE es la propuesta con el discurso más claro sobre "qué problema resuelve". En lugar de argumentar a favor de los covenants por motivos abstractos, LNHANCE agrupa OP_CTV con OP_CHECKSIGFROMSTACK (CSFS) y OP_INTERNALKEY, apuntando específicamente a mejoras en la Lightning Network.

La Lightning Network en abril de 2026 ha crecido a más de 65,000 nodos públicos y se ha convertido en el riel de pagos dominante de Bitcoin, pero arrastra una deuda de protocolo real. La verificación del estado del canal todavía requiere servicios de watchtower o carteras en línea. Las fábricas de canales (channel factories) y los canales multiparte son difíciles de construir. Las aperturas de canales no interactivas — donde una de las partes puede abrir un canal a otra sin que el destinatario esté en línea — no son posibles en la Lightning actual.

LNHANCE permite LN-Symmetry (un mecanismo de estado de canal más limpio), timeout trees (cierres masivos eficientes de canales), scripts PTLC simplificados (contratos de tiempo bloqueado por puntos que reemplazan los actuales contratos bloqueados por hash o HTLC), canales no interactivos unidireccionales, vaults mejorados y pools de monedas trustless. Cada una de estas es una mejora concreta para Lightning, más que una primitiva especulativa de contrato inteligente.

Este enfoque pragmático es la ventaja política de LNHANCE. La Lightning Network ha logrado una adopción real, desde procesadores de pagos regionales hasta el protocolo L402 que Lightning Labs está posicionando como la capa de pagos nativa para transacciones de agentes de IA. Las mejoras que mantienen a Lightning competitiva son más fáciles de justificar que las mejoras que permiten principalmente casos de uso de BTC-en-otras-cadenas.

BitVM2: La alternativa sin soft-fork que ya está activa​

El desarrollo pragmático más importante de los últimos dieciocho meses no es una propuesta de covenant en absoluto; es BitVM2, y el hecho de que requiere cero cambios en el consenso de Bitcoin.

BitVM2, de la autoría de Robin Linus, extrae la esencia de lo que permiten los covenants (computación fuera de la cadena verificable anclada a Bitcoin) sin requerir que el propio Bitcoin realice el cómputo. El protocolo funciona bajo un modelo de desafío-respuesta: un probador (prover) hace una afirmación sobre algún cómputo off-chain, deposita una fianza y, si un verificador cree que la afirmación es errónea, puede iniciar una disputa de búsqueda binaria que aísle el paso específico donde el probador hizo trampa. Ese único paso se ejecuta entonces on-chain en un script de Bitcoin, y la fianza del mentiroso es penalizada (slashed).

La elegancia económica: los probadores honestos nunca son desafiados, por lo que las disputas son raras y el coste on-chain se amortiza hasta ser casi nulo. La elegancia computacional: el protocolo revisado de BitVM2 resuelve cualquier disputa en solo tres transacciones on-chain, frente a las docenas requeridas en el esquema original de BitVM. La elegancia sin permisos (permissionless): cualquiera puede desafiar, por lo que la seguridad del sistema no depende de que un conjunto fijo de verificadores se mantenga honesto.

BitVM2 está activo ahora mismo. Citrea — el primer ZK-rollup de Bitcoin — lanzó su red principal el 27 de enero de 2026, con un puente basado en BitVM2 (nombre en clave "Clementine") como modelo de confianza de producción. GOAT Network lanzó su testnet V3 de BitVM2 en el primer trimestre de 2026, con el objetivo de lograr una pila completa de zkRollup nativa de Bitcoin. El patrón se está volviendo claro: los equipos que no quieren apostar su cronograma de lanzamiento a un soft fork polémico de Bitcoin están eligiendo BitVM2 en su lugar.

La limitación es económica, no criptográfica. Las disputas se pagan en espacio de bloque (blockspace) de Bitcoin y, en el peor de los casos, donde las comisiones se disparan durante una ventana de disputa, los desafiantes pueden quedar fuera por precio. Este riesgo de "economía de disputa" es el problema abierto que los operadores de BitVM2 están gestionando con sobrecolateralización, servicios de watchtower y una elección cuidadosa de qué cómputos asegurar. Es una restricción real, pero un tipo de riesgo muy diferente al de "esperar a que el consenso de Bitcoin se ponga de acuerdo sobre un opcode".

La cuestión de la activación: Por qué el consenso técnico no es suficiente​

La verdad incómoda sobre el debate de los covenants en Bitcoin es que los desacuerdos técnicos — recursivos vs. no recursivos, opcode minimalista vs. primitiva general — son en gran medida resolubles. La pregunta más difícil es cómo activar cualquiera de ellos.

La historia de los soft forks de Bitcoin es corta y está cargada políticamente. SegWit requirió una amenaza de UASF (User-Activated Soft Fork) para romper un estancamiento de mineros en 2017. Taproot utilizó Speedy Trial — una ventana BIP8 de tres meses con un umbral de señalización de mineros del 90 % — y se activó limpiamente en noviembre de 2021. Desde entonces, cada discusión sobre la metodología de activación se ha visto ensombrecida por lo que sucedió antes.

La propuesta de parámetros de CTV 2026 utiliza una ventana de señalización al estilo de Speedy Trial, que tiene precedentes. Pero los opositores a los covenants han dejado claro que no consideran que Speedy Trial sea adecuado para cambios contenciosos; fue diseñado específicamente para propuestas que ya habían logrado un consenso abrumador, y su ventana de tres meses no da tiempo al ecosistema más amplio para plantear objeciones. Es de esperar que la lucha por la metodología de activación sea, si cabe, más intensa que la lucha técnica.

Las condiciones políticas podrían favorecer la activación. La actividad on-chain de Bitcoin ha disminuido significativamente desde su pico de inscripciones de 2024, la demanda de espacio de bloque es débil y los mineros de Bitcoin — que tienen que aprobar cualquier soft fork mediante señalización — buscan nuevas narrativas que impulsen la demanda de espacio de bloque. Los vaults, las mejoras de Lightning y las L2 aseguradas por Bitcoin generan demanda de transacciones on-chain. La alineación de intereses económicos propios es más clara de lo que ha sido en años.

Qué significa esto para los constructores de infraestructura de Bitcoin​

Para los equipos que construyen sobre Bitcoin, el renacimiento de los covenants crea una verdadera elección estratégica. Los equipos que necesitan funcionalidad de tipo smart contract ahora tienen tres caminos creíbles:

Camino 1 — Esperar a CTV / CAT / LNHANCE. Menor complejidad, requiere un soft fork para activarse, cronograma incierto. Ideal para equipos cuyo caso de uso es fundamentalmente imposible sin cambios a nivel de consenso ( por ejemplo, vaults no federados a escala ).

Camino 2 — Construir sobre BitVM2. Disponible hoy, mayor complejidad de implementación, depende de la seguridad económica. Ideal para equipos que construyen L2s de Bitcoin, puentes o rollups que necesitan lanzarse en 2026 sin esperar al consenso.

Camino 3 — Enfoque híbrido. Lanzar en BitVM2, diseñar el protocolo para que la activación de covenants proporcione una vía de actualización más limpia. Esta es la postura que están tomando GOAT Network y varios otros equipos de Bitcoin L2.

Para los proveedores de infraestructura, la implicación compartida es la misma: el script de Bitcoin se está volviendo más expresivo sin importar cuál de estos caminos gane. Las billeteras, los proveedores de RPC, los indexadores y la infraestructura de nodos deben estar listos para manejar tipos de transacciones más ricos — UTXOs con covenants, transacciones de desafío de BitVM2, nuevas estructuras de canales de Lightning — en producción.

BlockEden.xyz proporciona infraestructura RPC de nivel empresarial para Bitcoin y redes adyacentes a Bitcoin, incluidas las L2 emergentes que construyen sobre BitVM2 y primitivas habilitadas para covenants. Explore nuestro marketplace de API para construir sobre bases diseñadas para el próximo capítulo de Bitcoin.

La forma de la próxima década de Bitcoin​

Lo más interesante de 2026 no es que una de estas propuestas se activará definitivamente — cualquiera de ellas podría estancarse por otros uno o tres años. Es que la cultura de desarrollo de Bitcoin ha superado decisivamente el debate binario de "covenants sí vs. covenants no" que definió el periodo 2022 - 2024.

La conversación ahora trata sobre qué combinación de primitivas de covenants, protocolos de verificación off-chain y arquitecturas de Capa 2 ofrece la programabilidad más útil con el menor cambio de consenso. CTV para vaults y control de congestión. CAT para expresividad y puentes. LNHANCE para Lightning. BitVM2 para cualquier cosa que pueda tolerar el modelo de resolución de disputas. Estas no son visiones contrapuestas — son herramientas complementarias en un kit de herramientas de scripting de Bitcoin ampliado.

Bitcoin pasó quince años siendo aburrido a propósito. Esa paciencia estratégica construyó la capa de liquidación más segura de la historia. La pregunta para la próxima década es si esa misma disciplina de seguridad puede sobrevivir al ser extendida para cubrir una capa programable genuinamente expresiva. Si los debates de activación de 2026 terminan con el lanzamiento de al menos una de estas propuestas, la respuesta será sí — y el papel de Bitcoin en el ecosistema cripto más amplio pasará de ser "oro digital que no hace nada" a "la capa de liquidación en la que todo lo demás confía".

Fuentes:

Share on Twitter