Contrats sur Bitcoin : DLCs et prêts sans remise des clés

Curiosité

1. Comment un contrat peut-il être exécuté sur Bitcoin sans que l’oracle ne sache qui parie ?
2. Pourquoi un DLC n’a-t-il besoin d’aucun flux de prix sur la blockchain ?
3. Qu’advient-il d’une position sur un produit dérivé si l’oracle se déconnecte ou ment ?

Explorer

Partie IDiscreet Log Contracts : les oracles à la manière de Bitcoin

1. Thaddeus Dryja a proposé les Discreet Log Contracts (DLC) en juin 2017 et les a présentés à la conférence Scaling Bitcoin en novembre de la même année. L’innovation principale réside dans un schéma d’engagement multipartite où les participants verrouillent des fonds dans une sortie multisignature tout en pré-signant des transactions pour chaque résultat possible. Aucun participant ne détient l’ensemble des signatures nécessaires pour dépenser les fonds, ce qui garantit que personne ne peut revendiquer unilatéralement le montant total.
2. L’oracle annonce à l’avance un nonce public pour un événement futur. À partir de ce nonce et de la clé publique de l’oracle, n’importe qui peut calculer, pour chaque résultat possible, le point auquel correspondra la signature finale de l’oracle. Les parties utilisent ces points pour verrouiller chaque transaction d’exécution de contrat pré-signée, de sorte que chacune ne puisse être finalisée qu’avec la signature de l’oracle concernant son propre résultat. L’oracle ne signe que le résultat ; il ne voit jamais le contrat et n’a pas besoin de savoir qu’il existe.
3. Lorsque l’oracle publie sa signature sur le résultat réel, la transaction correspondante peut être finalisée et diffusée, et verse les montants convenus. Les transactions relatives aux autres résultats restent verrouillées, car l’oracle ne signe jamais ces résultats ; signer deux résultats pour un même événement révélerait sa clé privée. Une transaction de remboursement assortie d’un timelock restitue les fonds si l’oracle ne signe jamais.
4. En revanche, les oracles DeFi sur Ethereum publient généralement des données de prix on-chain, où les contrats les lisent. Les utilisateurs dépendent des opérateurs de ces flux, et un flux obsolète ou manipulé fait exécuter les contrats sur des données erronées. Les DLC évitent cela en réglant les résultats off-chain au moyen de signatures, ne laissant aucun flux de prix manipulable sur la blockchain elle-même.
5. Les DLC permettent de créer des instruments financiers complexes, tels que des dérivés et des prêts garantis, directement sur Bitcoin, sans intermédiaire custodial. Comme le collatéral reste dans un séquestre multisignature contrôlé par les participants et vérifié par des signatures d’oracle, le risque de contrepartie est nettement réduit par rapport aux plateformes d’échange centralisées. Le protocole gère la logique de règlement au moyen d’engagements cryptographiques, plutôt que de compter sur une autorité centrale pour faire respecter les conditions ou débloquer les fonds.
6. Le principal compromis réside dans la dépendance à la disponibilité de l’oracle et à son honnêteté quant aux données elles-mêmes. Si un oracle ne peut ni voler les fonds ni connaître les détails des contrats, il peut néanmoins mentir sur le résultat en signant des données incorrectes. Toutefois, ce mensonge étant publiquement vérifiable par comparaison avec d’autres sources, un oracle malveillant s’expose à une atteinte à sa réputation. Ce modèle déplace la confiance des entités dépositaires vers la vérification cryptographique d’événements externes.

Partie IIPrêts garantis par du bitcoin sans renoncer à ses clés

7. La DeFi a instauré le prêt avec collatéral, mais des plateformes centralisées comme Celsius et BlockFi conservaient les bitcoins de leurs clients dans leurs propres portefeuilles. Lorsque toutes deux ont fait faillite en 2022, ces fonds se sont retrouvés bloqués dans les procédures d’insolvabilité. Cet échec a mis en évidence le risque central du prêt custodial : si l’intermédiaire contrôle les clés, un effondrement de son bilan ou une erreur opérationnelle peut geler ou détruire les actifs des utilisateurs, quel que soit l’état du prêt.
8. Les architectures natives de Bitcoin conservent le collatéral dans un séquestre multisignature on-chain ; certaines utilisent des Discreet Log Contracts (DLC), d’autres un multisig avec des transactions pré-signées. Dans ces structures, les fonds sont verrouillés dans des sorties dont la dépense exige les signatures de plusieurs parties. L’emprunteur en conserve la propriété jusqu’à ce que le remboursement soit vérifié, et la liquidation n’a lieu que lorsque des conditions prédéfinies, telles que des seuils de prix, sont remplies via des signatures d’oracle. Cela supprime la nécessité d’un dépositaire pour conserver l’actif en fonctionnement normal.
9. Firefish utilise un séquestre 3-of-3 avec cinq transactions pré-signées : le collatéral ne peut emprunter que des chemins convenus à l’avance, comme le remboursement, la liquidation ou la restitution, et Firefish, qui agit comme oracle de prix et de paiement, ajoute la signature finale. La clé de l’emprunteur signe une seule fois, puis est détruite ; les prêteurs n’en détiennent aucune. Titulaire d’une licence MiCA, Firefish a ajouté des prêts en USDT au premier trimestre 2026. Cette conception limite chaque partie à des issues convenues à l’avance, au lieu de donner à quiconque un contrôle libre.
10. Tous les protocoles n’ont pas conservé cette architecture. En novembre 2025, Lava a annoncé abandonner les modèles non-custodial basés sur les DLC au profit de modèles de garde traditionnels. Les utilisateurs se sont demandé qui contrôlait désormais leur collatéral. Ce revirement illustre la tension entre simplicité opérationnelle et garanties de sécurité propres aux mécanismes de séquestre en auto-conservation.
11. Trois facteurs précis déterminent la sécurité de toute structure de prêt garanti par du bitcoin : qui peut déplacer le collatéral, comment les oracles déclenchent la liquidation, et ce qu’il advient des fonds des utilisateurs si le prêteur disparaît. Dans une conception 3-of-3 robuste, aucune entité ne dispose d’un contrôle unilatéral. Un oracle ne peut pas s’emparer directement du collatéral, mais un prix erroné peut déclencher une liquidation abusive.
12. Ouvrez un explorateur de blocs et examinez une transaction comportant une sortie multisignature. Identifiez les conditions du script pour dépenser cet UTXO. Notez combien de signatures sont nécessaires et quelles parties les contrôlent. Cet examen concret révèle si un protocole de prêt répartit réellement la gestion des clés ou la concentre au sein d’une seule entité dépositaire, ce qui fournit une preuve directe du niveau de sécurité du collatéral.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• T. Dryja, 'Discreet Log Contracts' (June 2017)
• Scaling Bitcoin 2017 presentation by T. Dryja (November 2017)
• DLC specifications, github.com/discreetlogcontracts
• DLC specifications (github.com/discreetlogcontracts)
• Firefish Q1 2026 update
• Blockspace reporting on Lava (2025)
• Celsius bankruptcy reporting (2022)