Un covenant est une condition qui peut déterminer non seulement qui a le droit de dépenser des bitcoins, mais aussi la forme de leur prochain transfert. Il pourrait par exemple imposer un passage par une sortie assortie d’un délai. Cette restriction fait partie des règles de dépense de la sortie ; ce n’est pas un simple réglage d’application. Covenants désigne une famille de constructions et de propositions, pas une fonction disponible dans tous les portefeuilles.
Anna épargne en Bitcoin. Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. Le solde affiché par son portefeuille est constitué de sorties encore non dépensées de transactions antérieures, les UTXO. Chaque sortie contient un montant et les conditions permettant de le dépenser, inscrites dans un petit programme appelé Bitcoin Script. Une signature numérique prouve l’autorisation d’un paiement à l’aide d’une clé privée, une valeur numérique secrète, sans révéler cette clé. Multisig peut exiger plusieurs signatures, tandis qu’un Timelock ajoute une condition d’attente. Un covenant peut aussi restreindre la forme de la prochaine transaction, par exemple les sorties vers lesquelles les fonds doivent aller. Même un voleur possédant la bonne clé devrait respecter cette règle. Il faut toutefois examiner toutes les voies de dépense : si une autre branche permet de contourner la restriction, on ne peut pas compter sur elle. [1] [5] [9] [11]
Imaginons qu’Anna place son épargne dans un coffre avec délai. Il ne s’agit pas ici d’un appareil particulier, mais d’un agencement de règles de dépense. Sa clé habituelle pourrait lancer un retrait, mais les fonds passeraient d’abord dans une sortie d’attente. Ils ne pourraient poursuivre leur route vers le destinataire prévu qu’après le délai. Si un voleur lançait le retrait, Anna pourrait utiliser pendant l’attente une voie de secours préparée à l’avance pour placer les fonds sous des conditions plus sûres. Elle doit cependant détecter le retrait et faire confirmer la transaction de secours dans un bloc à temps. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. Ce mécanisme n’annule pas un paiement terminé et ne sauve pas automatiquement les fonds sans intervention. Les possibilités exactes dépendent de la conception du coffre. [6] [10]
Lorsqu’une application promet de retarder un retrait, ce peut être une simple promesse de son exploitant. Une règle inscrite dans un script Bitcoin est, elle, contrôlée par les nœuds : des logiciels qui vérifient les transactions selon les règles communes du réseau. Dans une construction covenant adaptée, ils doivent rejeter le transfert qui enfreint la restriction. Un outil proposé est OP_CHECKTEMPLATEVERIFY, ou CTV, décrit dans BIP119 ; un BIP est un document présentant une proposition pour Bitcoin. CTV comparerait le hash de certaines données de la transaction à une empreinte enregistrée à l’avance. Ici, le hash est une courte empreinte vérifiable des données. Modifier un destinataire ou un montant imposé changerait cette empreinte : le transfert ne correspondant pas au modèle échouerait au contrôle. Le seul mot « coffre » dans une application ne garantit pas cette protection. [2]
CTV lie une transaction à un modèle préparé à l’avance, y compris ses sorties. D’autres approches sont aussi étudiées. BIP443 propose OP_CHECKCONTRACTVERIFY pour des sorties portant un engagement vérifiable sur certaines données. Un engagement signifie ici qu’on ne peut pas remplacer ensuite une valeur par une autre sans que le contrôle détecte l’écart. Les données peuvent décrire l’état d’un contrat, par exemple la répartition actuelle de fonds partagés ; la sortie suivante pourrait porter un état mis à jour si les règles prévues sont respectées. CTV et cette proposition ne sont donc pas deux noms pour la même chose. Pour chaque mécanisme, il faut savoir ce qui doit être fixé à l’avance, ce qui peut évoluer ensuite et quels autres outils sont nécessaires à l’ensemble. [2] [7]
Une construction récursive peut exiger que la sortie suivante porte à nouveau une restriction. La règle se prolonge ainsi sur plusieurs transactions, par exemple pendant l’évolution de l’état d’un contrat. Il ne s’agit pas d’une boucle infinie lors de la vérification d’un script. Russell O’Connor et Marta Piekarska ont décrit de telles constructions dans leur étude de 2017 ; la possibilité de répétition dépend de la proposition considérée. [3]
Certaines restrictions peuvent être préparées avec des transactions présignées, des verrous temporels et une gestion des clés. Cette organisation peut toutefois demander d’effacer une clé de manière fiable, de conserver toutes les transactions ou de poursuivre la coopération. Un Multisig reposant sur le refus d’un autre signataire d’autoriser un paiement inadapté introduit une autre hypothèse de confiance. Une expérience similaire n’implique pas les mêmes garanties ni les mêmes possibilités de récupération. [5] [6]
Au-delà des coffres, les travaux portent sur des UTXO partagés et des paiements dont le règlement est étalé dans le temps. L’objectif peut être de réduire la coopération permanente ou de mieux utiliser l’espace des blocs. Cela ne promet ni transactions illimitées ni frais toujours faibles. Il faut aussi prévoir le départ individuel d’un participant, l’indisponibilité des autres et le paiement des frais lorsque le réseau est encombré. [2] [7]
Au 17 octobre 2026, BIP119 et BIP443 ont le statut Draft : ce sont des propositions en cours d’élaboration. L’ancien BIP345, OP_VAULT, est Closed et indique BIP443 comme remplacement proposé. La clôture de ce document ne signifie pas la fin des recherches sur les coffres. De même, attribuer un numéro BIP ne signifie pas que le réseau a adopté le changement. Un réseau de test ou un portefeuille de démonstration peut montrer une fonction alors que les règles du réseau principal de Bitcoin, mainnet, restent inchangées. Si un service propose un coffre utilisant des covenants, vérifiez sur quel réseau et avec quelles règles il fonctionne réellement. [6] [8]
Un modèle trop étroit ou une erreur de montant, de script ou de gestion des frais peut empêcher la dépense prévue. De nouvelles opérations élargissent aussi ce que l’implémentation doit vérifier en toute sécurité. Les changements de consensus doivent donc être évalués selon leur spécification précise et leur comportement en cas d’erreur. Un covenant ne donne pas, à lui seul, à un tiers le droit de modifier rétroactivement les conditions de vos UTXO existants. [4] [8]
Pour une solution donnée, demandez qui peut déclencher le retrait ou le secours, combien de temps reste disponible pour réagir et si quelqu’un doit surveiller la chaîne en permanence. Vérifiez aussi les sauvegardes, les frais, les possibilités de sortie et le réseau où elle fonctionne réellement. Les Covenants peuvent renforcer votre contrôle sur vos fonds ; le mot dans une description commerciale ne le prouve pas. [3] [6]
Pour une vision complète, lisez aussi Bitcoin Script, OP_CHECKTEMPLATEVERIFY, Timelock, Règles de consensus, UTXO, Multisig. Cette entrée est également citée par OP_CHECKTEMPLATEVERIFY, Bitcoin Vault, OP_CAT, Ark.