Arbitrum a déplacé les fonds volés à Binance : leur restitution passera par un vote

Le Conseil de sécurité d’Arbitrum a utilisé une mise à niveau temporaire du contrat pour déplacer la cryptomonnaie liée au piratage de Binance. Son action d’urgence a empêché l’attaquant de déplacer ces actifs, mais la décision de leur destination relève d’un processus de gouvernance distinct.

Le Conseil de sécurité d’Arbitrum a déplacé 8 425 ETH et 74 559 805,2 ARB liés au piratage de Binance vers une adresse de conservation dont les fonds nécessitent un vote de gouvernance de la DAO pour être déplacés à nouveau.

L’avis d’action d’urgence d’Arbitrum indique que l’intervention a eu lieu à 08:08 HKT le 30 octobre. Des contributeurs ont préparé une modification temporaire du contrat inbox Ethereum du réseau, les membres du conseil l’ont vérifiée et signée, et l’implémentation d’origine a été restaurée après les transferts.

L’action a attiré l’attention parce qu’elle n’a pas nécessité la clé privée de l’attaquant. Arbitrum a utilisé son autorité sur sa propre infrastructure pour créer des messages qui ont déplacé les actifs sur Arbitrum One.

Son avis public décrit le résultat comme un gel et réserve tout mouvement ultérieur à la gouvernance d’ArbitrumDAO. Déplacer des fonds hors d’un exploiteur et les restituer à un destinataire légitime sont donc des décisions distinctes.

L’intervention d’Arbitrum a utilisé une permission supérieure au portefeuille

Un paiement ordinaire en cryptomonnaie est autorisé par le compte qui l’envoie. L’avis d’incident d’Arbitrum décrit une voie exceptionnelle : une modification de l’infrastructure qui détermine comment les messages provenant d’Ethereum sont traités sur le rollup.

La fonction ajoutée, sendUnsignedTransactionOverride, pouvait imiter une transaction inter-chaînes tout en usurpant l’identité de son expéditeur. Deux messages ont transféré les ETH et les ARB depuis l’adresse identifiée vers l’adresse de conservation se terminant par 0DA0.

La distinction se situe entre compromettre la clé de l’attaquant et utiliser l’autorité administrative sur le système dans lequel ce compte existe. L’explication publiée d’Arbitrum décrit la seconde option.

Sa constitution accorde des privilèges de propriétaire de chaîne à la DAO et au Conseil de sécurité. Ces privilèges incluent la modification des implémentations et paramètres du protocole de base, y compris les contrats associés sur Ethereum.

Le rôle de propriétaire de chaîne se situe au-dessus des règles d’une application particulière. Il fait partie de l’architecture de gouvernance d’Arbitrum, de sorte que les pouvoirs disponibles ne peuvent pas être déduits uniquement des permissions visibles dans le portefeuille d’un utilisateur.

Ethereum a fourni le lieu de la transaction administrative, tandis que les actifs étaient détenus sur Arbitrum One. L’événement n’a pas démontré un pouvoir de réécrire des comptes Ethereum sans rapport ni de prendre des bitcoins natifs d’un autre réseau.

La documentation pour développeurs d’Arbitrum explique que les messages de la chaîne parente entrent dans le rollup via l’infrastructure inbox. Les utilisateurs peuvent envoyer des transactions via une inbox différée lorsque le séquenceur est indisponible ou ne les inclut pas.

Ce chemin de message ordinaire et la dérogation temporaire de l’incident doivent être distingués. L’accès d’un utilisateur normal à une inbox différée ne confère pas l’autorité spéciale d’usurpation d’expéditeur créée pour l’action d’urgence.

L’intervention du Conseil de sécurité a été possible parce qu’il pouvait approuver une mise à niveau du contrat concerné. La modification du code a fourni la fonctionnalité exceptionnelle ; le portefeuille de l’attaquant n’a pas approuvé volontairement le transfert.

