Um covenant é uma condição que pode determinar não só quem pode gastar bitcoins, mas também como deverá ser a transferência seguinte. Pode, por exemplo, exigir que os fundos passem primeiro por uma saída com um período de espera. A restrição faz parte das regras de gasto dessa saída, não é apenas uma definição da aplicação. Covenants designa uma família de construções e propostas, não uma função disponível em todas as carteiras.
Anna guarda poupanças em Bitcoin. Uma carteira é uma aplicação ou um dispositivo para receber e enviar bitcoins. O saldo apresentado na carteira é composto por saídas ainda não gastas de transações anteriores, chamadas UTXO. Cada saída contém um montante e as condições para o gastar, escritas num pequeno programa chamado Bitcoin Script. Uma assinatura digital comprova a autorização de um pagamento por meio de uma chave privada, um valor numérico secreto, sem revelar essa chave. Multisig pode exigir várias assinaturas e Timelock acrescenta uma condição de espera. Um covenant também pode limitar a estrutura da transação seguinte, por exemplo as saídas para as quais os fundos devem seguir. Mesmo um ladrão com a chave correta teria de cumprir essa regra. Mas é preciso considerar todos os caminhos de gasto: se outro ramo permitir contornar a restrição, não se pode confiar nela. [1] [5] [9] [11]
Imagine que Anna coloca as poupanças num cofre com um prazo de espera. Aqui, cofre não é um aparelho especial, mas uma organização das regras de gasto. A chave habitual poderia iniciar um levantamento, mas os fundos passariam primeiro para uma saída de espera. Só depois do prazo poderiam seguir para o destinatário pretendido. Se um ladrão iniciasse o levantamento, Anna poderia usar durante a espera um caminho de recuperação preparado antecipadamente e colocar os fundos sob condições mais seguras. Teria, porém, de detetar o levantamento e conseguir a confirmação da transação de recuperação num bloco a tempo. Um bloco reúne transações num conjunto acrescentado ao histórico comum. Isto não desfaz um pagamento concluído nem salva os fundos automaticamente sem intervenção. As possibilidades exatas dependem do projeto do cofre. [6] [10]
A promessa de uma aplicação de adiar um levantamento pode ser apenas uma promessa do seu operador. Já uma regra num script Bitcoin é verificada pelos nós: programas que validam transações segundo as regras comuns da rede. Numa construção covenant adequada, devem rejeitar uma transferência que viole a restrição. Uma ferramenta proposta é OP_CHECKTEMPLATEVERIFY, ou CTV, descrita em BIP119; um BIP é um documento com uma proposta para Bitcoin. CTV compararia o hash de certos dados da transação com uma impressão digital guardada antecipadamente. Um hash é aqui uma impressão digital curta e verificável dos dados. Alterar um destinatário ou montante fixado mudaria essa impressão; uma transferência diferente do modelo não passaria na verificação. O nome «cofre» numa aplicação não garante este controlo. [2]
CTV vincula uma transação a um modelo preparado antecipadamente, incluindo as suas saídas. Não é a única abordagem em estudo. BIP443 propõe OP_CHECKCONTRACTVERIFY para saídas que transportam um compromisso verificável com determinados dados. Compromisso significa aqui que não se pode substituir depois um valor por outro sem a verificação detetar a diferença. Os dados podem descrever o estado de um contrato, por exemplo a distribuição atual de fundos partilhados; a saída seguinte poderia transportar um estado atualizado se respeitasse as regras previstas. CTV e esta proposta não são, portanto, dois nomes da mesma coisa. Em cada projeto, importa saber o que tem de ficar fixado antecipadamente, o que pode mudar depois e que outras ferramentas são necessárias para a construção completa. [2] [7]
Uma construção recursiva pode exigir que a saída seguinte volte a conter uma determinada restrição. A regra prossegue assim por várias transações, por exemplo enquanto o estado de um contrato muda gradualmente. Não significa um ciclo infinito ao verificar um único script. Russell O’Connor e Marta Piekarska descreveram estas construções num estudo de 2017; a possibilidade de repetição depende da proposta concreta. [3]
Algumas restrições podem ser preparadas com transações previamente assinadas, bloqueios temporais e gestão de chaves. Mas isso pode exigir apagar uma chave de forma fiável, conservar todas as transações ou manter a cooperação. Um Multisig que depende de outro signatário recusar um pagamento inadequado introduz outro pressuposto de confiança. Uma experiência semelhante não implica as mesmas garantias nem as mesmas opções de recuperação. [5] [6]
Além dos cofres, estudam-se UTXO partilhados e pagamentos cuja liquidação se distribui ao longo do tempo. O objetivo pode ser reduzir a cooperação contínua ou aproveitar melhor o espaço dos blocos. Isso não significa transações ilimitadas nem taxas baixas garantidas. O projeto também precisa de explicar a saída individual de um participante, a indisponibilidade dos restantes e o pagamento de taxas com a rede congestionada. [2] [7]
Em 17 de outubro de 2026, BIP119 e BIP443 têm estado Draft, ou seja, são propostas em desenvolvimento. O anterior BIP345, OP_VAULT, está Closed e indica BIP443 como substituição proposta. Encerrar esse documento não significa acabar com a investigação sobre cofres. Do mesmo modo, atribuir um número BIP não significa que a rede tenha adotado a alteração. Uma rede de testes ou uma carteira de demonstração pode mostrar uma função enquanto as regras da rede principal de Bitcoin, a mainnet, continuam inalteradas. Se um serviço oferecer um cofre baseado em covenants, confirme em que rede e segundo que regras funciona realmente. [6] [8]
Um modelo demasiado restrito ou um erro nos montantes, no script ou no pagamento de taxas pode impedir o gasto pretendido. Novas operações também ampliam aquilo que uma implementação tem de validar com segurança. Por isso, as alterações de consenso devem ser avaliadas pela especificação exata e pelo comportamento em caso de erro. Um covenant não dá, por si só, a outra pessoa o direito de alterar retroativamente as condições dos seus UTXO existentes. [4] [8]
Numa solução concreta, pergunte quem pode iniciar o levantamento ou a recuperação, quanto tempo existe para reagir e se alguém tem de vigiar continuamente a cadeia. Verifique também cópias de segurança, taxas, opções de saída e a rede onde funciona realmente. Os Covenants podem aumentar o controlo sobre o seu dinheiro; a palavra numa descrição comercial não prova esse controlo. [3] [6]
Para ter uma visão mais completa, leia este verbete junto com Bitcoin Script, OP_CHECKTEMPLATEVERIFY, Timelock, Regras de consenso, UTXO, Multisig. Também há referências a este verbete em OP_CHECKTEMPLATEVERIFY, Bitcoin Vault, OP_CAT, Ark.