Binance a décidé de prendre en charge le réseau EVM de Zilliqa pour les dépôts et retraits de ZIL, alors que la blockchain abandonne son ancien système de transactions à la suite d’un incident de sécurité qui a exposé des milliers de comptes.

Binance a indiqué que le ZIL sera migré des adresses mainnet historiques de Zilliqa vers le réseau Zilliqa EVM à un ratio de 1:1, la plateforme prenant en charge le processus technique pour les utilisateurs qui détiennent le token sur son service.

Les dépôts et retraits via l’ancien réseau Zilliqa restent suspendus sur Binance depuis le 5 août à 01:00 UTC. Une fois la migration terminée, la plateforme ouvrira les dépôts et retraits de ZIL via Zilliqa EVM sans publier d’annonce distincte.

Les dépôts et retraits sur l’ancien réseau Zilliqa ne seront plus pris en charge après la migration. Le trading spot, le trading sur marge, les contrats à terme et les produits Binance Earn impliquant le ZIL resteront disponibles durant le processus.

La décision de Binance s’inscrit dans l’effort plus large de Zilliqa visant à faire migrer les exchanges, les dépositaires et les détenteurs individuels hors de son ancien système de transactions basé sur Schnorr, après qu’une faille dans l’application Zilliqa de Ledger a rendu certaines clés privées vulnérables.

La migration de Zilliqa fait suite à une faille de signature sur Ledger

La migration découle d’une vulnérabilité dans l’application Ledger de Zilliqa, qui affectait les transactions natives non-EVM signées à l’aide d’appareils Ledger.

Comme l’a précédemment rapporté crypto.news, le problème concernait la manière dont l’application générait les signatures Schnorr. Chaque signature nécessite un nombre secret aléatoire, appelé nonce, mais l’application concernée copiait incorrectement les données générées dans le buffer de signature.

Le post mortem du 20 août de Zilliqa a révélé que cette erreur laissait les 64 bits de poids fort de chaque nonce fixés à zéro, réduisant l’aléa nécessaire à la protection d’une clé privée. Un attaquant pouvait utiliser plusieurs signatures publiques provenant du même compte pour reconstituer sa clé privée.

Le défaut était présent dans toutes les versions publiées de l’application Ledger de Zilliqa entre 2019 et 2026. Zilliqa a indiqué que le premier vol avéré s’était produit le 4 mars, plusieurs mois avant que le problème ne soit détecté.

L’activité s’est intensifiée en juillet, et KuCoin a alerté Zilliqa le 19 juillet après avoir détecté des transactions sortantes inhabituelles depuis l’un de ses cold wallets. Zilliqa a désactivé les transactions historiques le 20 juillet avant d’identifier la cause racine le lendemain.

Le projet a ensuite confirmé qu’au moins 683,13 millions de ZIL avaient été volés au travers de 66 transactions. Au total, 6 772 comptes ont été identifiés comme exposés, tandis que 51 comptes ont été vidés. Zilliqa a précisé que ces deux chiffres constituaient des minimums confirmés, d’autres comptes exposés pouvant encore être identifiés.

Les détails initiaux étaient bien plus limités lorsque les transferts de ZIL ont été suspendus en juillet. À l’époque, Zilliqa avait indiqué qu’un partenaire exchange avait subi le vol d’un cold wallet, sans avoir identifié la méthode d’attaque ni le montant impliqué.

Les transactions sur Zilliqa EVM n’ont pas été affectées par la vulnérabilité. Le projet a expliqué que les software wallets utilisant ses SDK pris en charge généraient correctement les nonces, tandis que la phrase de récupération stockée sur les appareils Ledger n’avait pas été exposée.

Les soldes en ZIL sont transférés vers des adresses EVM

Corriger l’application Ledger pouvait empêcher la création de nouvelles signatures faibles, mais Zilliqa a indiqué qu’il ne pouvait pas sécuriser les clés privées déjà exposées via des signatures stockées de manière permanente on-chain.

Le projet a donc choisi d’abandonner l’ancien système de transactions non-EVM et de faire migrer les utilisateurs vers Zilliqa EVM. Les anciennes adresses sont retirées à mesure que les soldes sont réattribués au niveau du protocole à des adresses EVM.

Les migrations des exchanges ont été effectuées par vagues, car chaque plateforme participante doit fournir et vérifier ses adresses de wallet EVM avant que les soldes puissent être réattribués.

Le premier hard fork de migration des exchanges a eu lieu le 2 septembre, transférant les soldes détenus dans des wallets historiques basés sur Schnorr vers des adresses EVM fournies par les exchanges participants.

KuCoin, MEXC, OKCoin, Binance US, Bitvavo, Korbit, Indodax, Bitrue, WhiteBIT, CoinSpot et CoinSwitch figuraient dans la première vague. Les utilisateurs détenant du ZIL sur ces exchanges participants n’avaient aucune action à entreprendre.

