Covenants en Bitcoin

Qué es un covenant

En su sentido más general, un covenant es una restricción que un output de Bitcoin impone sobre la forma en que puede gastarse en el futuro. Un script tradicional responde a "quién puede gastar este UTXO". Un covenant añade otra dimensión: "hacia dónde, cuándo y en qué condiciones puede gastarse".

Por ejemplo, un covenant podría expresar:

• "Este UTXO solo puede gastarse hacia una dirección de bóveda específica."
• "Si alguien intenta gastarlo, debe haber un periodo de espera de 144 bloques antes de que sea final."
• "El output resultante debe tener exactamente este formato e importe."

El término es un préstamo del derecho inmobiliario anglosajón, donde un covenant es una cláusula que sigue a la propiedad aunque cambie de manos.

Por qué los covenants no existen hoy en Bitcoin

El diseño actual de Bitcoin Script no permite que un script inspeccione la transacción que lo está gastando. Los opcodes de verificación de firmas comprueban que una firma cubre el hash de la transacción, pero el script no puede "leer" los outputs que la transacción está creando ni imponer condiciones sobre ellos.

Curiosidad: algunos opcodes originales como OP_CAT (concatenar dos cadenas en la pila) habrían permitido construir covenants primitivos. Satoshi los desactivó en 2010 por motivos de seguridad, y su reactivación es hoy parte del debate.

Propuestas activas

OP_CHECKTEMPLATEVERIFY (CTV / BIP-119)

Propuesto por Jeremy Rubin, CTV introduce un opcode que obliga a que la transacción que gasta el UTXO tenga una forma exacta: un conjunto específico de outputs comprometidos mediante un hash fijo en el script. Es deliberadamente limitado: no permite inspeccionar la transacción libremente, solo comparar su forma contra una plantilla. Habilita bóvedas, pagos congestion-resistentes y joinpools.

SIGHASH_ANYPREVOUT (APO / BIP-118)

APO permite que una firma sea válida para cualquier UTXO con el mismo script, liberándola del outpoint concreto. Es clave para eltoo (LN-Symmetry): un rediseño de los canales Lightning que elimina la necesidad de revocar estados antiguos con penalizaciones, haciendo que el último estado siempre sobrescriba al anterior. No es un covenant "puro", pero habilita construcciones similares.

OP_VAULT (BIP-345)

Propuesto por James O'Beirne, introduce primitivas específicas para bóvedas: fondos con un periodo de espera obligatorio antes de moverse, durante el cual el propietario puede abortar el gasto si detecta compromiso de su clave caliente. Especializado, no general.

CSFS + CAT: el enfoque general

OP_CHECKSIGFROMSTACK (CSFS) verifica una firma sobre un mensaje arbitrario tomado de la pila. OP_CAT concatena dos elementos. Combinadas, permiten construir covenants "emulados" mediante técnicas criptográficas, habilitando construcciones muy potentes a costa de mayor complejidad de razonamiento.

Casos de uso que habilitarían

• Bóvedas (vaults): proteger fondos con un periodo de espera y una ruta de emergencia si alguien intenta robarlos.
• Canales Lightning más eficientes: eltoo simplificaría la lógica de estados en Lightning.
• Ark y joinpools: esquemas de escalado donde muchos usuarios comparten un UTXO on-chain con salidas unilaterales garantizadas.
• Pagos recurrentes: compromisos de pago predecibles sin necesidad de terceros.

El debate en la comunidad

A favor

• Habilitan mejor autocustodia (bóvedas) y mayor seguridad práctica.
• Permiten soluciones de escalado nuevas sin cambiar la capa base.

En contra

• Añaden complejidad al consenso que es inmutable en la práctica: cualquier error es para siempre.
• Podrían habilitar "listas negras" sobre UTXOs, comprometiendo la fungibilidad.
• Algunas propuestas (CSFS+CAT) son tan generales que es difícil acotar su espacio de consecuencias.

A fecha de 2026, ninguna propuesta ha sido activada. El debate continúa en listas de correo, conferencias y en revisión de prototipos en testnet y signet.