Création d'un prototype d'échange de bitcoin avec des « dark pools » privés

• Le code du prototype n'a pas encore été publié ni audité de manière indépendante.
• Les ordres sont appariés directement entre utilisateurs via des identités Nostr.

Un développeur identifié comme ian (@januszg_ sur X) a présenté le 21 juillet 2026, un prototype d'échange de bitcoin (BTC) conçu pour fonctionner comme un <> : un marché où les montants et les adresses des participants restent cachés tout au long de l'opération.

L'objectif est de transférer des bitcoins d'une personne à une autre sans laisser de trace sur le réseau et, en même temps, sans que l'une des parties (acheteur et vendeur) ait à faire confiance aveuglément à l'autre.

Pour y parvenir, deux éléments qui fonctionnent en parallèle sont combinés et connectés par un hash. Du côté de Bitcoin, le prototype utilise des statechains ---une technique qui permet de réassigner la clé de dépense d'un UTXO sans nécessiter de transaction sur la chaîne--- et s'appuie, selon l'auteur, sur le protocole Latch de Mercury Layer.

Le vendeur bloque sa position dans un ordre et cet ordre génère un hash unique, qui sert de fil conducteur à tout l'échange. Ce même hash entre en jeu de l'autre côté du système : le réseau de stablecoins.

Pour sa part, l'acheteur dépose ses stablecoins (ou <<n'importe quelle autre shitcoin>>, selon les propres mots de l'auteur) dans un contrat de garantie au sein d'un réseau avec des circuits de preuve de connaissance zéro (zk), une méthode cryptographique qui permet à une partie (le testeur) de prouver à une autre (le vérificateur) qu'une affirmation est vraie, sans révéler d'informations supplémentaires sur l'affirmation elle-même.

Ce contrat ne libère les fonds que si quelqu'un révèle la clé correspondant au hash généré par l'ordre du vendeur, ou les retourne automatiquement à l'acheteur si un délai déterminé expire sans que cela se produise.

C'est ici qu'intervient le troisième élément du design : un co-signataire qui ne participe pas à la négociation ni ne signe quoi que ce soit de sa propre initiative, mais agit uniquement lorsque les deux parties le lui indiquent.

Une fois que le vendeur vérifie que les stablecoins ont été déposés dans le contrat, il autorise le co-signataire à compléter le transfert du bitcoin ; l'acheteur fait de même de l'autre côté.

Avec les deux confirmations, le co-signataire réassigne la clé de dépense du statechain à l'acheteur et supprime la copie qu'il partageait avec le vendeur.

Ce n'est qu'après cette suppression que la clé permettant au vendeur de réclamer les stablecoins est révélée. C'est là que l'échange se complète.

Cette dernière étape laisse une condition de confiance que l'auteur lui-même reconnaît : l'acheteur doit faire confiance au co-signataire pour qu'il ait effectivement supprimé sa clé une fois l'opération terminée.

Tout ce mécanisme d'échange résout le problème de déplacer les actifs sans trace, mais ne dit encore rien sur la manière dont deux personnes parviennent à convenir d'une opération. Pour cela, le développeur a construit par-dessus un protocole de cotations (RFQ) basé sur des identités Nostr.

Chaque utilisateur crée une identité (npub) et publie des ordres d'achat ou de vente en montrant uniquement cette identité et le montant de l'ordre, sans révéler son adresse bitcoin ni d'autres données personnelles.

Il convient de préciser qu'à la différence des montants et des adresses, le npub de l'utilisateur reste visible pour les autres participants du livre d'ordres : ce que le design cache, c'est l'adresse bitcoin et les informations personnelles, pas l'identité pseudonyme sur Nostr.

Lorsque quelqu'un trouve une offre qui lui convient, il envoie une cotation chiffrée avec le montant et le prix exacts, que seule la contrepartie de cette opération spécifique peut lire.

Le résultat, selon la description de l'auteur, est que du côté de Bitcoin, il n'existe aucune transaction sur la chaîne, tandis que du côté du réseau zk, ce qui reste visible ce sont uniquement les hashes des entrées et des sorties, sans qu'il soit même possible de déterminer quel actif a été échangé.

Le propre ian a qualifié le design, dans son évaluation personnelle, d'extrêmement préservateur de la vie privée et a annoncé qu'il travaillera sur des versions plus optimisées du protocole et qu'il prévoit de publier le code à l'avenir, sans préciser de date.

Avertissement : Ce contenu est fourni à des fins de communication et d'information générale uniquement et ne constitue en aucun cas un conseil financier, d'investissement, juridique ou fiscal. Les événements, récompenses, événements en ligne ou toute information mentionnée dans ce document ne doivent pas être considérés comme une recommandation, une sollicitation ou une invitation à acheter, vendre, échanger ou traiter de quelque manière que ce soit des actifs crypto, ni à utiliser un quelconque service. Les actifs crypto sont très volatils et peuvent entraîner des pertes. Les services et événements en ligne de WEEX peuvent ne pas être disponibles dans toutes les régions et sont soumis aux lois, réglementations et conditions d'éligibilité applicables. Il vous appartient de veiller à ce que votre utilisation des services WEEX respecte la législation locale et d'évaluer soigneusement les risques avant de participer à toute activité liée aux cryptomonnaies.