Un deuxième hard fork était prévu pour le 22 septembre et concernait CoinEx, HTX, Bitkub, GOPAX, Coinone, OKX, LBank, Crypto.com, Gate, Paribu, CEX.IO et Bitget.

Bybit et Bithumb devaient rejoindre un troisième hard fork de migration, tandis que Zilliqa a indiqué rester en contact avec d’autres plateformes à mesure que les correspondances d’adresses étaient collectées et vérifiées.

Binance était resté en dehors des vagues précédentes. Sa dernière annonce confirme désormais que la plateforme cessera de prendre en charge l’ancien réseau et migrera son infrastructure de dépôts et de retraits de ZIL vers Zilliqa EVM.

Les détenteurs en self-custody disposent d’une voie de migration ZIL distincte

Les clients des exchanges ne sont pas les seuls détenteurs concernés par l’abandon des anciennes adresses.

Zilliqa a développé un système de migration basé sur des preuves à divulgation nulle de connaissance pour les utilisateurs qui conservent du ZIL dans leurs propres wallets historiques. Ce système est conçu pour permettre à un détenteur de prouver la propriété d’une ancienne adresse et de transférer le solde associé vers une adresse EVM sans fournir à Zilliqa une seed phrase ou une clé privée.

L’audit de l’outil de migration ZKP est terminé, selon une mise à jour de septembre de Zilliqa, des tests internes ayant suivi la revue de sécurité. Son déploiement était visé pour le 22 septembre, en même temps que l’activation d’un contrat d’entiercement requis pour le processus de migration.

Le projet a averti les utilisateurs de ne pas tenter de déplacer des fonds via des anciennes clés exposées. Une fois qu’un attaquant reconstitue une clé privée à partir d’anciennes signatures, le détenteur légitime comme l’attaquant peuvent tous deux signer des transactions depuis le compte.

Les transactions historiques ont donc été désactivées pour tous les détenteurs, y compris les comptes qui n’avaient jamais été exposés. Zilliqa a indiqué que le gel de l’ancien système de transactions empêchait les attaquants disposant de clés reconstituées de déplacer des fonds pendant la préparation du processus de migration.

Les soldes liés aux ZIL déjà volés pendant l’incident sont traités séparément et ne sont pas automatiquement restaurés via les hard forks de migration des exchanges.

Zilliqa a travaillé avec les exchanges et les autorités pour retracer les actifs volés. Son post mortem indique qu’un compte d’exchange utilisé pour liquider une partie des fonds volés a été identifié et gelé, tandis que le projet travaillait avec la police de Singapour et un cabinet d’avocats sur le processus de récupération.

L’équipe a par ailleurs proposé un vote de la communauté sur des changements de la tokenomics du ZIL, qui pourraient inclure l’émission de tokens afin de compenser les détenteurs affectés. Zilliqa a précisé que les détails portant sur l’éligibilité, les montants et les mécanismes seraient publiés avec la proposition de gouvernance, car toute nouvelle émission modifierait l’offre de ZIL.

Zilliqa EVM devient l’environnement de production du réseau

L’évolution de Zilliqa vers une infrastructure EVM avait commencé avant l’incident lié à Ledger.

La blockchain est passée à Zilliqa 2.0 en juin 2025, apportant une compatibilité complète avec l’Ethereum Virtual Machine, ainsi qu’un système de consensus proof-of-stake et des changements dans l’architecture du réseau.

Sa période de test de six mois a impliqué 21 validateurs externes, le proto-mainnet ayant traité 7,5 millions de blocs et effectué 15 mises à niveau du client avant la transition.

La prise en charge des transactions historiques a continué après le lancement de Zilliqa 2.0, laissant la blockchain fonctionner avec à la fois son ancienne infrastructure de transactions natives et son environnement EVM.

Zilliqa a déclaré que l’incident Ledger avait accéléré une décision qu’elle envisageait déjà, à savoir retirer complètement l’ancienne infrastructure. Le projet a qualifié l’ancienne stack de passif croissant en matière de développement et de sécurité, et a indiqué que Zilliqa EVM deviendrait son unique environnement de production.

L’incident de sécurité est survenu après plusieurs problèmes techniques antérieurs impliquant la blockchain, bien que Zilliqa n’ait pas relié ces interruptions à la vulnérabilité Ledger. Une panne réseau en janvier 2025 a été attribuée à des problèmes impliquant les lookup nodes, tandis qu’un bug distinct en septembre 2024 avait interrompu la production de blocs.

Le post mortem de Zilliqa indique que le correctif pour l’application Ledger a été soumis le 24 juillet et intégré par un ingénieur de Ledger le 27 juillet. La version corrigée rétablit une génération complète des nonces pour les nouvelles signatures, tandis que les clés privées déjà exposées par d’anciennes signatures historiques doivent être abandonnées.