La possession d’une clé privée par le propriétaire d’un portefeuille ne décrit donc qu’une partie du dispositif de sécurité. Sur un système évolutif, les utilisateurs dépendent aussi de la manière dont les permissions administratives sont réparties et encadrées.

La mise à niveau temporaire regroupait le sauvetage et la restauration

Arbitrum a déclaré que la mise à niveau, les transferts et la restauration formaient une action atomique. En termes de transaction, les opérations étaient regroupées de sorte que l'implémentation d'urgence n'était pas destinée à rester l'implémentation active après l'achèvement de l'opération.

L'avis d'Arbitrum identifie la transaction administrative comme 0xb69c81774f507d46ce776aeaed8b4d31df96dd66ce6fd05073481011835355d6. La déclaration identifie les opérations et la destination séparément de toute interprétation de leur effet juridique.

La restauration de l'implémentation antérieure a retiré la fonction spéciale de l'implémentation active utilisée après cette transaction. Elle n'a pas supprimé l'autorité de mise à niveau sous-jacente qui permettait au conseil de l'introduire.

Une analogie est utile si elle reste dans ces limites : retirer une instruction temporaire n'abolit pas l'office habilité à émettre une autre instruction. Les utilisateurs évaluant le risque d'intervention future ont besoin des règles de gouvernance permanentes ainsi que de la durée de vie du code temporaire.

L'architecture de gouvernance de la fondation décrit les exécuteurs de mise à niveau et les entités autorisées à les appeler. L'autorité d'urgence et la voie plus lente de la DAO sont différentes manières d'atteindre des opérations contractuelles privilégiées.

Le dossier technique peut établir quelle implémentation a été installée et restaurée, et quels messages ont été créés. Il ne décide pas de manière indépendante si une adresse a été correctement identifiée comme détenant des biens volés.

Cette identification dépend des preuves de l'incident et des acteurs qui les ont évaluées. L'avis d'Arbitrum identifie l'adresse comme associée à l'exploit de Binance et déclare que les fonds et applications des autres utilisateurs n'ont pas été affectés.

La portée étroite de l'action publiée est pertinente. Le conseil a ciblé des actifs identifiés sur sa chaîne gouvernée ; il n'a pas annoncé un retour en arrière à l'échelle du réseau de toute l'activité pendant le vol.

Pour un lecteur vérifiant la récupération, trois informations vont ensemble : la transaction administrative exécutée, les transferts qu'elle a causés et l'état du contrat de détention par la suite. Une capture d'écran d'un solde seule ne peut pas expliquer la permission qui l'a déplacé.

La même approche s'applique à toute libération ultérieure. Un résultat de gouvernance, des instructions exécutables et un transfert achevé forment une chaîne de preuves ; l'approbation à une étape n'est pas la preuve que toutes les étapes ultérieures ont eu lieu.

Neuf signataires peuvent agir avant un vote complet de la DAO

Le Conseil de sécurité compte 12 membres, et les actions d'urgence nécessitent 9 approbations. La FAQ de gouvernance distingue cette voie immédiate de la séquence plus longue utilisée pour les propositions ordinaires.

Neuf sur 12 est un seuil de signature de 75 %. Il permet à une action de progresser avec 3 membres indisponibles ou opposés, tandis que 4 membres retenant leur approbation empêcheraient ce seuil d'être atteint si les 8 autres le soutenaient.

Cette arithmétique décrit la règle d'approbation, non l'indépendance des personnes impliquées. L'indépendance dépend des affiliations, des conflits, du contrôle des clés et de la question de savoir si des signataires censément séparés peuvent en pratique être dirigés par la même partie.

Arbitrum publie la composition de son conseil, y compris les parcours professionnels des membres et les affectations de cohorte. La liste permet aux utilisateurs d'identifier les décideurs au lieu de traiter « le conseil » comme un service technique anonyme.

Sa constitution exige des rapports de transparence après les actions d'urgence et limite le mandat d'urgence aux véritables urgences de sécurité. La DAO peut modifier ou éliminer les pouvoirs du conseil par le processus de proposition constitutionnelle.

