DxSale publie des clarifications sur un incident : les contrats de verrouillage de liquidité v2 et ultérieurs ne sont pas affectés
DxSale publie des clarifications sur un incident : les contrats de verrouillage de liquidité v2 et ultérieurs ne sont pas affectés
Une récente arnaque visant les fournisseurs de liquidité sur la BNB Chain a ravivé une question familière dans la DeFi : l'« ancienne infrastructure » peut-elle redevenir dangereuse lorsque la chaîne sous-jacente évolue ? Fin mai 2026, des pirates informatiques ont ciblé des verrous de liquidité DxSale hérités, datant de 2021, déclenchant des mouvements de fonds on-chain et une vague d'inquiétude parmi les projets qui dépendaient autrefois de l'architecture de verrouillage précoce de DxSale.
Dans une clarification publiée aux alentours du 30–31 mai 2026 (selon le fuseau horaire), DxSale a déclaré que le problème était limité à son contrat de verrouillage v1 et que les versions v2 et ultérieures (v2, v3, etc.) n'avaient pas été affectées, les contrats plus récents ayant été audités et les actifs verrouillés par les utilisateurs restant sécurisés.
Vous trouverez ci-dessous une analyse pratique de ce qui s'est passé, pourquoi les fonctionnalités d'exécution « atomiques » au niveau de la chaîne peuvent révéler des cas limites dans les anciens contrats, et ce que les LPs et les équipes de token devraient faire ensuite.
Ce qui s'est passé sur la BNB Chain (29 mai 2026)
Le 29 mai 2026, des rapports ont indiqué qu'environ 1 400 anciennes positions de LP – principalement de l'ère 2021 – avaient été vidées sur la BNB Chain, avec des pertes estimées à environ 7,3 millions de dollars. Plusieurs analyses ont noté que le pirate informatique avait utilisé une approche cohérente avec la manipulation de la propriété / du contrôle privilégié, puis avait acheminé les actifs par le biais d'échanges et de dépôts.
Une adresse de pirate informatique largement citée dans l'incident est la suivante :
- 0xC4574DDE...2EeaFA69 – consultable sur le suivi d'adresses BscScan
Les résumés publics ont également décrit le pirate informatique consolidant les fonds en BNB, transférant 2 958 BNB (environ 1,87 million de dollars à l'époque) vers deux portefeuilles principaux, puis les acheminant vers des adresses de dépôt d'échange et les échangeant via PancakeSwap. Pour un aperçu accessible de l'incident, consultez le rapport de Cointelegraph repris sur TradingView.
Le point essentiel de DxSale : Le rayon d'impact est limité à la v1
La clarification de DxSale met l'accent sur trois affirmations clés :
- Les contrats concernés sont les premiers contrats de verrouillage de liquidité « v1 » lancés en 2021.
- Les contrats v2 et ultérieurs ne sont pas affectés.
- Les contrats de génération ultérieure ont été construits selon une architecture différente et ont fait l'objet d'une revue de sécurité / d'un audit.
Bien que les utilisateurs doivent toujours vérifier les adresses de contrat et la portée de l'audit pour leur verrouillage spécifique, vous pouvez vérifier l'historique de sécurité et d'audit des projets de DxSale via la page du projet DxSale sur CertiK Skynet.
Pour les utilisateurs peu familiers avec le versionnement sur DxSale, la documentation de DxSale elle-même distingue les lockers plus récents (par exemple, les documents de verrouillage de liquidité DxLock V2), ce qui est utile pour confirmer les outils et la génération de contrat qu'un projet donné a utilisés.
Pourquoi les « transactions atomiques » peuvent invalider les vieilles hypothèses
DxSale a attribué la cause fondamentale à un problème de compatibilité entre le nouveau style d'exécution « transaction atomique » de la BNB Chain et la conception ancienne du locker v1.
Dans les écosystèmes EVM modernes, « atomique » fait souvent référence au regroupement de plusieurs actions en une seule transaction tout ou rien (de sorte que les états intermédiaires ne persistent jamais). Cette orientation s'est accélérée en 2025-2026 grâce à l'adoption plus large de l'abstraction de compte et des primitives de batching, y compris les mécanismes de style EIP-7702.
La BNB Chain a publiquement discuté des mises à niveau des smart-wallets et de l'abstraction de compte – voir l'annonce du hard fork Pascal de la BNB Chain. Pour la norme sous-jacente qui a popularisé les concepts de délégation / batching en une seule transaction, référez-vous à l'EIP-7702 sur les EIPs d'Ethereum.
La leçon clé pour la sécurité DeFi
Même lorsqu'un contrat hérité « fonctionne depuis des années », les nouveaux modèles de transaction peuvent invalider les anciens modèles de menace, surtout si le contrat s'appuyait sur des privilèges d'administrateur, des flux de propriété inhabituels ou des hypothèses sur la manière dont les appels peuvent être composés.
C'est l'une des raisons pour lesquelles les conversations sur la sécurité DeFi en 2025-2026 se concentrent de plus en plus sur :
- le risque des contrats immuables vs évolutifs,
- les rôles privilégiés et les limites de propriété,
- et si les contrats restent sûrs sous les nouvelles fonctionnalités de la chaîne et les environnements d'exécution.
Ce que les fournisseurs de liquidité et les équipes de token devraient faire maintenant
1) Confirmer la version du locker utilisée par votre LP
Si vous êtes un membre de la communauté d'un ancien projet de la BNB Chain, ne supposez pas que « verrouillé » signifie « sécurisé ». Demandez à l'équipe de fournir :
- l'adresse exacte du contrat du locker,
- l'ID du verrouillage / la page de verrouillage,
- et une confirmation pour savoir s'il s'agit de la v1 vs v2+.
Si vous n'avez qu'une adresse, commencez par BscScan et inspectez l'heure de création du contrat, les fonctions de propriété et les transactions historiques.
2) Considérer l'audit comme une étape nécessaire, mais pas suffisante
Les audits réduisent les risques mais ne les éliminent pas, surtout lorsque le comportement de la chaîne évolue. Utilisez les références d'audit comme point de départ, puis évaluez :
- Les fonctions privilégiées sont-elles toujours présentes ?
- La propriété peut-elle être modifiée ?
- Y a-t-il des paramètres contrôlés par l'administrateur qui affectent les retraits ?
3) Supposer que les attaquants cibleront les contrats oubliés
L'exploit illustre un schéma récurrent : les attaquants recherchent souvent les liquidités dormantes et les contrats hérités car la surveillance est plus faible et les réponses sont plus lentes.
4) Protéger vos clés de signature lors des migrations et des actions d'urgence
Les incidents comme celui-ci déclenchent souvent des « migrations urgentes », qui sont le moment idéal pour le phishing et les invites de signature malveillantes.
Un portefeuille matériel tel que OneKey peut aider en gardant les clés privées hors ligne et en exigeant une confirmation sur l'appareil pour les transactions, réduisant ainsi la probabilité qu'un ordinateur compromis ou une extension de navigateur approuve silencieusement des actions nuisibles. Cela ne résout pas un contrat DeFi vulnérable, mais cela améliore matériellement la sécurité opérationnelle personnelle lorsque vous interagissez avec des dApps sous pression.
En résumé
- L'incident de mai 2026 met en évidence comment les contrats de verrouillage de liquidité hérités peuvent redevenir un risque systémique, en particulier sur les chaînes en évolution rapide où les fonctionnalités d'exécution évoluent rapidement.
- La déclaration de DxSale présente le problème comme étant limité aux lockers v1 de l'ère 2021, les contrats v2 et ultérieurs n'étant pas affectés.
- Pour les utilisateurs et les équipes, la conclusion à retenir est d'inventorier les anciens verrous, de vérifier les versions des contrats et de mettre à jour les pratiques de sécurité pour correspondre aux réalités de 2026 : batching atomique, exécution déléguée et stratégies d'attaque en évolution rapide.
Si vous gérez une trésorerie ou signez régulièrement des transactions DeFi sur la BNB Chain, envisagez d'utiliser OneKey dans le cadre d'une posture de sécurité plus large : isolation des clés protégée par matériel, gestion prudente des autorisations et flux de travail de réponse aux incidents calmes et vérifiables.
