Une proposition, pas encore une décision

La proposition publiée sur le forum de gouvernance de Polygon demande un hard fork coordonné de Polygon PoS. À un bloc déterminé, le protocole retirerait les POL natifs des adresses attribuées aux attaquants et créditerait des adresses vérifiées de Binance et Polymarket. L’activation dépend encore d’un vote, de tests et de l’adoption du logiciel par les validateurs.

Distinction essentielle : les montants et le mécanisme proviennent de la proposition PIP. Ils sont documentés par des traces on-chain, mais l’approbation communautaire, la date d’activation et la version cliente restent à déterminer.

Répartition des fonds bloqués

IncidentAdresses concernéesPOL visés
Polymarket423 862 736,07
Binance146 626 593,27
Total5Environ 70,49 millions

Pourquoi la liste de blocage ne suffit pas

Les producteurs de blocs empêchent actuellement les adresses d’émettre des transactions. Selon les auteurs, ce dispositif est fragile : la liste est chargée au démarrage, nécessite des mises à jour manuelles et ne constitue pas un gel natif définitif. Un attaquant aurait même proposé jusqu’à 219 450 POL de frais et contacté des validateurs pour tenter de contourner le blocage.

Une modification directe de l’état de la chaîne

Le fork ne créerait pas de nouveaux POL : il transférerait les soldes dans l’état du protocole, sans transaction signée par les détenteurs des clés. Les nœuds non mis à jour suivraient une chaîne différente. Les explorateurs, indexeurs et outils comptables devraient aussi reconnaître cette modification sans transaction classique.

Le dilemme entre restitution et neutralité

Les promoteurs qualifient eux-mêmes l’opération d’extrême et affirment qu’elle ne doit pas devenir habituelle. Le bénéfice immédiat est la restitution de fonds traçables à des victimes identifiées. Le coût institutionnel est la création d’un précédent où la gouvernance peut modifier des soldes après un vol.

Calendrier envisagé

Le projet doit être présenté lors d’un appel de gouvernance, puis testé sur Amoy. Les auteurs estiment qu’un déploiement environ deux semaines après approbation serait réaliste. Une couverture suffisante du stake par la nouvelle version sera indispensable pour limiter le risque de scission.