La voie plus rapide a une justification opérationnelle explicite. Attendre un vote complet des jetons peut laisser des fonds à la disposition d'un attaquant pendant que les délégués discutent d'une proposition et que la fenêtre de vote s'écoule.

Le compte de décentralisation progressive d’Arbitrum décrit le conseil comme un mécanisme destiné aux urgences critiques pendant que la gouvernance se développe. Il présente la réponse rapide et la gouvernance distribuée comme faisant partie de la même architecture.

La préoccupation opposée est consignée dans l’évaluation d’Arbitrum par L2BEAT, qui traite l’autorité de mise à niveau immédiate comme une hypothèse de confiance matérielle. Sa classification de stade 1 permet l’intervention du conseil de sécurité ; cela ne signifie pas que chaque opération importante échappe à la discrétion humaine.

Ces comptes rendus décrivent la même permission sous des perspectives différentes. Arbitrum met l’accent sur la capacité à réagir à un événement critique, tandis que l’évaluation des risques identifie les conséquences si les décideurs privilégiés agissent de manière malveillante ou si leurs clés sont compromises.

L’opération de Binance démontre une intervention dirigée contre des actifs soupçonnés d’avoir été volés. Évaluer l’architecture exige de considérer qui pourrait approuver une autre intervention et quelles limites exécutoires s’appliquent à cette autorité.

Le gel des fonds et le choix d’un destinataire ont des échéances différentes

Un gel d’urgence répond à une question immédiate : les actifs identifiés peuvent-ils être empêchés de quitter le système ? Une libération répond à une autre : quel destinataire doit les recevoir, sur quelles preuves et selon quelles instructions ?

L’avis de Binance précise l’exigence de gouvernance mais ne fixe pas de délai de remboursement des clients. Un vote de DAO doit être préparé autour d’une destination proposée et d’une action exécutable avant de pouvoir régler cette étape suivante.

Le moment de l’intervention initiale peut néanmoins être calculé à partir des deux avis d’incident. Binance a situé le début du vol à 20 h 05 UTC le 29 octobre ; 08 h 08 HKT le 30 octobre correspond à 00 h 08 UTC, soit un intervalle d’environ 4 heures et 3 minutes.

Le calcul concerne le début du vol signalé et l’heure d’action déclarée par Arbitrum. Il ne mesure pas le temps que le conseil a mis pour agir après avoir reçu une alerte, car l’avis ne précise pas quand cette alerte est arrivée.

Il n’établit pas non plus que tous les actifs du piratage plus large sont restés récupérables pendant ces heures. L’intervention portait sur les avoirs identifiés sur Arbitrum One, tandis que le vol et les transferts ultérieurs impliquaient d’autres réseaux.

Le temps écoulé jusqu’au gel et le temps écoulé jusqu’à la restitution nécessitent donc des événements de début et de fin distincts. Le second exigerait un retour achevé au destinataire autorisé, et non simplement une annonce selon laquelle les actifs ont été immobilisés.

Une proposition datée fournirait la partie suivante de cette chronologie, suivie de son vote, des périodes d’attente applicables et de l’exécution. Tant que ces événements ne se produisent pas, l’horodatage du gel ne fournit aucune date de paiement automatique pour les clients.

Le guide de vote des propositions d’Arbitrum distingue la discussion, la signalisation hors chaîne et le vote formel sur chaîne. Un fil de discussion positif ou un contrôle de température n’est pas le même événement que l’exécution via les contrats de gouvernance.

La constitution classe séparément comme constitutionnelles les propositions qui modifient le logiciel ou nécessitent les pouvoirs du propriétaire de la chaîne. Elle leur attribue des étapes de vote, d’attente et de mise en œuvre, la voie applicable étant déterminée par ce que la proposition fait réellement.

Une proposition de transfert nécessite par conséquent plus de détails qu’une déclaration selon laquelle les fonds devraient être restitués. L’adresse du destinataire, le montant, l’autorité et toute condition doivent correspondre aux instructions que les votants sont invités à approuver.

