Comment Polygon restituerait 70 millions de POL volés aux portefeuilles de récupération

Deux vols ont laissé des millions de POL dans cinq adresses bloquées. Une proposition Polygon déplacerait ces soldes vers des portefeuilles de récupération en modifiant les règles du réseau à un bloc spécifique. Transférer les jetons là-bas résoudrait une partie de la récupération. Les restituer aux clients est une tâche distincte.

Une proposition d'amélioration Polygon a identifié 70,49 millions de POL répartis sur cinq adresses bloquées qu'un hard fork coordonné pourrait déplacer vers des portefeuilles de récupération désignés pour Binance et Polymarket.

La proposition décrit une modification des soldes de POL natifs à un bloc fixe. Le logiciel mettrait à zéro les cinq soldes listés et créditerait les montants correspondants aux adresses de récupération vérifiées.

La distinction se situe entre un solde que le réseau a empêché de bouger et un solde qu'une équipe de récupération peut contrôler. Pour les clients, il existe une distinction supplémentaire entre des jetons atteignant un portefeuille de récupération et une plateforme reconnaissant et payant une réclamation.

Comment les deux incidents s'additionnent

La proposition attribue 46,63 millions de POL dans une adresse à l'incident Binance et 23,86 millions répartis sur quatre adresses à l'incident Polymarket. L'addition de ces chiffres arrondis donne 70,49 millions de POL. En divisant chacun par ce total, la part de Binance s'élève à environ 66,2 % et celle de Polymarket à 33,8 %.

Ce sont des parts de la récupération proposée, et non des mesures des pertes totales des deux incidents. Une estimation en dollars dépend également de l'horodatage et du prix utilisés. Les quantités dans la proposition sont libellées en POL.

Les adresses comptent plus que le chiffre en dollars des gros titres

Les soldes de référence de la proposition totalisent 70 489 329,34 POL. L'adresse Binance représente 46 626 593,27 POL, tandis que les quatre adresses Polymarket représentent 23 862 736,07 POL. Ce sont les soldes aux blocs de référence choisis par les auteurs. Le transfert antérieur depuis un portefeuille chaud Binance était légèrement inférieur au solde ensuite enregistré à l'adresse du destinataire.

Une différence de quatre jetons sur un transfert de plus de 46 millions ne changerait guère le chiffre des gros titres. Cela importe à un implémenteur car il existe deux nombres possibles à encoder : le montant tracé depuis l'expéditeur et le solde complet à la destination. La proposition décrit ce dernier comme le montant à lire dans l'état immédiatement avant l'activation, avec un instantané précédent à publier afin que les changements soient visibles. Le projet doit donc être lu comme une procédure pour déterminer le montant final, accompagnée d'un tableau qui établit le montant approximatif en discussion.

Le chiffre de Polymarket présente un problème de mesure distinct. La proposition situe l'incident à environ 28 millions de POL et les quatre soldes sélectionnés à environ 23,86 millions de POL. Par rapport à cette estimation arrondie de l'incident, le montant sélectionné représente environ 85 %, laissant une différence d'environ 4,14 millions de POL. Cette soustraction mesure l'écart entre l'estimation de l'incident et les soldes sélectionnés. Elle ne peut pas établir où les jetons restants ont abouti ni si certains pourraient être récupérés par une autre voie.

Une conversion en dollars ajoute une autre variable. À 0,092 $ par POL, le solde de référence vaudrait environ 6,49 millions de dollars. À 0,096 $, les mêmes jetons vaudraient environ 6,77 millions de dollars. Le calcul multiplie la quantité de référence de la proposition par deux prix illustratifs. Il explique comment des chiffres en dollars proches de 6,5 millions et 6,8 millions de dollars pourraient décrire presque le même transfert proposé. La couverture initiale situait la valeur autour de 6,5 millions de dollars. Une décision de paiement nécessiterait une date de valorisation et une source de prix explicites.

Ce que le fork proposé laisserait derrière lui

La récupération proposée couvre environ 85 % des quelque 28 millions de POL attribués à l'incident Polymarket dans le message du forum. Il est tentant de décrire les 15 % restants comme un montant que le fork ne parviendrait pas à récupérer. La comparaison plus précise se fait entre un chiffre approximatif de l'incident et les soldes que les auteurs affirment encore détenus à quatre adresses. Un exercice de traçage distinct serait nécessaire pour rendre compte de la différence.

