Tornado Cash vs OFAC : comprendre l’arrêt d’appel

L’affaire Tornado Cash a débuté à l’été 2022 lorsque l’Office of Foreign Assets Control (OFAC) du Département américain du Trésor a placé quarante‑et‑une adresses Ethereum et trois contrats intelligents de Tornado Cash sur la liste des « Specially Designated Nationals » (SDN).

L’agence affirmait que l’outil de mixage avait servi à blanchir plusieurs centaines de millions de dollars provenant notamment du groupe de cyber‑pirates nord‑coréen Lazarus.

Pour la première fois, une autorité de sanctions visait non pas des personnes ou des entités juridiques, mais directement du code open‑source déployé sur une blockchain.

Six utilisateurs, menés par Joseph Van Loon, ont alors saisi la justice fédérale. Ils ne contestaient pas la réalité des flux illicites, mais la méthode : selon eux, un contrat intelligent immuable ne peut pas être assimilé à un « bien » au sens de l’International Emergency Economic Powers Act (IEEPA).

Une fois le code déployé et les clés administratives détruites, personne – pas même la DAO Tornado Cash – ne possède un droit exclusif ou un contrôle effectif sur le programme.

Le sanctionner reviendrait, plaidaient‑ils, à interdire l’usage d’un logiciel libre et à porter atteinte à leur liberté d’expression et de transaction.

Comment fonctionne réellement Tornado Cash ?

Tornado Cash est ce que l’on appelle un mixeur : l’utilisateur dépose une somme fixée (par exemple 1 ETH) dans le contrat intelligent et reçoit un « commitment hash ».

Après un délai variable, il peut renvoyer ce hash depuis n’importe quelle autre adresse et récupérer exactement la même somme, débarrassée du lien public on‑chain entre l’adresse d’envoi et l’adresse de retrait.

Le secret repose sur un arbre de Merkle et des preuves à divulgation nulle de connaissance (ZK‑SNARKs).

Une étape baptisée « cérémonie » a rendu le code immuable : les clés permettant de le modifier ont été détruites, garantissant l’autonomie totale du contrat.

Cette autonomie, pierre angulaire de nombreux protocoles DeFi, complique toute action coercitive classique.

Les arguments de l’OFAC

Le Trésor soutenait qu’il existait malgré tout une « propriété » : la DAO bénéficiait des frais de gaz et votait des paramètres de gouvernance.

Dès lors, faire fonctionner Tornado Cash revenait à fournir un service soumis à l’IEEPA.

L’agence invoquait en outre la nécessité de neutraliser un outil régulièrement cité dans des rapports d’enquête sur des hacks majeurs, dont celui du bridge Ronin (Axie Infinity).

La décision de la cour d’appel (février 2025)

La cour a remis les pendules à l’heure sur trois points essentiels.

• Notion de bien : un morceau de code auto‑exécutable qui n’est la propriété exclusive de personne ne peut être confondu avec un bien matériel ou financier traditionnel. L’OFAC a donc outrepassé son mandat en le traitant comme tel.

• Contrôle effectif : la DAO discute du produit des frais, mais n’a aucun moyen technique de bloquer ou de modifier les contrats en production. Le caractère immuable neutralise l’argument du contrôle.

• Proportionnalité : bloquer l’ensemble des adresses rendait impossible l’utilisation licite de l’outil (par exemple pour masquer un salaire versé en crypto ou protéger la confidentialité de donateurs). La régulation, rappelle la cour, doit concilier sécurité nationale et libertés fondamentales. ​

Conséquence : l’arrêt de première instance est annulé ; le dossier est renvoyé afin de déterminer si une mesure plus ciblée serait légalement défendable.

Les sanctions OFAC ne disparaissent pas totalement, mais leur fondement est fragilisé et la portée d’une sanction “sur le code” est désormais incertaine.

Pourquoi cette décision compte‑t‑elle ?

• Pour les développeurs : publier du code open‑source ne suffit plus à se dédouaner ; la question de la responsabilité civile ou pénale reste ouverte, mais la cour reconnaît qu’un créateur peut perdre tout contrôle sur l’outil qu’il lance.

• Pour les utilisateurs : l’arrêt ne légalise ni le blanchiment ni la fraude ; il rappelle toutefois que la simple utilisation d’un mixeur, en soi, n’est pas illicite tant qu’aucune preuve de mauvaise provenance des fonds n’est établie.

• Pour les régulateurs : il faudra distinguer clairement le logiciel (protégé par la liberté d’expression) des services commerciaux qui s’appuient sur ce logiciel. Une option évoquée est d’imposer des filtres listes‑noires au niveau des interfaces centralisées, plutôt qu’au niveau des contrats immuables eux‑mêmes.

Trois futurs possibles

• Durcissement américain – le Congrès pourrait amender l’IEEPA pour viser explicitement les outils de mixage automatisés.

• Approche européenne nuancée – un MiCA 2 ou des lignes directrices de l’ESMA pourraient distinguer le noyau open‑source et les opérateurs qui monétisent l’accès, imposant KYC à ces derniers.

• Auto‑régulation de l’écosystème – certains mixeurs envisagent déjà d’intégrer des filtres d’adresses sanctionnées afin de rester accessibles aux acteurs régulés.

Que faire si vous êtes concerné ?

• Plateformes et exchanges : ajoutez des oracles de sanctions on‑chain pour refuser automatiquement un retrait vers une adresse SDN restante.

• Entreprises : cartographiez vos transactions vers des protocoles anonymisants ; documentez la provenance des fonds en interne.

• Développeurs : formalisez vos licences (MIT, GPL) et limitez votre exposition en expliquant noir sur blanc que vous n’avez plus la main sur le code après déploiement.

Cet arrêt consacre un principe simple mais lourd de conséquences : sanctionner un programme immuable n’équivaut pas à sanctionner ses utilisateurs ou ses opérateurs, et la loi doit s’adapter aux réalités de la décentralisation plutôt que tordre ces réalités pour faire rentrer le code dans des catégories juridiques du XXᵉ siècle.

L’équilibre entre vie privée, innovation et lutte contre la criminalité financière reste fragile ; Tornado Cash n’en est probablement que le premier acte.

Si vous êtes concerné par cette nouvelle mesure, vous pouvez me poser toutes vos questions :