Cette précision est particulièrement pertinente pour une récupération impliquant un échange. Binance a promis de couvrir les clients à l’aide des ressources de l’entreprise, de sorte que le destinataire des actifs récupérés peut être l’échange ou un autre arrangement de récupération autorisé, plutôt que chaque titulaire de compte recevant une distribution directe sur chaîne.

Son programme de remplacement d'actifs s'est poursuivi tandis que les actifs d'origine restaient gelés ailleurs. Les produits de la récupération et les passifs envers les clients doivent donc être rapprochés afin que le même montant ne soit pas représenté comme deux remboursements distincts.

Prenons l'exemple hypothétique d'une plateforme d'échange qui remplace 100 jetons volés en utilisant sa trésorerie. Si une DAO restitue ensuite 20 jetons d'origine, les clients n'ont pas reçu 120 jetons de restitution ; la plateforme a récupéré une partie du coût de restauration du passif initial de 100 jetons.

Si les jetons n'ont pas encore été remplacés, la même récupération pourrait plutôt réduire le déficit client en cours. La description correcte dépend du passif réel et des modalités de remboursement au moment du transfert.

Le processus décisionnel devrait rendre ces modalités visibles. Une adresse de récupération identifie où les actifs vont on-chain, tandis que la documentation qui l'accompagne explique qui la contrôle et à quelle créance le transfert est censé répondre.

Le sauvetage de KelpDAO a déjà montré ce qui peut retarder une restitution

Arbitrum a utilisé une intervention comparable après l'exploit de KelpDAO en avril. Son avis d'action d'avril identifiait 30 765,667501709008927568 ETH déplacés vers la même adresse de détention et indiquait que la gouvernance devrait autoriser une libération.

Comme crypto.news l'a rapporté précédemment, le conseil a immobilisé les ETH liés à Kelp sans annoncer d'interruption générale pour les autres utilisateurs ou applications. La valeur citée à l'époque était d'environ 71 millions de dollars.

Les étapes suivantes impliquaient une proposition de récupération coordonnée pour les détenteurs de rsETH. Aave Labs, KelpDAO, LayerZero, EtherFi et Compound ont co-signé une proposition de libération du 25 avril.

Son objectif déclaré était de diriger les ETH immobilisés vers la restauration de la couverture des rsETH. La proposition précisait que les actifs étaient déjà gelés et que leur destination constituait la question de gouvernance restante.

Des revendications juridiques ont ensuite compliqué le processus. Un avis de restriction du 1er mai, décrit dans la couverture de la restriction judiciaire, concernait les créances de créanciers judiciaires liés au terrorisme qui soutenaient que les actifs pouvaient satisfaire des jugements contre la Corée du Nord.

La distinction historique importante est celle entre cette allégation et une décision de propriété établie. L'attribution d'un exploit à un acteur lié à un État ne répond pas, à elle seule, à toutes les questions de propriété concernant des actifs pris à une autre partie.

La couverture du vote de gouvernance du 8 mai décrivait un fort soutien à une proposition de récupération et à des dispositions d'indemnisation. Le soutien au plan et l'exposition juridique des personnes qui le mettent en œuvre étaient traités par des modalités distinctes.

La discussion amendée sur le forum public faisait ensuite référence à un transfert vers la garde d'Aave LLC sous supervision judiciaire. Cette discussion de mai constitue un contexte historique, et non la preuve que les actifs de Binance font désormais face à la même créance ou à la même procédure judiciaire.

La comparaison identifie une source de retard démontrée : un conseil peut retirer des actifs du contrôle immédiat d'un attaquant avant que le destinataire légitime et la voie de transfert licite soient établis. Aucun calendrier de restitution fixe ne découle automatiquement de la rapidité du gel initial.

Il serait donc prématuré d'attacher le statut juridique de la récupération de KelpDAO à la nouvelle détention de Binance. La proposition applicable et toute ordonnance judiciaire réelle doivent identifier les actifs et les parties qu'elles concernent.