La comparaison avec Binance est différente. La proposition identifie un transfert de 46 626 589,6 POL depuis un portefeuille chaud et un solde de 46 626 593,27 POL chez le destinataire au moment où l'instantané de référence a été pris. Le solde de destination était environ 3,67 POL plus élevé que ce transfert. La différence est suffisamment faible pour disparaître dans tout titre arrondi, mais elle aide à expliquer pourquoi un instantané pris à un bloc spécifié est plus utile que de citer un montant issu de la transaction d'origine.

Une deuxième leçon réside dans les unités. Le tableau de référence utilise du POL natif, tandis que le transfert Binance antérieur incluait également 6 185 900,1 USDT. Un total en dollars qui inclurait les deux couvrirait un ensemble d'actifs différent de celui du fork proposé. Un rapport sur des fonds bloqués pourrait raisonnablement aborder les deux, à condition de préciser quelle organisation a pris chaque mesure et si les fonds ont ensuite bougé.

Les deux cas partagent également un mécanisme d'activation sans partager un seul compte. Le logiciel Polygon créditerait des adresses de récupération distinctes, préservant la distinction entre les soldes attribués à chaque incident. Les destinataires pourraient donc rapprocher ce qu'ils ont reçu de leurs propres réclamations et registres d'indemnisation. Le message du forum ne combine pas les réclamations découlant des deux incidents ni ne donne à une plateforme autorité sur les produits de l'autre.

Ce qu'un solde bloqué peut nous dire

Un blocage peut empêcher une adresse listée de transférer des fonds tandis que le solde apparaît toujours sur la chaîne. Un observateur peut voir combien reste à une adresse sans pouvoir déterminer combien un client individuel donné a droit de recevoir.

Les cinq soldes définissent la portée de cette proposition. Un actif impliqué dans l'un ou l'autre incident mais hors de ces soldes nécessiterait sa propre voie de récupération.

Ce que le registre des transferts peut établir

La proposition décrit deux transferts natifs à 18:30:34 et 18:35:59 UTC le 29 octobre. Ensemble, ils ont déplacé 3 282 275,71 POL d'une adresse à une autre. Deux horodatages comptent parce qu'ils aident à établir la séquence selon laquelle les soldes se sont répartis entre les portefeuilles. L'historique des transactions peut montrer les mouvements et les montants même lorsque les personnes contrôlant les clés sont plus difficiles à identifier.

La proposition relie les adresses listées aux incidents. Pour une vérification indépendante, un examinateur devrait suivre les registres de transactions nommés et comparer les adresses sources avec les comptes identifiés par les plateformes concernées. C'est plus précis que de voir plusieurs portefeuilles déplacer de l'argent le même jour. Cela se distingue aussi de la preuve d'une réclamation légale sur chaque pièce encore présente dans un compte.

Une adresse détenant du POL natif et un stablecoin peut illustrer les limites du langage au niveau du portefeuille. L'émetteur du stablecoin peut agir via le contrat du stablecoin. Le POL natif fait partie de la comptabilité des soldes du réseau. Les deux actifs partagent une adresse, mais les personnes qui peuvent empêcher les transferts, et le mécanisme qu'elles peuvent utiliser, dépendent de la nature de l'actif.

La proposition décrit d'autres adresses fournies par Binance comme étant de classe B. Elles relèvent de la discussion sur le blocage, tandis que les changements d'état du projet sont limités aux adresses de classe A spécifiées pour la récupération. Compter chaque adresse bloquée comme un portefeuille qui serait vidé surestimerait la portée. Cela occulterait également une question de gouvernance importante : bloquer une transaction est une action, tandis que décider qu'un solde spécifique doit aller à un destinataire nommé en est une autre.

Pourquoi deux actifs ont nécessité des réponses différentes

La chronologie de la proposition Polygon retrace 46 626 589,6 POL natifs et 6 185 900,1 USDT depuis un portefeuille chaud Binance vers le même destinataire dans le bloc 96 406 484. Tether a gelé les USDT. Le POL est resté l'objet de l'intervention réseau proposée.

Le transfert proposé traite des différents contrôles disponibles sur ces deux actifs. Un émetteur peut imposer des restrictions via le système qu'il exploite pour son jeton. Dans ce cas, les producteurs de blocs de Polygon ont plutôt utilisé un filtre de transactions Bor pour le POL natif, et la proposition décrit ce filtre comme une mesure provisoire.

Chaque producteur de blocs lit la liste au démarrage, selon la proposition. Les modifications nécessitent un déploiement et un redémarrage ou une rotation, et le filtre couvre les expéditeurs externes et les autorités EIP-7702. La proposition indique que l'instantané sera relu avant l'activation, de sorte que son tableau publié est une référence plutôt qu'une garantie des montants de débit finaux.

