Bitcoin Vault é uma construção de custódia com etapas de saque separadas. O início abre um período no qual suas regras permitem mover os fundos para uma via segura de recuperação. Não é o nome de um único opcode ativado nem apenas outro termo para carteira de hardware.
Em uma carteira comum de assinatura única, um ladrão com a chave pode criar um pagamento direto. O vault procura limitar essa saída imediata: a chave operacional inicia o processo, mas não deve sozinha contornar a espera e a recuperação. A questão é quais combinações de chaves pagam diretamente e quais exigem um estado intermediário. O rótulo vault ou uma transferência adiada pelo aplicativo não provam imposição pela blockchain. [BIP 345 — OP_VAULT]
O modelo distingue UTXO depositado, saída intermediária unvault confirmada e pagamento concluído. Se a saída intermediária confirmada no bloco H exige 144 blocos no caminho normal, ele pode ser usado no mínimo em H+144, respeitadas as demais condições. O caminho de recuperação deve permitir intervenção anterior. Isso não significa exatamente 24 horas nem reversão automática: a intervenção eficaz precisa anteceder o gasto final confirmado. [BIP 345 — OP_VAULT] [BIP 112 — CHECKSEQUENCEVERIFY]
Algumas construções usam regras atuais e transações pré-assinadas. Limitam gastos alternativos exigindo apagar com segurança as chaves de assinatura de uso único, ou a autorização de outras partes independentes. A rede não comprova por si mesma a exclusão de chaves. Uma cópia secreta preservada pode contornar o caminho previsto. Transações pré-assinadas também integram a recuperação: um seed sozinho pode não recriar assinaturas de uma chave já apagada. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
A especificação Revault distingue stakeholders, managers e cosigning servers. Sua saída deposit usa chaves N-of-N de stakeholders; a saída unvault permite esse caminho ou o de managers e cosigners após X blocos. Cancel devolve a saída à política deposit, enquanto emergency leva a Emergency Deep Vault. Existe também um bypass assinado por stakeholders. Portanto, esse modelo não garante atraso se todas as chaves de stakeholders forem comprometidas e não descreve todos os vaults. [Revault — Transaction specification]
Na revisão de 8 de setembro de 2026, BIP 345 está Closed e indica BIP 443 como Proposed-Replacement. Originalmente combinava OP_VAULT e OP_VAULT_RECOVER com OP_CHECKTEMPLATEVERIFY. BIP 443 propõe o mais geral OP_CHECKCONTRACTVERIFY, ou OP_CCV, e está Draft; seu mecanismo de ativação não foi definido. BIP 119 também está Draft. Um número BIP, implementação de teste ou exemplo publicado de vault não comprovam por si só a ativação dessas regras no Bitcoin mainnet. [BIP 345 — OP_VAULT] [BIP 443 — OP_CHECKCONTRACTVERIFY] [BIP 119 — CHECKTEMPLATEVERIFY]
Um monitor deve reconhecer um saque inesperado, não apenas observar uma transação. A reação exige transação de resgate válida, rede acessível e taxas suficientes. Enviar ao mempool não é confirmar; congestionamento, pinning ou estratégia inadequada de aumento de taxas podem consumir a janela. Revault especifica CPFP e, em alguns resgates, ALL | ANYONECANPAY para acrescentar entradas que paguem taxas. Suas taxas históricas não são recomendações para hoje. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
Redirecionar para um script de recuperação só ajuda se o proprietário autorizado conseguir cumprir suas condições depois. Chaves indisponíveis, configuração ausente ou pré-assinaturas perdidas podem trocar o roubo por bloqueio permanente do próprio dono. Um caminho de resgate fácil demais de acionar também pode permitir assédio por cancelamentos repetidos. Separe a autorização de iniciar o movimento protetor da autorização de gastar no destino e verifique ambos os papéis. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
A verificação deve listar todos os caminhos de saque e bypass, pressupostos de consenso, backups necessários e tempo de resposta. Um ambiente de teste separado deve cobrir saque normal, tentativa prematura, unvault inesperado, falha do monitor e ausência de fundos para taxas. Os resultados precisam distinguir assinatura válida, aceitação no mempool e confirmação. Uma demonstração bem-sucedida não prova todas as ramificações seguras; estes modelos não instruem a depositar fundos reais num script experimental. [BIP 345 — OP_VAULT] [Revault — Transaction specification]
Para ter uma visão mais completa, leia este verbete junto com Bitcoin covenants, OP_CHECKTEMPLATEVERIFY, Timelock, Multisig, Bitcoin Inheritance Plan, Autocustódia. Também há referências a este verbete em Bitcoin covenants, OP_CHECKTEMPLATEVERIFY, Dead Man’s Switch.