Une adresse de détention peut contenir plus d'une récupération

Les avis d'Arbitrum identifient la même destination se terminant par 0DA0 pour les actions liées à Binance et à KelpDAO. Cela rend les registres de transfert et l'attribution des actifs particulièrement pertinents lorsque les lecteurs tentent de suivre une récupération via un explorateur.

Un solde ETH affiché est un total pour l'adresse au moment de la requête. Sans l'historique des transactions et les restrictions pertinentes, il n'identifie pas quelle portion appartient à quel incident ni si une allocation antérieure a déjà changé.

Les 8 425 ETH de l'avis de Binance constituent donc la quantité spécifique à l'incident à suivre. Substituer le solde ETH actuel total de l'adresse de détention pourrait combiner des entrées non liées, des avoirs résiduels ou des transactions ultérieures.

Le solde ARB nécessite son propre enregistrement de transfert de jetons. Additionner de l'ETH natif et un nombre de jetons ne produit aucune quantité unique utile, à moins que les deux ne soient valorisés à l'aide d'un prix et d'un horodatage divulgués.

Par exemple, une valorisation de l'allocation Binance serait de 8 425 multiplié par le prix ETH sélectionné, plus 74 559 805,2 multiplié par le prix ARB sélectionné. Le montant change lorsque l'un ou l'autre des prix change, même si aucun jeton ne quitte l'adresse de détention.

À un prix ETH illustratif de 2 200 $ et un prix ARB de 0,16 $, la formule produit environ 30,46 millions de dollars. Ce sont des données de valorisation hypothétiques, et non des prix de marché cotés ni la comptabilisation de la perte par Arbitrum.

Le calcul explique pourquoi un titre en dollars peut évoluer alors que la quantité récupérée reste fixe. Rapporter les montants de jetons préserve une référence stable pour le dossier de récupération.

Une distinction similaire s'applique aux frais et au nombre de transactions. Une transaction administrative Ethereum peut créer plusieurs messages et transferts sur un rollup, de sorte que compter uniquement la transaction de la chaîne parente ne décrit pas chaque mouvement d'actif qui en résulte.

La documentation sur le cycle de vie des transactions du réseau sépare la soumission et l'inclusion entre la chaîne parente et la chaîne enfant. Examiner une intervention exige de suivre cette relation, et non de traiter les deux chaînes comme des preuves indépendantes de récupérations en double.

Le dossier utile pour les lecteurs est donc propre à l'incident : adresse d'origine, quantités transférées, destination de détention, autorisation de libération et destinataire final. Chaque élément répond à une partie différente de la question de savoir où les actifs sont allés.

L'auto-conservation et la gouvernance du réseau couvrent des pouvoirs différents

L'auto-conservation signifie qu'un utilisateur contrôle les identifiants normalement requis pour autoriser des transactions depuis un compte. Elle ne promet pas que chaque blockchain sur laquelle le compte existe a des règles immuables ou aucune permission administrative.

L'architecture publiée d'Arbitrum comprend un séquenceur, des mécanismes de validation et de litige, des permissions de mise à niveau et une gouvernance. Chaque composant traite d'une partie différente de la manière dont les transactions sont acceptées et dont le système change.

Sa documentation sur le séquenceur décrit des modalités d'inclusion alternatives lorsque le séquenceur échoue ou censure des messages. Ces protections concernent l'ordonnancement et la disponibilité des transactions dans le cadre des règles du protocole.

Une mise à niveau logicielle d'urgence concerne les règles et les contrats privilégiés eux-mêmes. Une voie de contournement d'un séquenceur indisponible ne supprime pas la capacité distincte des acteurs de gouvernance autorisés à modifier une implémentation pouvant être mise à niveau.

La documentation sur le contrôle d'accès d'OpenZeppelin établit une distinction connexe au niveau du contrat. La propriété et les rôles déterminent quels comptes peuvent appeler des fonctions privilégiées, et un timelock peut retarder les opérations qui lui sont assignées.