Pourquoi un filtre de transactions peut tenir pendant des jours et rester temporaire

La liste des producteurs de blocs repose sur une configuration logicielle. La proposition indique que la liste est lue au démarrage. Une nouvelle entrée nécessite donc un changement opérationnel, et les opérateurs doivent appliquer la même configuration pour que les restrictions fonctionnent comme prévu. L'effort impliqué peut être justifié lors d'un incident en cours, lorsque chaque heure donne à une personne détenant les clés une chance supplémentaire de déplacer des fonds.

Une restriction au niveau du producteur doit également correspondre à la manière dont une transaction peut être autorisée. La proposition indique que le filtre couvre les expéditeurs externes et les autorités EIP-7702. C'est une affirmation plus étroite que de dire que les fonds ont été rendus impossibles à déplacer par tout chemin de transaction concevable. Ce que les auteurs rapportent, c'est que les fonds ont été arrêtés et qu'ils n'avaient trouvé aucun contournement. Ils identifient les limites de l'approche dans le cadre de leur argumentaire en faveur d'un changement plus durable.

Les auteurs décrivent une transaction en attente portant des frais proposés exceptionnellement élevés et des tentatives d'obtenir l'assistance des validateurs. Une transaction tentée est la preuve d'un effort pour changer le statut du solde. Elle a un poids probatoire différent de celui d'un transfert exécuté. La proposition décrit également un canal de récupération onchain resté sans réponse. Un retour négocié aurait dépendu d'une réponse d'une partie capable d'autoriser le paiement, tandis que la proposition de fork fonctionnerait via l'adoption de nouvelles règles par les participants.

Une liste indéfinie a des conséquences pratiques pour les personnes qui l'administrent. Elles auraient besoin de savoir quelles entrées servent encore à quelque chose, comment les nouveaux opérateurs obtiennent la configuration correcte et qui est responsable de l'examen des anciennes entrées. La proposition du forum envisage un examen après la récupération, incluant un traitement distinct pour les adresses supplémentaires. Cela signifie que la proposition concerne à la fois un changement de solde ponctuel et ce qu'il advient des contrôles temporaires qui l'entourent.

Ce qui change au bloc de fork

Normalement, un transfert modifie les soldes des comptes après qu'une transaction valide a été acceptée selon les règles du réseau. La proposition demande plutôt au logiciel suivant les règles mises à jour d'appliquer les débits et crédits listés dans le cadre du traitement d'un bloc spécifié.

Les crédits correspondants importent. L'opération telle que décrite prélève le même nombre de jetons natifs sur les adresses listées qu'elle n'en donne aux adresses de récupération désignées. La portée ne s'étend pas aux jetons arbitraires présents dans les portefeuilles.

Le bloc qui enregistrerait la récupération

Le changement d'état proposé est ordonné autour du bloc d'activation, que le projet appelle F. Le montant pertinent est le solde après F moins un. Les nœuds mis à jour appliqueraient les ajustements de solde prescrits avant les transactions ordinaires dans F. Cette séquence importe car elle identifie la frontière exacte qu'un réviseur utiliserait pour vérifier le résultat.

Un transfert normal donne généralement à un explorateur une entrée de transaction à afficher. Un changement appliqué directement selon les règles de la chaîne peut plutôt être visible en comparant les soldes entre des blocs adjacents. Quelqu'un qui ne regarde que la liste des transferts ordinaires du destinataire pourrait le manquer. La publication proposée d'un script de vérification aiderait à relier l'état avant et après avec la liste des destinataires prévus.

La vérification doit couvrir les deux côtés du grand livre. Elle rechercherait un débit et un crédit correspondants pour chaque solde. Si une adresse de récupération recevait également des transactions ordinaires dans le même bloc, la différence brute entre deux instantanés pourrait inclure ces mouvements. Un réviseur devrait alors les séparer du changement d'état spécial plutôt que de traiter chaque incrément comme des fonds récupérés.

Le bloc d'activation est une échéance de coordination. Un opérateur exécutant un logiciel qui calcule l'ancien état et un opérateur appliquant la règle de solde spéciale pourraient calculer des résultats différents à partir du même bloc. Le travail pratique consiste donc à publier le changement, à donner aux opérateurs le temps de l'examiner et à rendre le point d'activation clair. Le tableau de la proposition étiquette encore le bloc comme une décision à prendre une fois l'approbation en place. Une discussion de gouvernance est l'occasion de régler ce plan, tandis que l'état de la chaîne établirait l'exécution.

