La vérité explosive derrière les bots crypto qui devancent les voleurs pour « sauver » les fonds — mais ils décident qui est remboursé

Source : CryptoNewsNet Titre original : La vérité explosive derrière les bots crypto qui devancent les voleurs pour « sauver » les fonds — mais qui décident qui est remboursé Lien original :

L’incident Makina Finance

Makina Finance a perdu 1 299 ETH, environ 4,13 millions de dollars, lors d’une exploitation de flash-loan et de manipulation d’oracle.

L’attaquant a drainé les fonds du protocole et a diffusé la transaction dans le mempool public d’Ethereum, où elle aurait dû être récupérée par les validateurs et incluse dans le bloc suivant.

Au lieu de cela, un constructeur MEV identifié par l’adresse 0xa6c2 a devancé la transaction de drain, redirigeant la majorité des fonds vers une garde contrôlée par le constructeur avant que le hacker ne puisse les déplacer hors chaîne.

La transaction du hacker a échoué. Les fonds ont été déposés dans deux adresses associées au constructeur MEV.

La conclusion immédiate est que les utilisateurs de Makina ont évité une perte totale. Le signal plus profond concerne la personne qui a fini par détenir l’argent et ce que cela signifie pour l’architecture émergente de réponse d’urgence en crypto.

L’acteur le plus important dans cette histoire n’est ni l’attaquant ni le protocole, mais la chaîne d’approvisionnement de construction de blocs qui a intercepté l’exploitation et contrôle désormais si les utilisateurs récupèrent leurs fonds, dans quelles conditions, et à quelle vitesse.

Les bots et constructeurs MEV deviennent la dernière ligne de défense de la crypto, non pas par conception mais par position structurelle. C’est un problème, car la capacité de sauvetage est concentrée entre les mains d’intermédiaires maximisant le profit, opérant avec une responsabilité peu claire.

MEV comme filet de sécurité est déjà un modèle

L’incident Makina n’est pas isolé. Chainalysis a documenté une dynamique similaire lors de l’exploitation Curve et Vyper en 2023, notant que des hackers white hat et des opérateurs de bots MEV ont aidé à récupérer des fonds, ce qui a réduit les pertes réalisées en dessous des estimations initiales.

Le modèle est mécanique : tant que les exploits ou tentatives de sauvetage sont visibles dans les canaux de transaction publics, des chercheurs et constructeurs sophistiqués peuvent rivaliser pour réorganiser les transactions.

Parfois, ils sauvent des fonds. Parfois, ils les capturent. Quoi qu’il en soit, ils agissent comme une couche de réponse d’urgence de facto.

Lorsqu’une transaction d’exploitation entre dans le mempool public, les chercheurs MEV surveillent pour des opportunités rentables. Si un hacker drain une plateforme et diffuse la transaction publiquement, un chercheur peut construire une transaction concurrente qui s’exécute en premier, redirigeant les fonds vers une autre adresse.

Le chercheur regroupe la transaction et la soumet à un constructeur de blocs, qui l’inclut si le profit dépasse les offres concurrentes. Si le bloc du constructeur est choisi par un validateur, la transaction du chercheur s’exécute, et celle du hacker échoue.

Il s’agit d’une extraction de profit avec un effet secondaire bénéfique plutôt que d’un pur altruisme. Mais c’est aussi le mécanisme le plus fiable que la crypto ait développé pour intercepter les exploits en temps réel, car il opère au niveau de l’ordre des transactions plutôt que de s’appuyer sur des coupe-circuits ou une intervention de gouvernance au niveau du protocole.

Pourquoi la dépendance aux constructeurs MEV est inconfortable

Le problème des sauvetages basés sur le MEV, c’est qu’ils concentrent la capacité de réponse d’urgence dans un pipeline fortement intermédiaire.

Sur Ethereum, MEV-Boost domine la production de blocs. Le paysage des relais de Rated montre qu’environ 93,5 % des blocs récents sont routés via MEV-Boost, contre environ 6 % utilisant la production de blocs standard.

