Bitcoin Vault es una construcción de custodia con etapas de retiro separadas. Al iniciarse el retiro, comienza un periodo en que las reglas permiten trasladar los fondos a una vía de recuperación segura. No es el nombre de un único opcode activado ni otro nombre para una cartera de hardware.
En una cartera ordinaria de una firma, un ladrón con la clave puede crear un pago directo. Un vault pretende limitar esa salida inmediata: la clave operativa inicia el proceso, pero no debería eludir por sí sola la espera y la vía de recuperación. La pregunta central es qué combinaciones pueden pagar directamente y cuáles requieren un estado intermedio. La etiqueta vault o una transferencia demorada por la aplicación no demuestran imposición en la blockchain. [BIP 345 — OP_VAULT]
El modelo distingue el UTXO depositado, el output intermedio unvault confirmado y el pago completado. Si un output intermedio confirmado en el bloque H exige 144 bloques para la rama normal, esta podrá usarse como mínimo en H+144, cumpliendo las demás condiciones. La rama de recuperación debe permitir intervenir antes. No son exactamente 24 horas ni una reversión automática: la intervención eficaz debe adelantarse al gasto final confirmado. [BIP 345 — OP_VAULT] [BIP 112 — CHECKSEQUENCEVERIFY]
Algunas construcciones usan reglas actuales y transacciones prefirmadas. Restringen gastos alternativos exigiendo borrar de forma segura las claves de firma de un solo uso, o que otras partes independientes autoricen una alternativa. La red no demuestra por sí misma el borrado. Una copia secreta conservada puede eludir la vía prevista. Las transacciones prefirmadas también forman parte de la recuperación: un seed por sí solo puede no recrear las firmas de una clave eliminada. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
La especificación Revault distingue stakeholders, managers y cosigning servers. Su output deposit utiliza claves N-of-N de stakeholders; el output unvault permite la vía de stakeholders o la de managers y cosigners tras X bloques. Cancel devuelve el output a la política deposit, mientras emergency lo envía a Emergency Deep Vault. También existe un bypass firmado por stakeholders. Por tanto, este modelo no garantiza demora si se comprometen todas sus claves ni describe todos los vaults. [Revault — Transaction specification]
En la revisión del 8 de septiembre de 2026, BIP 345 figura como Closed y señala BIP 443 como Proposed-Replacement. Originalmente combinaba OP_VAULT y OP_VAULT_RECOVER con OP_CHECKTEMPLATEVERIFY. BIP 443 propone el más general OP_CHECKCONTRACTVERIFY, u OP_CCV, y es Draft; no se ha determinado su activación. BIP 119 también es Draft. Un número BIP, una implementación de prueba o un ejemplo publicado de vault no demuestran por sí mismos la activación de esas reglas en Bitcoin mainnet. [BIP 345 — OP_VAULT] [BIP 443 — OP_CHECKCONTRACTVERIFY] [BIP 119 — CHECKTEMPLATEVERIFY]
Un monitor debe reconocer un retiro inesperado, no solo ver una transacción. Responder requiere una transacción de rescate válida, red accesible y comisiones suficientes. Entrar en el mempool no es confirmarse; congestión, pinning o una estrategia inadecuada para elevar comisiones pueden consumir la ventana. Revault especifica CPFP y, para ciertos rescates, ALL | ANYONECANPAY para añadir inputs que paguen comisiones. Sus tarifas históricas no recomiendan la comisión actual. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
Redirigir hacia un script de recuperación solo ayuda si el propietario autorizado puede satisfacer después sus condiciones. Claves inaccesibles, configuración ausente o transacciones prefirmadas perdidas pueden sustituir el robo por un bloqueo propio permanente. Una rama de rescate demasiado fácil de activar puede permitir hostigamiento cancelando retiros repetidamente. Distinga el permiso para activar el traslado protector del permiso para gastar desde su destino, y verifique ambos roles. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
La verificación debe enumerar todas las vías de retiro y bypass, supuestos de consenso, respaldos necesarios y tiempo de respuesta. Una configuración de prueba separada debe cubrir retiro normal, intento prematuro, unvault inesperado, fallo del monitor y falta de fondos para comisiones. Los resultados deben distinguir firma válida, aceptación por el mempool y confirmación. Demostrar un escenario no prueba seguras todas las ramas; estos modelos no indican depositar fondos reales en un script experimental. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
Para obtener la imagen más completa, lee esta entrada junto con Covenants de Bitcoin, OP_CHECKTEMPLATEVERIFY, Timelock, Multisig, Bitcoin Inheritance Plan, Autocustodia. También enlazan con esta entrada Covenants de Bitcoin, OP_CHECKTEMPLATEVERIFY, Dead Man’s Switch.