Qui fait prendre effet au changement

La proposition du forum décrit le changement demandé. Un jalon distinct serait une version qui l'implémente et identifie le bloc d'activation. Les opérateurs devraient alors adopter un logiciel compatible pour que le changement prenne effet sur la chaîne qu'ils utilisent.

Un utilisateur suivant la proposition devrait donc distinguer un message de forum, une implémentation et un bloc qui reflète réellement les nouveaux soldes. Chacun répond à une question différente sur la récupération.

Le travail derrière le choix d'un bloc d'activation

Un numéro de bloc peut ressembler à un détail administratif. En pratique, c'est là que le nouveau logiciel et l'ancien logiciel commencent à diverger sur les soldes des comptes concernés. Le choisir donne aux opérateurs une échéance commune pour installer la mise à niveau, et il donne aux explorateurs, aux fournisseurs d'infrastructure et aux entreprises concernées un point commun à partir duquel vérifier le résultat.

La préparation proposée dans le message du forum implique de confirmer les destinations, de maintenir les dispositions de blocage en place jusqu'à l'activation et de publier un nouvel instantané des soldes. Ces étapes répondent à différentes manières dont une récupération pourrait mal tourner. Une adresse enregistrée de manière incorrecte pourrait envoyer des actifs quelque part d'inattendu. Un changement inexpliqué de solde pourrait laisser les lecteurs comparer le résultat à un chiffre obsolète. Une mise à niveau retardée pourrait laisser un opérateur calculer l'état en utilisant les anciennes règles.

Chacun de ces problèmes appelle une vérification différente. Pour la destination, la preuve importante est la manière dont le destinataire démontre le contrôle et comment l'adresse publiée est examinée. Pour le montant, c'est le solde au point de référence final. Pour le réseau, c'est quelles versions logicielles traitent réellement les blocs après le point d'activation. Une déclaration selon laquelle les opérateurs soutiennent la récupération ne répondrait à aucune de ces questions de mise en œuvre à elle seule.

Il existe également une vérification utile après l'événement. Le changement d'état affecterait directement les soldes natifs, tandis qu'un paiement ordinaire effectué dans le même bloc pourrait affecter le même destinataire. Une différence de solde doit donc être rapprochée des transactions ordinaires de ce bloc. C'est là que le script de vérification proposé par les auteurs serait utile, en particulier s'il identifie à la fois le débit et le crédit correspondant pour chaque compte.

Où les clients entrent dans le processus

Le destinataire du transfert proposé est une adresse de récupération, pas une liste de comptes clients. Une fois qu'un opérateur contrôle les fonds, la question suivante est de savoir comment son propre processus de récupération et de remboursement en tient compte.

Les preuves pertinentes incluraient un calendrier de réclamations, des instructions pour prouver une perte et une politique sur la date d'évaluation. Une plateforme pourrait déjà avoir remboursé certains utilisateurs à partir d'autres fonds. Sa comptabilité devrait établir où va le POL récupéré dans ces cas.

Ce qui compte comme un retour aux clients

Un portefeuille de réception est l'endroit où la capacité du réseau à déplacer les fonds rencontre la responsabilité d'une organisation de les comptabiliser. Si les clients concernés ont déjà été remboursés à partir des ressources propres d'un échange, la récupération pourrait reconstituer ces ressources selon les conditions applicables. S'ils ont des réclamations en cours, une distribution pourrait plutôt réduire le montant qui leur est dû. Les deux scénarios impliquent que l'argent atteigne une adresse de récupération, avec des conséquences différentes pour les utilisateurs.

Il peut également y avoir une inadéquation entre l'actif récupéré et l'actif qu'un client a perdu. Un utilisateur dont le solde d'origine était libellé en dollars ou dans un autre jeton aurait besoin de savoir si la compensation est calculée en unités de cet actif d'origine, en POL ou en monnaie à un prix déclaré. Un jeton volatil peut produire des résultats sensiblement différents selon le moment où la conversion est mesurée.

La distinction entre les soldes des clients et les pertes de la plateforme est particulièrement importante lorsque des incidents distincts sont combinés dans une seule proposition. Le tableau de référence répartit les soldes Polygon par incident. Il ne contient pas de pool de créances conjoint ni de calcul des montants dus aux utilisateurs individuels. Même si les deux ensembles de soldes évoluent dans le même bloc d'activation, les plateformes peuvent faire face à des obligations différentes et peuvent annoncer des modalités de paiement différentes.

