Boltz

Commencez par le sens de l’échange. Pour alimenter un portefeuille Lightning à partir de bitcoins sur la chaîne principale, utilisez un Submarine Swap : vous payez on-chain, par une transaction inscrite dans la blockchain, et recevez par Lightning. Le Reverse Swap fonctionne à l’inverse. Vous payez une facture Lightning, une demande de paiement contenant les informations nécessaires, puis pouvez récupérer des fonds sur la chaîne. Un Chain Swap relie deux chaînes, comme Bitcoin et Liquid. Dans les deux derniers cas, votre application doit diffuser un claim, la transaction qui récupère réellement vos fonds. Le paiement ne termine donc pas votre part du travail. Sur Liquid, vous recevez du L-BTC, l’actif de ce réseau distinct, et non une sortie ordinaire sur la chaîne principale Bitcoin. Vérifiez aussi le réseau de destination avant de confirmer. [1]

Imaginez que le serveur vous communique une adresse et un montant. Sans autre contrôle, vous lui faites simplement confiance pour respecter l’échange convenu. Le client Boltz, l’application sur votre appareil, doit recalculer le montant et vérifier le hash de paiement de la facture Lightning. Ce hash est une empreinte calculée qui relie le paiement au bon swap. L’application vérifie également l’adresse et le script, les conditions qui précisent qui peut dépenser les fonds et quand. Avec Taproot, une manière de construire une sortie Bitcoin, elle contrôle aussi les clés et l’arbre de scripts, qui organise les conditions de dépense possibles. L’utilisateur n’a pas à faire ces calculs à la main ; il lui faut un client qui les effectue réellement. Le code ouvert de boltz-web-app permet un examen, mais ne prouve pas à lui seul qu’une autre intégration ou l’application chargée dans le navigateur est correcte. [5] [9]

Une adresse de swap n’est pas un compte sur lequel accumuler progressivement la somme nécessaire. La documentation Boltz demande une seule transaction lockup, le premier transfert qui verrouille les fonds selon les règles du swap. Les paiements suivants à la même adresse ne s’y ajoutent pas : seul le premier sert à l’échange. Si vous envoyez trop peu, ne versez donc pas automatiquement la différence. Pour un Chain Swap, le client peut proposer un nouveau devis fondé sur le montant reçu plutôt qu’un remboursement. Il doit rester assez de temps, la somme doit respecter les limites et aucune signature de refund, ou remboursement, ne doit avoir été créée. Les fonds disponibles du service comptent aussi. C’est une procédure particulière pour un Chain Swap mal financé, pas un moyen général de compléter tout transfert échoué. [2] [8]

Pour comparer les coûts, suivez l’ensemble du trajet plutôt que le seul pourcentage annoncé. Boltz facture son service, et les transactions sur les différentes chaînes ont leurs propres coûts. Dans un Reverse Swap, onchainAmount désigne, dans les données techniques, la somme que Boltz verrouille pour vous après prise en compte de ses frais de lockup. Ce n’est pas encore le montant net reçu dans votre portefeuille : vous payez aussi votre claim, la transaction de récupération. Dans un Chain Swap, votre transaction d’envoi initiale est également à votre charge. Comparez donc la dépense totale avec le montant finalement reçu. Les taux, minimums et limites dépendent du sens et de la paire de réseaux ; ils peuvent évoluer avec les conditions du réseau. Un ancien exemple publicitaire n’est pas un devis actuel. [6]

Si un Submarine Swap ou un Chain Swap échoue après l’envoi de vos fonds, leur récupération peut exiger une transaction de votre part. Il vous faut la clé de refund et les données du swap conservées. Avec Taproot, la coopération de Boltz peut permettre un key path refund plus rapide : un remboursement signé ensemble, sans attendre la condition temporelle. Sans coopération, le script path permet le retour prévu par le script après satisfaction du timelock, la restriction temporelle inscrite dans les règles de transaction. Cette possibilité ne diffuse rien toute seule : le client doit s’en charger. L’annulation d’un paiement Lightning encore non réglé dans un Reverse Swap est différente : elle libère les fonds en attente. Elle n’implique pas une récupération automatique après toute panne de l’application ou tout claim manqué. [3]

Dans un Reverse Swap, le règlement Lightning et la récupération de vos fonds sur la chaîne sont distincts. Le statut invoice.settled peut signifier que Boltz a obtenu le preimage, une valeur secrète permettant d’achever le paiement lié à son hash. Le serveur ne suit pas si votre application diffuse ensuite réellement le claim. Le client doit donc vérifier sa propre sortie, les fonds qui vous sont destinés, et les récupérer avant le timeout, le seuil après lequel l’autre partie peut les reprendre. Une application fermée, des données perdues ou des frais trop faibles peuvent compliquer l’achèvement. Une notification peut réveiller l’application, mais ne remplace pas une transaction diffusée. Jugez le résultat sur la réception effective, pas seulement sur un message vert. [1] [2]

Une sauvegarde classique du portefeuille ne contient pas forcément tout ce qu’exige un swap en cours. Le Boltz Rescue Key est un ensemble de mots de sauvegarde pour un mécanisme de restauration pris en charge. Swap Restore permet de reconstruire les swaps UTXO compatibles, qui utilisent des sorties individuelles de transactions encore non dépensées. Le client dérive un xpub, une clé publique étendue permettant de retrouver les swaps associés, ainsi que les clés privées correspondantes. Un claim exige aussi de reconstruire correctement le preimage. Un seed quelconque, le secret de départ d’une autre application, ne convient donc pas automatiquement : dérivation et format de restauration doivent correspondre. Les clés privées restent sur l’appareil. Le xpub envoyé ne permet pas de dépenser, mais révèle l’historique des swaps au serveur Boltz. Gardez donc les données du client concerné et les éventuels anciens fichiers refund en plus de la sauvegarde habituelle. [4] [2]

Une transaction peut apparaître sur le réseau avant son inclusion dans un bloc. Son acceptation à ce stade s’appelle 0-conf, c’est-à-dire sans confirmation. Selon sa documentation, Boltz n’accepte pas ces dépôts utilisateurs sur la chaîne principale Bitcoin en raison de l’adoption de full-RBF. Ces règles permettent, sous certaines conditions, de remplacer une transaction non confirmée par une autre payant davantage de frais, même sans signalement initial de cette possibilité. Dans un Reverse Swap, le destinataire assume au contraire le risque s’il accepte une transaction non confirmée. Les règles d’une paire de réseaux ne s’appliquent pas forcément aux autres. Une documentation accessible ne prouve pas non plus que le service dispose à cet instant des fonds nécessaires à votre transfert. Avant de payer, vérifiez les paramètres actuels, le temps restant et l’état du swap concerné. [7] [6]