Un covenant es una condición que puede determinar no solo quién puede gastar bitcoins, sino también cómo debe ser su siguiente transferencia. Por ejemplo, podría exigir que los fondos pasaran primero por una salida con un periodo de espera. La restricción forma parte de las reglas de gasto de esa salida, no es simplemente un ajuste de una aplicación. Covenants engloba una familia de construcciones y propuestas, no una función disponible en todas las carteras.
Anna guarda sus ahorros en Bitcoin. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. El saldo que muestra su cartera está formado por salidas aún no gastadas de transacciones anteriores, llamadas UTXO. Cada salida contiene un importe y las condiciones para gastarlo, escritas en un pequeño programa llamado Bitcoin Script. Una firma digital acredita la autorización de un pago mediante una clave privada, un valor numérico secreto, sin revelar esa clave. Multisig puede exigir varias firmas y Timelock añade una condición de espera. Un covenant también puede limitar la estructura de la siguiente transacción, por ejemplo las salidas a las que deben ir los fondos. Incluso un ladrón con la clave correcta tendría que cumplir esa regla. Pero importan todas las vías de gasto disponibles: si otra rama permite eludir la restricción, no se puede confiar en ella. [1] [5] [9] [11]
Imagina que Anna coloca sus ahorros en una bóveda con demora. Aquí bóveda no significa un dispositivo especial, sino una combinación de reglas de gasto. Su clave habitual podría iniciar una retirada, pero los fondos pasarían primero a una salida de espera. Solo después del plazo podrían continuar hacia el destinatario previsto. Si un ladrón iniciara la retirada, Anna podría usar durante la espera una vía de recuperación preparada de antemano y trasladar los fondos a unas condiciones más seguras. Tendría que detectar la retirada y conseguir que la transacción de recuperación se confirmara en un bloque a tiempo. Un bloque agrupa transacciones en un lote que se añade al historial compartido. Esto no revierte un pago completado ni rescata los fondos automáticamente sin intervención. Las posibilidades exactas dependen del diseño de la bóveda. [6] [10]
La promesa de una aplicación de retrasar una retirada puede ser solo una promesa de su operador. Una regla de un script de Bitcoin, en cambio, la comprueban los nodos: programas que verifican las transacciones según las reglas compartidas de la red. En una construcción covenant adecuada, deben rechazar cualquier transferencia que incumpla la restricción. Una herramienta propuesta es OP_CHECKTEMPLATEVERIFY, o CTV, descrita en BIP119; un BIP es un documento con una propuesta para Bitcoin. CTV compararía el hash de determinados datos de la transacción con una huella guardada de antemano. Aquí un hash puede entenderse como una breve huella verificable de unos datos. Cambiar el destinatario o el importe fijados cambiaría esa huella, y la transferencia que no coincidiera con la plantilla no superaría la comprobación. Llamar «bóveda» a algo dentro de una aplicación no garantiza este control. [2]
CTV vincula una transacción a una plantilla preparada de antemano, incluidas sus salidas. No es el único enfoque que se estudia. BIP443 propone OP_CHECKCONTRACTVERIFY para salidas que llevan un compromiso verificable con determinados datos. Compromiso significa aquí que no se puede sustituir después un valor por otro sin que la comprobación detecte la diferencia. Los datos pueden describir el estado de un contrato, por ejemplo el reparto actual de fondos compartidos; la siguiente salida podría llevar un estado actualizado si cumple las reglas establecidas. CTV y esta propuesta no son, por tanto, dos nombres de lo mismo. En cada diseño hay que distinguir qué debe fijarse de antemano, qué puede cambiar más tarde y qué otras herramientas necesita la construcción completa. [2] [7]
Una construcción recursiva puede exigir que la siguiente salida vuelva a incorporar una restricción. Así, la regla continúa a través de varias transacciones, por ejemplo mientras cambia el estado de un contrato. No significa un bucle infinito al comprobar un único script. Russell O’Connor y Marta Piekarska describieron estas construcciones en un trabajo de 2017; la posibilidad de repetir condiciones depende de cada propuesta. [3]
Algunas restricciones pueden prepararse con transacciones prefirmadas, bloqueos temporales y gestión de claves. Pero esa estructura puede exigir borrar una clave de manera fiable, conservar todas las transacciones o contar con más cooperación. Un Multisig donde otro firmante debe rechazar pagos inadecuados introduce una premisa de confianza diferente. Una experiencia similar no implica las mismas garantías ni las mismas opciones de recuperación. [5] [6]
Además de las bóvedas, se estudian UTXO compartidas y pagos cuya liquidación se distribuye en el tiempo. El objetivo puede ser reducir la cooperación continua o aprovechar mejor el espacio de los bloques. Eso no significa transacciones ilimitadas ni comisiones bajas garantizadas. El diseño también debe explicar la salida individual de un participante, la ausencia de otros y el pago de comisiones cuando la red está congestionada. [2] [7]
A 17 de octubre de 2026, BIP119 y BIP443 tienen estado Draft: son propuestas en desarrollo. La anterior BIP345, OP_VAULT, figura como Closed y señala BIP443 como sustitución propuesta. Cerrar ese documento no significa abandonar la investigación sobre bóvedas. Tampoco asignar un número BIP significa que la red haya adoptado el cambio. Una red de pruebas o una cartera de demostración pueden mostrar una función mientras las reglas de la red principal de Bitcoin, mainnet, siguen sin cambios. Si un servicio ofrece una bóveda basada en covenants, comprueba en qué red y bajo qué reglas funciona realmente. [6] [8]
Una plantilla demasiado estricta o un error en importes, scripts o gestión de comisiones puede impedir el gasto previsto. Añadir operaciones también amplía lo que una implementación debe validar con seguridad. Por eso los cambios de consenso deben evaluarse según su especificación exacta y su comportamiento ante fallos. Un covenant no concede por sí mismo a otra persona el derecho a modificar retroactivamente las condiciones de tus UTXO existentes. [4] [8]
Ante una solución concreta, pregunta quién puede iniciar la retirada o la recuperación, cuánto dura el plazo de reacción y si alguien debe vigilar continuamente la cadena. Revisa también las copias de seguridad, comisiones, vías de salida y la red donde funciona realmente. Covenants puede ampliar tu control sobre el dinero; la palabra en la descripción de un producto no demuestra ese control. [3] [6]
Para obtener la imagen más completa, lee esta entrada junto con Bitcoin Script, OP_CHECKTEMPLATEVERIFY, Timelock, Reglas de consenso, UTXO, Multisig. También enlazan con esta entrada OP_CHECKTEMPLATEVERIFY, Bitcoin Vault, OP_CAT, Ark.