Les preuves publiques peuvent être ordonnées selon ce que chaque étape prouverait. Une hauteur de libération et d'activation montrerait qu'une mise en œuvre est prête. L'état du bloc montrerait si le registre a changé. Les enregistrements de la plateforme établiraient si les actifs récupérés ont été distribués, retenus au titre d'une compensation antérieure ou autrement comptabilisés. Le projet de forum rend ses destinations prévues au niveau de la chaîne spécifiques à chaque incident et prévoit une vérification publique des changements de solde.

Qui peut décider de la valeur d'un jeton récupéré ?

Supposons, à titre d'illustration, qu'une plateforme doive à un utilisateur la valeur en espèces d'un solde et reçoive des POL après que le prix a changé. Il y a au moins trois dates auxquelles la plateforme pourrait se référer : le moment du vol, le moment auquel elle obtient les jetons récupérés et le moment auquel elle effectue une distribution. Le montant en espèces représenté par la même quantité de POL peut différer à chacun de ces points.

Une politique de créances pourrait plutôt prévoir un paiement en unités de l'actif qui a été perdu. Cela évite de choisir un prix de marché pour une créance libellée dans le même actif, mais cela laisse encore des questions sur l'éligibilité et les remboursements antérieurs. Un client qui avait déjà été remboursé pourrait avoir une position différente de celle d'une personne dont la créance reste impayée. Le réseau n'a aucun rôle dans ces déterminations.

Ce dont un client a besoin, c'est d'un relevé de ce que la plateforme doit, dans quelle unité et comment elle comptabilise tout ce qui a été payé auparavant. La chaîne peut établir qu'une adresse de récupération a reçu un solde, et la plateforme peut le rapprocher de ses registres. Aucun des deux documents ne fait le travail de l'autre. C'est l'une des raisons pour lesquelles une récupération confirmée peut être une nouvelle même s'il reste une attente distincte pour les détails d'une distribution.

Une comparaison de reporting peut garder les chiffres côte à côte. Le premier serait le POL natif récupéré dans le cadre du changement d'état. Le deuxième serait le montant attribué aux créances des clients ou aux remboursements déjà effectués. Le troisième serait tout solde qui reste en garde pendant que la plateforme résout les cas individuels. Un seul chiffre en dollars tiré de la première étape dirait peu aux lecteurs sur les deux autres.

Pourquoi la portée étroite importe

Un fork qui modifie les soldes soulève une question qu'une mise à niveau logicielle normale ne soulève pas. Quels faits devraient être présents pour que les participants soutiennent à nouveau cette intervention ?

La proposition elle-même décrit l'action comme extrême et la limite aux soldes en POL natif énumérés. L'argument en faveur de la proposition et la question du précédent peuvent tous deux être évalués à l'aune des mêmes détails concrets : les adresses identifiées, la destination proposée et le bloc auquel les soldes changeraient.

Qu'est-ce qui ferait de ce cas un précédent ?

Un autre projet pourrait invoquer l'approche de Polygon après un vol, mais les circonstances de ce projet sont inhabituellement spécifiques. Les auteurs identifient les incidents, les comptes énumérés, les actifs soumis au changement proposé et leur destination. Ils décrivent également pourquoi la restriction déjà en place n'était qu'une mesure temporaire. Une proposition dépourvue de ces éléments présenterait un argument différent pour modifier les soldes.

La question importante est de savoir qui doit être convaincu et quelles informations il reçoit. Une bourse peut savoir quels soldes clients ont été affectés, tandis que les opérateurs ont besoin de preuves concernant le changement proposé à la chaîne. Un utilisateur dont les fonds sont récupérés s'intéresse au résultat. Un opérateur évaluant la proposition doit également réfléchir à la manière dont il évaluerait une future demande émanant d'une autre partie.

La comparaison la plus sûre porte sur les faits qu'une autre requête pourrait démontrer. Peut-elle identifier le montant à un bloc particulier ? Peut-elle relier ces fonds à un incident reconnu ? Peut-elle vérifier un destinataire et préciser ce qu'il advient des adresses déjà bloquées ? Ces questions découlent directement du projet publié et sont plus utiles que de décrire chaque changement d'état inhabituel comme équivalent.