La question de sécurité pratique est de savoir où ces permissions mènent. Une application peut utiliser un multisig tandis qu'un contrat réseau de niveau supérieur reste mis à niveau possible via un ensemble distinct de signataires, chacun avec ses propres règles.

Aave offre un contraste utile dans sa documentation sur la gouvernance. Elle distingue les gardiens d'urgence du protocole des gardiens d'urgence de la gouvernance, attribuant des mandats d'intervention différents à des organes différents.

Cette séparation n'établit pas que tout système utilisant un gardien est également sûr. Elle montre pourquoi le nom du rôle est moins informatif que les fonctions exactes qu'il peut appeler, les approbations requises et le processus pour le remplacer.

L'exploit de Binance lui-même impliquait un autre type d'autorité. Les enquêteurs ont décrit des autorisations de portefeuille valides dans la séquence d'attaque Ethereum, tandis que la récupération d'Arbitrum a utilisé une voie d'administration du réseau après que les actifs ont atteint sa chaîne.

Les deux événements ne doivent pas être compressés en une affirmation selon laquelle les clés privées n'ont plus d'importance. Ils démontrent que l'autorité de signature, le comportement de compte délégué et les permissions de mise à niveau du réseau sont des parties distinctes de l'environnement de sécurité d'un actif.

L'adhésion au conseil et les clés de signature exigent un examen distinct

La liste publique identifie des personnes, tandis que le multisig exige des signatures de clés particulières. Les deux registres sont pertinents : un nom sur une page d'adhésion ne montre pas en soi qu'une clé est conservée de manière sécurisée ou disponible lors d'un incident.

Les devoirs des membres d’Arbitrum exigent une sécurité opérationnelle, notamment un portefeuille matériel dédié à ce rôle. Les attentes publiées incluent la diversité entre les organisations, les emplacements et les fuseaux horaires afin de soutenir l’indépendance et une réponse rapide.

Les deux objectifs peuvent tirer dans des directions opérationnelles différentes. Les signataires ont besoin d’une séparation suffisante pour résister à une compromission commune, tandis qu’un nombre suffisant d’entre eux doit être joignable pour atteindre le seuil lorsqu’une urgence survient.

Une règle de 9 sur 12 n’élimine pas ce problème de coordination. Si 3 membres sont indisponibles, chaque membre restant doit approuver pour que l’action puisse se poursuivre ; si 4 sont indisponibles, le seuil de signature immédiat ne peut pas être atteint.

Il s’agit d’un calcul de disponibilité, et non d’une preuve que l’un ou l’autre de ces événements s’est produit pendant la réponse à Binance. La transaction publiée enregistre une intervention qui a bien eu lieu.

La présentation du conseil décrit les modalités d’élection et de révocation. Elle indique qu’un membre peut être révoqué par un vote de la DAO remplissant les conditions de participation et de supermajorité applicables, ou par l’approbation d’au moins 9 membres du conseil.

La révocation d’un décideur et la révocation d’une permission contractuelle sont des actes différents. Le système administratif doit garantir que les permissions correspondent à l’adhésion autorisée après une élection, une démission ou un remplacement.

Arbitrum publie un registre des adresses de déploiement identifiant les contrats de gouvernance, y compris l’infrastructure d’élection et de révocation. Il permet aux lecteurs de distinguer une interface de vote des contrats qui enregistrent et mettent en œuvre le résultat.

Une annonce d’élection ne constitue donc pas l’intégralité du dossier d’installation. Le changement on-chain pertinent établit quelles clés peuvent exercer le rôle par la suite.

La même distinction s’applique lorsqu’un signataire fait tourner une clé. La personne peut rester membre du conseil tandis que l’identifiant de signature autorisé change, de sorte qu’une simple comparaison des noms manquerait un événement de sécurité important.

Les documents de gouvernance d’Arbitrum décrivent des instances multisig distinctes sur Ethereum et sur les chaînes gouvernées. Leurs permissions s’appliquent aux contrats concernés, de sorte que les adresses de conseil listées ne sont pas interchangeables pour toutes les opérations.

