# [Serie BTCFi 7] Covenants: El Fork Congelado de Bitcoin > CTV y CSFS desbloquearían vaults, bridges más económicos y plataformas off-chain a escala de Ark. Analizamos por qué la activación se estancó y qué implica un impulso fuera de Core en 2026. - Source: https://www.steadyrain.xyz/es/articles/btcfi-series-7-covenants-ctv-csfs/ - Publisher: Steady Rain - Author: 0xYatha - Published: 2026-07-15T02:36:36.384Z - Categories: BTCFi - Language: es ## Introducción Bitcoin no ha activado ningún cambio de consenso desde Taproot en noviembre de 2021. Todas las demás cadenas importantes con contratos inteligentes han iterado varias veces sobre su capa de ejecución en ese mismo período. Bitcoin, por diseño, no lo ha hecho — y la frustración que esto ha generado dentro de la comunidad de builders de BTCFi está aflorando ahora como un impulso organizado hacia una actualización concreta y mínima: la combinación de **OP_CHECKTEMPLATEVERIFY** (CTV) y **OP_CHECKSIGFROMSTACK** (CSFS). La propuesta es acotada. CTV permite que una moneda se comprometa de antemano con la forma exacta de la transacción que la gasta. CSFS permite que un script verifique una firma sobre datos arbitrarios extraídos del stack. Ninguno introduce recursión. Ninguno habilita la programabilidad general que los defensores de OP_CAT persiguen. Sin embargo, juntos desbloquearían una categoría de construcciones — vaults sin custodia, joinpools y channel factories más eficientes, discreet log contracts más baratos, y caminos más simples para Lightning y Ark — que los builders de BTCFi han venido emulando con maquinaria de transacciones prefirmadas cada vez más frágil. La pregunta interesante para nosotros no es si CTV+CSFS es técnicamente sólido. Ese debate está en gran medida agotado; la propuesta lleva años en el dominio público. La pregunta interesante es por qué una actualización tan acotada ha quedado paralizada, y qué significan la carta abierta de mediados de 2025 y el calendario de activación fuera de Core propuesto para 2026\~2027 en términos de cómo Bitcoin toma decisiones de consenso en adelante. Si la activación prospera a través de un cliente que no es Bitcoin Core, será el primer precedente de ese tipo desde la era del UASF de SegWit, y redefinirá cómo se negocian los cambios de protocolo futuros. Si fracasa, confirmará que la trayectoria de actualización de Bitcoin está, en la práctica, congelada — y que los builders de BTCFi deberían planificar en consecuencia. ## Qué es un covenant *[Figure: img1]* Un covenant, en términos de Bitcoin script, es una condición de gasto que restringe no solo si un UTXO puede gastarse, sino cómo debe ser la transacción que lo gasta. Hoy, el script responde una pregunta en tiempo presente: dados los datos del witness, ¿está autorizado este gasto ahora mismo? Un covenant extiende ese horizonte temporal: dado este gasto, ¿la transacción que produce coincide con una forma a la que nos comprometimos antes? CTV, especificado en el BIP-119, implementa esto de la manera más restrictiva posible. Cuando un UTXO está bloqueado en un script CTV, el opcode hashea un conjunto específico de campos de la transacción que lo gasta y los compara con un hash de plantilla embebido en el script. Según Bitcoin Optech, los campos comprometidos son: la versión de la transacción, el locktime, los scriptsigs, el número de inputs, los valores de secuencia, el número de outputs, los propios outputs, y el índice del input que gasta. Si alguno de estos difiere de la plantilla, el gasto falla. Dos propiedades de este diseño merecen una pausa. Primera, CTV se compromete con los outputs pero no con los inputs — en concreto, no con los txids de los inputs. Esto es lo que permite reutilizar la misma plantilla con distintas transacciones de financiación, lo cual hace prácticas las construcciones de vaults y de control de congestión. Segunda, CTV es **no recursivo por construcción**. El hash de la plantilla es un valor fijo en el script; no puede computarse a partir de la transacción que lo gasta. Un output CTV puede forzar su siguiente salto, pero ese siguiente salto es una transacción concreta y preespecificada — no puede ser a su vez un output CTV cuya plantilla se derive de algo en el stack. Esta no recursión estructural es la base íntegra del argumento de que CTV no puede producir monedas permanentemente restringidas. CSFS es un primitivo diferente. Mientras que el OP_CHECKSIG existente de Bitcoin verifica una firma sobre la transacción actual, CSFS verifica una firma sobre datos arbitrarios que el gastador coloca en el stack. Esos datos pueden ser cualquier cosa — un mensaje sobre un precio futuro, una attestation de un oráculo, un compromiso producido por una contraparte en un protocolo de canal. Por sí solo, CSFS no es un covenant; es un primitivo de delegación y attestation. Su potencia en esta combinación proviene de lo que permite hacer a los scripts junto con CTV: verificar que una parte fuera de la cadena ha autorizado un estado concreto y, a continuación, usar CTV para restringir la liquidación on-chain de ese estado. Debemos ser honestos sobre una laguna en nuestra investigación. La mecánica precisa de cómo CSFS se compone con CTV para producir, por ejemplo, un canal al estilo LN-Symmetry o una ronda de Ark más eficiente no quedó desarrollada en el material de partida con el que trabajamos. Lo que sí está claro es que CSFS se incluye en el paquete de "primer paso" precisamente porque CTV solo no cierra la brecha de diseño que más preocupa a los builders de Lightning y Ark. Los lectores que quieran rastrear esas construcciones en detalle deben acudir directamente al hilo de Delving Bitcoin y a los BIPs referenciados. ## Qué desbloquea CTV para BTCFi *[Figure: img2]* La manera más clara de entender por qué los builders impulsan esto es recorrer las construcciones concretas que CTV mejora de forma sustancial. ### Vaults Un vault de Bitcoin, en el sentido que ha adquirido el término, es un esquema de almacenamiento en frío en el que cualquier gasto desde cold storage debe pasar primero por una dirección intermedia con timelock. Durante la ventana de demora, el propietario del vault puede observar el gasto pendiente y, si no está autorizado, invocar un clawback de recuperación que redirige los fondos a una clave más segura. Es lo más parecido que tiene Bitcoin a una respuesta nativa ante el compromiso de claves. Hoy, los vaults se construyen con **claves efímeras y transacciones prefirmadas**. El propietario genera un par de claves temporal, firma los caminos de gasto del vault con ellas, y luego destruye la clave privada. La seguridad del vault descansa entonces en la suposición de que la clave efímera fue efectivamente eliminada y nunca se filtró antes de esa eliminación. Bitcoin Optech describe esta construcción como "frágil en el mejor de los casos," que es la versión educada de la visión de los practitioners. Verificar la eliminación de claves de manera auditable y repetible es un problema operativo real, y la clase de personas dispuestas a ejecutar ese esquema con capital significativo es pequeña. Con CTV — y el OP_VAULT del BIP-345 se apoya en CTV precisamente por esta razón — el juego de las transacciones prefirmadas se reemplaza por un covenant. El output del vault se compromete directamente en consenso con la forma de la transacción de gasto diferido. No existe ninguna clave efímera que pueda filtrarse. No se requiere ninguna eliminación de confianza. El vault se convierte en una construcción sin estado y reproducible que una wallet puede generar de forma determinista a partir de parámetros públicos. ### Joinpools y channel factories Las construcciones que agrupan los fondos de muchos usuarios en un único UTXO y les permiten salir o reestructurarse de forma independiente — joinpools, channel factories y sus variantes — dependen de poder renegociar el estado fuera de la cadena sin pasar por dos rondas completas de firma interactiva cada vez. Optech señala que CTV reduce las rondas de firma necesarias para las transiciones de estado en estas construcciones **de dos a una**. Suena a un detalle de implementación; en realidad es un cambio de escalabilidad y liveness. Una construcción que requiere que los N participantes estén en línea durante dos rondas falla la mitad de las veces, en el límite, si solo requiere una — y los modos de fallo de estas construcciones son habitualmente peores de lo que sugiere el camino feliz. ### Discreet log contracts Los DLC son la forma en que Bitcoin ejecuta hoy los contratos atestados por oráculos. Un único DLC con, digamos, pagos BTC/USD redondeados al dólar más cercano puede involucrar más de diez mil resultados posibles, según Optech, cada uno de los cuales requiere su propio signature adaptor que las contrapartes deben crear, intercambiar, verificar y almacenar. CTV reemplaza ese adaptor por resultado con una plantilla. El coste de configuración de un DLC grande cae aproximadamente en proporción al tamaño del espacio de resultados, que para contratos prácticos es uno o dos órdenes de magnitud. ### Control de congestión y batching CTV también habilita una construcción específica para el mercado de comisiones: un exchange o custodio puede comprometerse on-chain con un único output de plantilla que, cuando se despliega más adelante, paga a múltiples destinatarios. Durante la congestión, el compromiso es barato; el despliegue ocurre cuando las comisiones lo permiten. Esto no crea nueva capacidad, pero permite a los grandes actores desacoplar el momento del settlement orientado al usuario del momento de la confirmación on-chain, lo que cambia la curva de demanda de espacio en bloques durante los picos. Vale la pena mencionar por separado la vía de BitVM. BitVM2 ya está en producción, impulsando el bridge de mainnet de Citrea sin ningún soft fork. Lo que ofrecerían los covenants no es habilitación sino reducción de costes: las construcciones actuales de BitVM consumen una cantidad sustancial de bytes de script emulando primitivos que CTV+CSFS proporcionaría directamente. La afirmación de los proponentes es que los covenants hacen que los bridges con mínima confianza sean más baratos, no que los hagan posibles por primera vez. ## La apuesta minimalista frente al espacio de diseño de OP_CAT *[Figure: img3]* CTV+CSFS no es la única propuesta de covenant sobre la mesa. La alternativa más debatida es **OP_CAT**, un opcode de cuatro bytes que simplemente concatena los dos elementos superiores del stack. Formaba parte del lenguaje de scripting original de Bitcoin y fue desactivado en 2010 por preocupaciones de denegación de servicio relacionadas con el crecimiento ilimitado del stack. A OP_CAT se le asignó el número BIP 347 en 2024, lo que es una señal de que ha superado el umbral de seriedad técnica del proceso, no de que esté cerca de la activación. La brecha de filosofía de diseño entre los dos campos es real. CTV es un **opcode específico y diseñado para un propósito concreto**: hace una sola cosa (comprometerse con un hash de plantilla), y lo hace de una manera que descarta estructuralmente la recursión. OP_CAT es un **primitivo**: hace una cosa muy pequeña (concatenar bytes), pero ese primitivo, combinado con las firmas Schnorr de Taproot, habilita la introspección de scripts — la capacidad de un script de razonar sobre la transacción que lo contiene — lo que a su vez permite covenants recursivos y máquinas de estado generales. StarkWare ha publicado una prueba de concepto de un covenant bridge con OP_CAT que demuestra bridging Bitcoin-a-L2 con mínima confianza sin un multisig federado. Ese tipo de construcción no está disponible bajo CTV+CSFS. El tradeoff, entonces, es entre dos posiciones que son internamente coherentes. La posición de CTV+CSFS es que los covenants deben añadirse en los incrementos más pequeños posibles, que la recursión es una escalada cualitativa distinta, y que la preocupación por la fungibilidad planteada contra los covenants recursivos — la posibilidad teórica de monedas permanentemente bloqueadas en scripts restrictivos — es suficientemente grave como para tratarse en su propio debate, no escondida dentro de un primitivo de propósito general. Los proponentes aceptan que esto significa que varias construcciones de BTCFi seguirán fuera de alcance. La posición de OP_CAT es que la preocupación por los covenants recursivos es en gran medida teórica, que ya existen formas más débiles de restricción (multisig, timelocks, hashlocks), y que añadir introspección general es un cambio de protocolo de una sola vez que abre un espacio de diseño mucho mayor de lo que jamás logrará una serie de opcodes acotados. Las preocupaciones de DoS que motivaron la desactivación de OP_CAT en 2010, argumenta este campo, ya no aplican dado los límites de tamaño de script que introdujo Taproot. Señalamos que la afirmación de que "ya no aplican" es controvertida; se afirma con más frecuencia de la que se demuestra en el material que revisamos. Existe una tercera posición, sostenida principalmente por colaboradores de Bitcoin Core que han sido escépticos abiertos: que el debate sobre covenants en su conjunto es prematuro, que ninguna propuesta ha acumulado los años de revisión que justifica un cambio de consenso, y que la cultura de scripting de Bitcoin — que trata cada nuevo opcode como superficie de ataque — debería tomar el no como predeterminado a menos que el caso del sí sea abrumador. Esta posición no requiere una objeción técnica específica a CTV. Solo requiere una prior elevada contra los cambios de consenso. ## La carta de junio de 2025 y el plan de activación de 2026 *[Figure: img4]* En junio de 2025, según reportes que no pudimos verificar completamente a partir de fuentes primarias en nuestro material de investigación, se publicó una carta abierta convocando a la activación de CTV+CSFS. El brief temático cita aproximadamente 66 firmantes, entre ellos criptógrafos y desarrolladores de Lightning identificados por nombre, pero la lista específica, el texto exacto y el argumento completo de la carta no son directamente accesibles desde las fuentes con las que trabajamos. Optamos por señalar esto como una laguna en lugar de citar una lista de firmantes que no podemos verificar. Lo que sí podemos decir es que la carta existió, que fue cubierta como un evento significativo en la industria, y que su propósito era demostrar consenso entre desarrolladores en torno al paquete mínimo de covenants como primer paso. La respuesta de los colaboradores de Bitcoin Core, según el brief temático, fue de rechazo más que de respaldo. De nuevo, no tenemos acceso directo a las objeciones técnicas específicas planteadas — el hilo de Delving Bitcoin que alberga el debate de fondo solo era parcialmente legible en nuestro material fuente — y no vamos a inventarlas. Lo que sí está claro por la forma del debate es que ninguna facción dentro de Core ha avanzado hacia fusionar la lógica de activación de CTV+CSFS en la propia base de código de Core. Aquí es donde el calendario de 2026 se vuelve interesante. Según una síntesis publicada en abril de 2026, los parámetros concretos de despliegue propuestos para un cliente de activación fuera de Core son: - **Tiempo de inicio**: 30 de marzo de 2026 - **Tiempo de expiración**: 30 de marzo de 2027 - **Altura mínima de activación**: aproximadamente mayo de 2027 - **Umbral de señalización**: 90% de los mineros durante un período de 2016 bloques Tratamos estos números como parámetros propuestos procedentes de una fuente secundaria, no como consenso finalizado. Pero si se mantienen, este sería el primer calendario concreto de soft fork que Bitcoin produce desde Taproot. El mecanismo es la señalización de mineros al estilo BIP9: durante cada ventana de 2016 bloques, los mineros pueden activar un bit en las versiones de sus bloques para señalar disponibilidad. Si el 90% señaliza dentro de la ventana, el fork se bloquea y activa en la altura mínima de activación. La dimensión fuera de Core es la parte más relevante del plan. Como Core no ha fusionado la lógica de activación, el código de señalización y activación se distribuirá en un **cliente alternativo** — una implementación de Bitcoin que sigue todas las reglas de consenso existentes pero añade CTV+CSFS como nueva regla en la altura mínima de activación, siempre que se haya alcanzado el umbral de señalización de los mineros. Los nodos que ejecuten Core seguirán siendo válidos siempre que no se mine ninguna transacción CTV. Si CTV se activa y los nodos Core rechazan un bloque con compromiso CTV, se producirá una escisión de la cadena. ## Apuestas de gobernanza: qué señalaría una activación fuera de Core *[Figure: img5]* El proceso de consenso de Bitcoin no tiene ningún órgano de gobernanza formal. En la práctica, la norma ha sido que los mantenedores de Bitcoin Core tienen un veto suave: los cambios que Core no quiera fusionar no se activan. El UASF de SegWit de 2017 fue el último desafío serio a esa norma, e incluso entonces terminó pasando por la base de código de Core; el cliente UASF (BIP148) era un fork de Core con lógica de activación modificada, y SegWit ya estaba en Core cuando la presión del UASF alcanzó su punto álgido. Una activación fuera de Core para CTV+CSFS supondría un desafío más fuerte a la norma del veto de Core que el UASF de SegWit. El cliente alternativo llevaría código de activación que los mantenedores de Core han declinado explícitamente adoptar. Si los mineros señalizan por encima del 90% y el fork se activa, o bien Core tendría que fusionar CTV+CSFS para mantener a sus usuarios en la cadena mayoritaria — lo que establecería un precedente de que una coalición de desarrolladores suficientemente coordinada más una supermayoría de mineros puede forzar la mano de Core — o bien Core tendría que rechazar explícitamente el fork y aceptar una escisión de la cadena, lo que representa una ruptura mucho más profunda con la suposición de que Bitcoin tiene una única implementación canónica. Hay un argumento legítimo de que esto sería saludable. Que el proceso de actualización de Bitcoin esté efectivamente congelado desde 2021 no es un resultado de diseño que nadie eligió; es un equilibrio que emergió de la dificultad de coordinar cambios de consenso sin gobernanza formal. Forzar la pregunta — o se activa o se rechaza explícitamente — genera información que un estancamiento permanente no produce. También hay un argumento legítimo de que esto es peligroso. El umbral de señalización del 90% de los mineros es un piso, no una prueba de consentimiento de los usuarios. La activación de Taproot contó con un apoyo visible mucho más amplio entre usuarios, empresas y desarrolladores del que tiene CTV actualmente. Un soft fork que se activa con una supermayoría mínima de mineros frente a la objeción de Core podría sentar un precedente explotable por coaliciones futuras con objetivos más estrechos — y los covenants son exactamente la clase de cambio en la que el espacio de "objetivos más estrechos" es amplio. Ninguno de los dos argumentos es decisivo por sí solo. La pregunta empírica es si la coalición de desarrolladores detrás de la carta puede producir suficiente infraestructura de apoyo — soporte de nodos económicos, compromisos de integración de wallets, disponibilidad de exchanges — para que la señal del 90% de los mineros parezca una ratificación y no una señal capturada. A partir de las fuentes que revisamos, esa infraestructura de apoyo aún estaba en proceso de ensamblaje. ## Objeciones pendientes Sería deshonesto de nuestra parte insinuar que las objeciones técnicas han sido resueltas. Tres merecen nombrarse aunque no podamos documentarlas completamente. La primera es la preocupación sobre **TxWithhold**, explorada por Gleb Naumenko en un artículo de BitMEX referenciado en el hilo de Delving Bitcoin. Los covenants pueden usarse para construir scripts que paguen a los mineros por retener transacciones específicas de los bloques. La gravedad depende de cuán fácil resulte realizar dichas construcciones y de cuánta tolerancia tenga el mercado de comisiones; la preocupación no es que los covenants introduzcan la retención de transacciones, sino que podrían abaratar sustancialmente el coste de sobornar para lograrlo. Esto no ha sido, hasta donde sabemos, analizado formalmente en el contexto específico de CTV+CSFS de una manera que resuelva el debate. La segunda es la crítica del **presupuesto de complejidad**. Cada nuevo opcode amplía la superficie del código de consenso y crea nuevas interacciones con los primitivos de script existentes. La cultura de desarrollo de Bitcoin trata esta expansión como costosa por defecto. El paquete CTV+CSFS es acotado, pero no es gratuito, y las horas de revisión necesarias para auditar las interacciones con Taproot, los flags de sighash y las propuestas futuras son nada despreciables. La tercera es el **problema del primer paso**. Si CTV+CSFS se activa, ¿hace eso el debate de OP_CAT más fácil o más difícil? Los proponentes argumentan que más fácil: la comunidad habrá demostrado que puede publicar un soft fork, y el espacio de diseño más allá de CTV podrá evaluarse por sus propios méritos. Los escépticos argumentan que más difícil: la activación de un covenant acotado consumirá el capital político que de otro modo estaría disponible para una propuesta más ambiciosa, y Bitcoin quedará con un covenant parcial que resulta inadecuado para las construcciones que OP_CAT habría habilitado. Ambas posiciones son plausibles. La evidencia histórica es escasa porque Bitcoin no ha publicado una actualización desde 2021. ## Implicaciones para BTCFi Para los builders de BTCFi, la pregunta práctica es cómo planificar la asignación de capital y hoja de ruta frente a la incertidumbre. Tres orientaciones parecen defendibles. La primera es construir contra el conjunto de scripts actual. BitVM2 en producción en Citrea demuestra que una mínima confianza significativa es alcanzable sin ningún nuevo opcode, al precio de una huella on-chain sustancialmente mayor. Los equipos que necesiten publicar en 2026\~2027 no pueden condicionar su hoja de ruta a la activación. La segunda es construir teniendo CTV+CSFS como objetivo blando. Los productos de vault, los venues basados en channel factories y las aplicaciones con uso intensivo de DLCs se benefician desproporcionadamente de la activación, y sus diseños pueden estructurarse para que una versión con covenants sea una actualización limpia respecto a una versión con transacciones prefirmadas. La desventaja es que la versión con transacciones prefirmadas sigue siendo frágil, y los usuarios soportan esa fragilidad hasta la activación. La tercera es construir contra el espacio de diseño más profundo de OP_CAT, bajo la suposición de que una vez que un covenant se activa, el segundo se vuelve políticamente más fácil. Es una apuesta a más largo plazo. Además, depende de una cadena de contrafactuales — activación de CTV, debate posterior sobre OP_CAT, activación del propio OP_CAT — cada uno de los cuales es contingente. Las preguntas abiertas que vigilaríamos durante el resto de 2026 y a lo largo de 2027 son acotadas y respondibles. ¿Se publica el cliente alternativo, y responde Core con su propia lógica de señalización o con un rechazo explícito? ¿Cuál es el comportamiento de señalización de los mineros en la primera ventana de 2016 bloques tras el inicio de marzo de 2026? ¿Las objeciones técnicas específicas de los colaboradores de Core se publican en una forma evaluable, o el debate permanece difuso? ¿Y la coalición de apoyo — wallets, exchanges, custodios — se compromete públicamente antes de que se abra la ventana de señalización, o después? Si la respuesta a esas preguntas es "el cliente alternativo se publica, los mineros señalizan por encima del 90%, y Core fusiona el cambio en respuesta," Bitcoin habrá descubierto una nueva vía de actualización, y BTCFi tendrá un espacio de diseño sustancialmente diferente contra el que construir en un plazo de dieciocho meses. Si la respuesta es "el cliente se publica, la señalización fracasa, y el debate se reinicia," habremos confirmado que el proceso de actualización de Bitcoin no es meramente conservador sino estructuralmente bloqueado, y la hoja de ruta de BTCFi necesitará asumir una estasis del script en el futuro previsible. Ambos resultados son informativos. El que sería peor es el tercero: el cliente se publica, los mineros señalizan, y la escisión de cadena resultante revela que la gobernanza de Bitcoin era menos coherente de lo que cualquier facción suponía. Ese resultado no es el más probable, pero es el que más recompensa prestarle atención ahora.