THORChain a interrompu toutes les opérations de rotation des coffres après que les développeurs ont découvert un problème de consensus qui se manifeste précisément pendant le processus de churning. L’équipe de développement du réseau a restructuré sa feuille de route autour d’une seule sortie - la mise à jour v3.20 - qui consolide des correctifs de sécurité, l’intégration de Monero et le déploiement du routeur V6 dans une seule mise à niveau coordonnée visant un déploiement la semaine suivante. La pause découle d’une vulnérabilité nécessitant des changements profonds dans Thornode, impossibles à porter via une mise à jour ponctuelle. La consolidation comble un écart de sécurité critique tout en limitant le nombre de séquences de mise à niveau à haut risque que le réseau doit exécuter, ce qui est particulièrement important compte tenu de la capacité d’évaluation des relecteurs, étirée au sein de l’équipe de développement.
THORChain interrompt la rotation des coffres en attendant la v3.20
La rotation des coffres constitue l’un des mécanismes de sécurité fondamentaux de THORChain, et l’opération n’est actuellement pas en cours. Un problème de consensus apparaît précisément pendant le processus de churning, et le correctif exige des changements suffisamment profonds dans Thornode pour qu’une mise à jour ponctuelle ne puisse pas les transporter. Cela a écarté le correctif v3.19.4 initialement prévu, le même jour où l’équipe en discutait.
L’équipe s’est réunie pour établir la v3.20 à la place, en visant une hauteur de mise à niveau pour la semaine suivante. Une fois la version déployée, le plan est de réactiver d’abord Solana, puis de restaurer le churning. Tout ce qui était prévu pour v3.19.4 - y compris le travail sur Monero - est désormais regroupé dans cette seule mise à niveau plus importante, avec le nouveau code du routeur V6, déjà prêt et déployé progressivement. Pour les utilisateurs, l’expérience après la mise à niveau reste la même : les swaps passent par THORChain Swap comme à l’habitude.
La consolidation n’est pas uniquement réactive. Le fait de regrouper plusieurs améliorations dans une seule sortie coordonnée limite le nombre de fois où le réseau doit traverser une séquence de mise à niveau à haut risque, ce qui compte quand la capacité de relecture est déjà sollicitée.
Trois bugs chaînés ont permis le récent exploit
Le récent exploit ne provenait pas d’un seul défaut catastrophique. D’après Aaluxx, cofondateur de Maya Protocol et désormais développeur senior chez THORChain, la vulnérabilité était une combinaison de trois bugs plus anciens qui coexistaient sans danger dans le code jusqu’à ce que quelqu’un - ou quelque chose - découvre qu’ils pouvaient être déclenchés en séquence.
« C’étaient trois bugs qui, une fois chaînés, étaient exploitables. Chacun d’eux, pris isolément, était inoffensif », a déclaré Aaluxx.
Il a décrit le matin où l’exploit a éclaté comme glacé. L’équipe avait récemment fusionné des correctifs TSS provenant d’un dépôt privé, et sa crainte immédiate était qu’une erreur dans cette fusion ait introduit la vulnérabilité. Un contrôle rapide l’a écarté : le commit était intact, et la cause racine remontait à un code beaucoup plus ancien. L’équipe avait en fait repéré un bug chaîné similaire - une potentielle double dépense - seulement quelques mois plus tôt, ce qui signifie que le schéma sous-jacent était déjà sur le radar.
L’équipe a détecté un coffre compromis via l’analyse de paramètres cryptographiques
La détection était techniquement élégante. En factorisant l’un des paramètres cryptographiques de la configuration TSS et en scannant pour des petits nombres premiers qui ne devraient pas être présents, les développeurs pouvaient déterminer si un coffre donné avait été empoisonné. Sur THORChain, l’un des cinq coffres a été trouvé compromis, ce qui explique pourquoi environ 20 % de la TVL a été vidée plutôt que la totalité. La méthode a offert à l’équipe un diagnostic fiable dans une situation où la rapidité du triage était critique.
Aaluxx a été direct sur la leçon plus large liée au rôle de l’IA pour la suite : une petite équipe peut désormais explorer une base de code sous bien plus d’angles en simultané, ce qui est un avantage défensif - mais la même capacité est disponible pour quiconque tente de trouver des vulnérabilités depuis l’extérieur. Il s’attend à quelques mois difficiles de plus, le temps que l’industrie s’adapte à cette nouvelle réalité.
Maya Protocol a maintenu les swaps pendant l’arrêt d’un mois
Pendant environ le mois où THORChain a été en pause, Maya Protocol a continué à échanger. Le même bug latent existait dans la base de code de Maya, mais il n’a jamais été déclenché. Plus important encore, Maya exécutait un coffre unique que l’équipe pouvait vérifier indépendamment comme sain - ils l’ont donc maintenu opérationnel tout en mettant le churning en pause par précaution, car un churn aurait pu ouvrir le même chemin d’exploit.
La conséquence pratique a été réelle : les swaps natifs BTC-vers-ETH sont restés indisponibles sur THORChain pendant cette période, mais sont restés disponibles sur Maya. C’est l’argument de redondance rendu concret.
« Il faut faire voler le jet avec deux moteurs », a déclaré Aaluxx.
Après l’exploit et durant la période TCY plus tôt, certaines voix ont plaidé pour fusionner THORChain et Maya - en utilisant RUNE pour racheter CACAO et en consolidant le tout dans un seul DEX plus large. Aaluxx a reconnu que ce serait une décision commerciale raisonnable, mais l’a quand même rejetée. Deux DEX indépendants et sans permission partageant les mêmes idéaux constituent un choix de conception délibéré, et non une inefficacité à optimiser. Le coût de la redondance est réel, mais le coût d’un point de défaillance unique l’est aussi.
Les contraintes de capacité de relecture freinent la vitesse de développement
La contrainte qui ralentit la cadence de publication de THORChain n’est pas un manque de code. C’est un manque de personnes qualifiées pour le relire et le déployer.
« Notre facteur limitant n’est pas la création de code : c’est la relecture et le déploiement », a déclaré Aaluxx.
Actuellement, seules environ trois personnes ont la profondeur d’expertise requise pour relire et déployer des changements pour THORChain. Ajouter davantage de développeurs ou plus de pull requests n’accélère pas automatiquement la livraison - cela augmente la charge de relecture sur un goulot d’étranglement déjà étroit. L’équipe fonctionne selon un ratio délibéré de deux pour un : chaque morceau de code écrit nécessite au moins deux relectures avant de passer à l’étape suivante.
L’équipe propose de séparer la phase d’idée du processus ADR
Côté gouvernance, un problème structurel a émergé. Comme les propositions proviennent désormais de nombreux contributeurs plutôt que d’un seul organisme de coordination comme Nine Realms, les numéros ADR ont heurté les uns les autres et des idées approximatives ont été déposées comme ADR formels avant d’être prêtes à être construites.
Le correctif proposé consiste à séparer entièrement la phase d’idée de la phase ADR. Une ADR, comme l’a présenté Aaluxx, devrait être une recette déjà finalisée : concise, technique et réalisable avec les ressources disponibles. Ce qui manque, c’est un espace en amont - une sorte de champ de bataille - où les idées brutes sont contestées, affinées ou abandonnées avant d’être éligibles au statut ADR.
« Certaines personnes pensent que “je veux des pâtes” est une ADR. Ce n’est pas une ADR, c’est un problème. Venez avec une recette », a déclaré Aaluxx.
Plus loin, des numéros ADR pourraient être demandés et attribués on-chain via node relay, le premier nœud approuvant donnant le prochain numéro séquentiel. Cela rendrait la propriété d’une proposition sans ambiguïté sans créer un gardien centralisé. Une ADR, il faut le redire, n’est pas une condition préalable pour livrer du code : chacun peut ouvrir des issues et des pull requests sur GitLab dès aujourd’hui. Une ADR sert de test de température qui indique aux opérateurs de nœuds s’ils veulent du temps développeur rémunéré consacré à quelque chose.
ShapeShift rejoint le modèle de frais dynamiques à mesure que les intégrations s’étendent
Malgré la pause, les intégrations à travers l’écosystème ont continué d’avancer. ShapeShift a désormais rejoint Symbiosis en tant que participant en direct au modèle de frais dynamiques, et les données qui reviennent des deux côtés se révèlent utiles. Trois ou quatre affiliés supplémentaires devraient se mettre en ligne dans la semaine, sous réserve de la disponibilité de Chad Barraford pour finaliser les intégrations.
Un conseil de la communauté a rouvert deux conversations plus larges sur les intégrations. Un DM froid à Randy Bechtold a fait émerger Robinhood Chain comme cible potentielle - et un rapide regard a révélé qu’il s’appuie sur Arbitrum, un réseau que THORChain poursuivait déjà. Cela a créé une opportunité “deux pour le prix d’un” : Bechtold a un appel programmé avec l’équipe d’Arbitrum et prévoit de demander une introduction chaleureuse à Robinhood pendant ce temps.
Aaluxx a apporté une note technique de prudence sur Arbitrum : il fonctionne à environ quatre blocs par seconde, ce qui inonde les nœuds par volume de messages d’une manière similaire à Solana. Maya a passé environ un an à stabiliser son propre support Arbitrum. L’avantage, c’est que le gros du travail difficile est largement déjà réalisé côté Maya, ce qui donne à THORChain un chemin plus court.
L’intégration Monero progresse jusqu’à l’étape d’audit au moindre niveau d’autorité
L’intégration XMR est la fonctionnalité majeure la plus proche d’un lancement. Aaluxx est en discussion avec Least Authority pour un audit sécurité - un cabinet qu’il classe parmi les meilleurs pour les travaux liés aux chaînes orientées confidentialité. Il existe un précédent direct : Zcash a financé un audit de Least Authority pour son intégration ZEC-vers-Maya, qui vient de se terminer avec seulement des constats mineurs de déni de service et d’améliorations de confort d’utilisation, sans bugs majeurs. Le travail sur Monero a déjà franchi les tests chain-net et une relecture développeur.
Conformément à l’approche habituelle du protocole, le pool XMR sera lancé en premier avec une liquidité faible, détenue par le protocole, et de petits swaps de test, afin de maintenir les fonds des utilisateurs hors du champ pendant que le client de la chaîne fait ses preuves en production.
« Cassez les choses, mais cassez-les petit », a déclaré Aaluxx.
Côté THORChain, ZEC n’a pas de calendrier. Le goulot d’étranglement, c’est la bande passante : les remboursements, le travail de sécurité, le redémarrage du réseau et le lancement de Monero se disputent tous la même fenêtre étroite de relecture et de déploiement, et les churns passent en premier.
Moca lance une bêta de point-of-sale crypto via Maya et THORChain
L’angle paiements de l’écosystème a reçu sa propre mise à jour. Moca, un réseau de point-of-sale crypto et de paiements, règle les transactions via Maya Protocol, THORChain et une poignée d’autres backends. L’objectif est de permettre aux commerçants ordinaires d’accepter la crypto et de régler en crypto sans friction - avec un vrai volume dans le monde réel qui revient dans les protocoles à la suite.
La bêta est volontairement discrète, avec un lancement le lundi qui vient après le prochain, sans poussée marketing au début. Le plan est d’ouvrir des comptes professionnels, de recueillir des retours, d’exécuter de vrais paiements de test, puis de corriger les bugs avant un déploiement plus large.
« Le volet paiements de Maya est désormais là », a déclaré EricOnchain, Moca.
Les builders intéressés par un accès API en amont peuvent contacter EricOnchain ou directement le compte Moca.
FAQ
Pourquoi la rotation des coffres de THORChain est-elle actuellement en pause ?
Un problème de consensus spécifiquement lié au processus de churning nécessite des correctifs au niveau de Thornode. Ces changements sont trop profonds pour être livrés dans une mise à jour ponctuelle ; la rotation des coffres reste donc en pause jusqu’au déploiement de la mise à jour complète v3.20.
Qu’est-ce qui a causé le récent exploit de THORChain ?
Trois bugs plus anciens, chacun inoffensif pris isolément, sont devenus exploitables une fois déclenchés en séquence. La combinaison a permis de compromettre l’un des cinq coffres de THORChain, entraînant le drainage d’environ 20 % de la TVL.
Comment Maya Protocol a-t-il maintenu les swaps pendant l’indisponibilité de THORChain ?
Maya exécutait un seul coffre que l’équipe pouvait vérifier indépendamment comme non compromis. En gardant ce coffre opérationnel - tout en mettant le churning en pause par précaution - Maya a continué à traiter les swaps pendant toute la durée de la pause de THORChain, soit un mois entier.