Au sein de MEV-Boost, la part de marché des relais est encore plus concentrée : Ultra Sound Money représente environ 29,84 % du trafic de relais, et Titan environ 24,24 %, ce qui signifie que les deux plus grands relais gèrent ensemble plus de 54 % de la production de blocs.

Si la majorité des blocs transitent par MEV-Boost et que la majorité du trafic MEV-Boost passe par deux relais, la couche de sauvetage dépend structurellement d’un petit nombre d’intermédiaires. Cela pose rapidement des problèmes de gouvernance.

Si un constructeur détient les fonds sauvés, qui autorise la garde ? Qui fixe la prime ? Qu’est-ce qui empêche l’extorsion ou les demandes de rançon ? Et si le constructeur est offshore, anonyme, ou opère dans une juridiction à faible enforcement ?

Le cas Makina illustre le problème. Les fonds sont en garde chez le constructeur, mais il n’existe pas de SLA public, de prime prédéfinie, ou de mécanisme clair pour restituer les fonds à Makina ou à ses utilisateurs.

Le constructeur pourrait rendre les fonds volontairement, négocier une prime, demander des frais plus élevés que la norme du secteur, ou refuser de rendre les fonds.

Le routage privé aggrave le problème

Un article académique de 2025 intitulé “Sandwiched and Silent” a documenté un routage privé généralisé des transactions et a constaté que de nombreuses victimes migrent vers des canaux privés après avoir été sandwichées par des bots MEV.

Cependant, le routage privé n’élimine pas le MEV, il le déplace simplement des mempools publics vers des flux de commandes privés contrôlés par des constructeurs et relais.

Pour les protocoles, cela signifie que les sauvetages dans le mempool public deviennent moins fiables, car les transactions d’exploitation transitent de plus en plus par des canaux privés accessibles uniquement à un sous-ensemble de constructeurs.

Une tentative de civiliser le chaos

Safe Harbor est un cadre développé par SEAL qui cherche à remplacer le modèle « constructeur MEV comme dépositaire accidentel » par des répondants autorisés, des SLA explicites, et des incitations limitées.

SEAL décrit Safe Harbor comme un cadre juridique et technique permettant aux protocoles de pré-autoriser des white hats à intervenir lors d’exploits actifs.

La règle opérationnelle principale est que les fonds sauvés doivent être envoyés à des adresses de récupération officielles dans les 72 heures, avec des primes prédéfinies et enforceables.

SEAL indique que Safe Harbor a été motivé par le hack Nomad, où les white hats étaient prêts à aider mais étaient limités par une ambiguïté légale quant à la possibilité de poursuivre en cas de restitution des fonds comme accès non autorisé à un ordinateur.

Safe Harbor élimine cette ambiguïté en donnant aux protocoles un moyen de pré-autoriser l’intervention et de définir des termes clairs. SEAL affirme que Safe Harbor protège déjà plus de $16 milliard(s) à travers de grands protocoles, y compris certains DEX, Pendle, certaines solutions de couche 2, et zkSync.

Immunefi, la plateforme de bug bounty, a opérationnalisé Safe Harbor avec des conditions plus strictes.

Immunefi décrit Safe Harbor comme un cadre développé par SEAL qui redirige les fonds vers un coffre contrôlé par le protocole sur la plateforme Immunefi. Sur la page du programme Safe Harbor d’Immunefi, il est indiqué : « Vous avez 6 heures pour transférer les fonds. »

Le non-respect de ce délai de six heures constitue une violation matérielle. C’est quatre fois plus rapide que l’exigence de 72 heures de SEAL.

Safe Harbor n’élimine pas la dépendance à l’infrastructure MEV. Il cherche simplement à la formaliser.

Si un constructeur devance une exploitation et que le protocole a adopté Safe Harbor, le constructeur doit reconnaître l’intervention comme autorisée et rediriger les fonds vers l’adresse de récupération désignée par le protocole dans le SLA.

Mais cela suppose que les constructeurs surveillent les registres Safe Harbor, respectent les termes, et privilégient la conformité au profit du profit.