La proposition laisserait certaines de ces questions vérifiables en public. Une hauteur d'activation permettrait aux observateurs d'identifier la transition d'état exacte. Des destinations nommées leur permettraient de retracer ce qui s'est produit ensuite. Les auteurs proposent également de réexaminer les entrées de la liste de blocage temporaire après l'activation, y compris un traitement différent pour les adresses supplémentaires liées à Binance. Ce réexamen final aiderait à établir quelles restrictions d'urgence restent en vigueur une fois la récupération terminée.

Ce que le registre pourrait confirmer

Si la proposition est mise en œuvre, la première vérification consisterait à comparer les soldes des adresses listées de part et d'autre du bloc de bifurcation. Des crédits concordants montreraient que le registre a appliqué le transfert comme spécifié. Les distributions aux clients nécessiteraient des preuves de la part des opérateurs de récupération.

La proposition actuelle spécifie cinq adresses sources et des adresses de récupération désignées pour les deux incidents.

Quels enregistrements répondent à quelle question de récupération

Un incident peut franchir ces étapes à des vitesses différentes. Le gel de l'USDT, par exemple, concerne un actif et un mécanisme différents de la bifurcation POL proposée. Une annonce ultérieure concernant des fonds protégés ou récupérés devrait préciser quel actif a été compté et ce qu'il est advenu de lui.

Les soldes peuvent également changer entre les dates utilisées dans les rapports. Une proposition qui cite un instantané antérieur devrait conserver le numéro de bloc afin que les lecteurs puissent reproduire le montant même si le solde actuel change. Lorsque le résultat est connu, la comparaison du bloc d'exécution avec l'instantané publié établirait si le montant restitué diffère du montant discuté dans la proposition.

La réconciliation la plus importante pour les lecteurs est celle entre le montant débité et le montant crédité. Publier cette vérification séparément pour les deux incidents permettrait de comparer le récit ultérieur des produits de chaque plateforme avec le montant sur lequel elle a effectivement pris le contrôle. Un seul total combiné rendrait plus difficile de suivre quels produits étaient disponibles pour satisfaire quelles réclamations.

Une récupération étroite donne également aux plateformes un moyen de communiquer ce qu'il est advenu des actifs en dehors de la bifurcation. Le chiffre Polymarket dans le message du forum inclut plus de POL que ce qui est listé dans le changement d'état proposé. Le transfert Binance incluait de l'USDT, que Tether a traité séparément. Une mise à jour de récupération qui identifie l'actif concerné, l'adresse et l'action entreprise permettrait aux lecteurs de réconcilier les deux incidents sans supposer que tous les fonds volés ont suivi une seule voie.

La chronologie donne trois dates aux significations différentes. La date de l'incident établit quand les fonds ont bougé. Le bloc de référence établit ce qui a été observé aux adresses lorsque les auteurs ont compilé la proposition. La date d'activation, si elle est convenue, établirait quand le réseau applique la règle de récupération. Un jeton peut être protégé contre certains transferts entre ces dates sans avoir été restitué entre-temps.

Les enregistrements d'adresses peuvent également servir de contrôle des déclarations faites après une mise à niveau. Si un opérateur affirme que les fonds ont été envoyés à la destination publiée, la chaîne devrait montrer la variation de solde correspondante à la hauteur d'activation. S'il déclare que les clients ont été remboursés, la preuve la plus utile est un registre de distribution ou un compte rendu clair des remboursements. L'un est une déclaration sur le réseau, l'autre sur les obligations de la plateforme.

C'est pourquoi les preuves du registre sont particulièrement précieuses lorsque la conversation publique porte sur la question de savoir si le fork a fonctionné. Elles offrent aux observateurs une question précise qu'ils peuvent vérifier sans attendre que chaque entreprise concernée ait terminé sa propre comptabilité. La proposition énonce une procédure pour publier les soldes utilisés dans le changement d'état et pour vérifier les crédits des destinataires par la suite. Ces enregistrements donneraient également aux utilisateurs un point de départ pour suivre ce que chaque plateforme a fait une fois qu'elle a eu le contrôle de l'argent.

Points à surveiller

• Proposition de libération : Les quantités spécifiques à l'incident, les adresses de destinataires proposées et les instructions exécutables soumises à la gouvernance.
• Bloc d'activation : La hauteur de bloc confirmée et la version logicielle que les opérateurs de Polygon devraient installer avant celle-ci.
• Crédits de récupération : Les POL natifs débités de chaque adresse bloquée et le crédit correspondant enregistré chez son destinataire désigné.
• Réclamations des clients : Les instructions de chaque plateforme sur l'éligibilité, l'évaluation et la manière dont elle comptabilisera les remboursements antérieurs.

FAQ