Pour l’action concernant Binance, l’avis publié identifie une mise à niveau de contrat sur Ethereum et des transferts sur Arbitrum One. Cette relation détermine quelles permissions et quels enregistrements de transaction sont pertinents pour l’intervention.

Il existe une autre différence entre une affiliation et le contrôle d’une signature. Une relation d’employeur publique peut aider les lecteurs à évaluer la concentration, mais elle ne prouve pas que l’employeur contrôle la clé de la personne ou a ordonné un vote particulier.

La preuve d’une instruction réelle, d’un accord de garde partagée ou d’une infrastructure de signature commune répondrait à une question différente de celle d’une biographie professionnelle. L’analyse ne devrait pas convertir l’une en l’autre sans informations à l’appui.

Un rapport de transparence peut rendre ces limites plus faciles à examiner en identifiant les signataires, l’action, le moment et la raison de l’urgence. Le compte rendu du rapport peut ensuite être comparé à la transaction administrative et au mandat constitutionnel énoncé.

Modifier l’autorité à plus long terme du conseil serait une décision de gouvernance à part entière. Cela ne déterminerait pas automatiquement où les actifs Binance déjà immobilisés devraient aller, car la libération nécessite encore un destinataire défini et des instructions.

Un vote doit identifier exactement ce qui sera exécuté

Pour les détenteurs de jetons, le prochain événement concret de récupération est une proposition précisant l’allocation Binance et sa destination. L’avis actuel confie cette décision à la gouvernance mais ne fournit pas en lui-même un transfert achevé vers l’exchange.

La constitution d’Arbitrum recommande que les propositions exposent les spécifications, les étapes de mise en œuvre, les coûts et le calendrier. Une proposition impliquant un tiers devrait également inclure la documentation légale et les procédures applicables.

Les votants doivent comparer le texte descriptif avec les instructions exécutables. Une proposition peut indiquer un montant en prose tandis que la charge utile de la transaction appelle un contrat avec ses propres paramètres d’actif, de destinataire et de permission.

Le guide de gouvernance d’OpenZeppelin distingue le décompte des votes, le quorum, l’exécution des propositions et les composants de timelock. Le résultat principal d’un vote n’est qu’une étape d’un système construit à partir de ces contrats et règles distincts.

La proposition de récupération devrait préciser clairement si sa destination est un portefeuille contrôlé par un exchange, un multisig de récupération ou un intermédiaire soumis à des conditions supplémentaires. La partie qui contrôle la destination détermine qui peut agir une fois le transfert DAO effectué.

Tout arrangement distinct de garde ou d'indemnisation devrait être attribué à ses termes réels. La discussion de KelpDAO montre que de tels arrangements peuvent faire partie d'un processus de récupération, mais elle ne fournit pas de termes par défaut pour un nouvel incident.

La responsabilité des signataires se poursuit après le transfert d'urgence. L'exigence constitutionnelle de transparence concerne tant la justification de l'action que ce que le code a fait.

Ce rapport peut être comparé au registre des transactions, à l'identification déclarée de l'adresse liée à l'exploiteur et aux limites décrites dans l'avis public. Une libération finale ajoute un autre événement observable à cette séquence.

La déclaration d'Arbitrum du 30 octobre situe les actifs liés à Binance à l'adresse 0x0000000000000000000000000000000000000DA0 et indique qu'un vote de gouvernance est requis pour les déplacer.

Points à surveiller

• Proposition de libération : Les quantités spécifiques à l'incident, le destinataire proposé et les instructions exécutables soumis à la gouvernance.
• Rapport du conseil : La base documentée de l'action d'urgence et les approbations impliquées.
• Mouvements de rétention : Les transferts attribuables à l'allocation Binance, séparément des autres actifs à la même adresse.
• Conditions juridiques : Toute ordonnance ou arrangement de garde réel régissant la libération proposée.
• Exécution : La transaction finale transférant les fonds après approbation et achèvement des périodes d'attente applicables.

FAQ