MetaMask quitte la validation : où va l'ETH staké ?

MetaMask a commencé à mettre hors ligne les validateurs Ethereum concernés après avoir divulgué un incident de sécurité dans une partie de son infrastructure. L'entreprise affirme que les clés de retrait des clients sont hors de son contrôle. Cette distinction est importante, mais elle ne rend pas la transition instantanée : une sortie, un retrait et le lancement d'un validateur de remplacement sont trois événements différents.

La divulgation identifie une sortie, pas une violation de portefeuille

La mise à jour du 30 septembre de MetaMask indique que l'entreprise répond à un incident en cours affectant une partie de son infrastructure. Elle affirme n'avoir trouvé aucune menace immédiate pour les portefeuilles MetaMask. Par précaution, elle sort les validateurs concernés au sein de ses opérations de staking non dépositaire en coordination avec les clients et les partenaires. Elle déclare également ne pas gérer les clés de retrait pour le stake des clients. La déclaration n'identifie pas le composant compromis, le nombre de clés de validateur, le montant staké, les clients concernés, l'heure exacte de la découverte ou une perte.

Ces omissions ne sont pas interchangeables. Un utilisateur de portefeuille qui n'a jamais utilisé le service de staking de MetaMask a une exposition différente de celle d'une institution dont les opérations de validateur utilisent l'infrastructure concernée. Même parmi les clients de staking, l'exposition possible d'une clé d'opérateur et l'exposition possible d'une clé de retrait mènent à des résultats différents. La déclaration publique soutient l'inquiétude concernant la continuité du service et une réponse de sécurité active. Elle n'établit pas que l'ETH des clients a été volé, que chaque validateur MetaMask est affecté ou que les clés de portefeuille ordinaires ont été exposées.

L'entreprise avait lancé Validator Staking via MetaMask Portfolio comme un arrangement dans lequel les clients fournissent le stake tandis qu'un fournisseur exploite les nœuds validateurs. La description antérieure du produit est un contexte utile, bien qu'elle ne puisse pas nous dire quel produit ou cohorte de clients actuel l'incident de septembre touche. MetaMask a depuis séparé son identité d'entreprise de Consensys, une autre raison de ne pas fusionner plusieurs marques, entités opératrices et produits de staking en un seul pool affecté sans une nouvelle divulgation.

La première correction observable au dossier public sera une déclaration de portée. Un avis d'incident est un compte horodaté de ce qu'une entreprise sait, pas un rapport médico-légal complet. Si MetaMask divulgue ultérieurement l'ensemble de clés concerné, les identifiants de retrait clients pertinents et si un validateur a été pénalisé ou a manqué des tâches, l'analyse pourra devenir spécifique. D'ici là, la description défendable est plus étroite : des sorties par précaution sont en cours et le montant d'ETH impliqué est inconnu.

Un validateur peut cesser de signer sans que le client reçoive de l'ETH

Le staking Ethereum sépare au moins trois étapes souvent décrites comme un seul retrait. Un opérateur initie une sortie volontaire ou, lorsque cela est pris en charge, un détenteur d'identifiant de retrait peut en déclencher une en utilisant des mécanismes de la couche d'exécution. Le validateur attend son tour dans la file de sortie, cesse d'assumer de nouvelles tâches lorsque la sortie devient effective, puis attend que le solde devienne retirable et que le protocole le transfère vers l'adresse de retrait désignée. Un nouveau validateur, si un tel lancement est prévu, fait également face à la file d'entrée.

La documentation d'Ethereum sur les retraits distingue un validateur hérité avec un solde effectif de 32 ETH d'un validateur à composition dont le solde effectif peut atteindre 2 048 ETH. Ce dernier modifie le calcul naïf selon lequel un validateur signifie toujours exactement 32 ETH. L'avis public de MetaMask ne précise pas quels identifiants ou types de validateurs sont concernés. Multiplier un nombre deviné de validateurs par 32 créerait une estimation qui semble précise mais manque des deux entrées.

Une sortie n'implique pas nécessairement une vente. L'ETH peut passer de la couche de consensus à l'adresse de retrait contrôlée par le client et être ensuite déposé auprès d'un autre opérateur, ou il peut y rester. Un produit différent peut acheminer les produits via les contrats propres d'un pool de staking. Sans les identifiants de retrait et les instructions du client, aucun observateur ne peut affirmer que ces fonds vont vers un exchange. Même un retrait visible est la preuve d'un transfert vers une adresse désignée, et non d'une transaction à la destination suivante de cette adresse.

Pour le staking liquide, il existe un autre registre entre le validateur et le détenteur. La documentation de Lido sur la sortie des validateurs décrit le message de sortie de l'opérateur, la comptabilité de l'oracle et le reporting du solde de retrait. Un détenteur de token peut continuer à détenir une créance de staking liquide tandis que les validateurs sous-jacents tournent. Inversement, une demande de remboursement d'un token de staking liquide par un détenteur peut entraîner des sorties au niveau du protocole lorsque la liquidité disponible est insuffisante. Le flux à travers ces registres ne peut pas être déduit simplement du mot « exit » dans l'avis de MetaMask.

La séparation clé définit la frontière de sécurité

Une clé de signature de validateur autorise les attestations et les blocs. Un identifiant de retrait pointe vers la destination de l'ETH retiré et, selon son type, peut permettre une demande de sortie au niveau de la couche d'exécution. L'opérateur a normalement besoin du premier pour faire fonctionner un validateur. Le client devrait conserver l'autorité sur le second dans un service non dépositaire. La déclaration de MetaMask repose sur cette division : elle indique qu'elle ne gère pas les clés de retrait des clients.

C'est une protection significative contre le détournement direct du principal via une destination de retrait modifiée. Ce n'est pas une garantie absolue contre toutes les pertes de staking. Un opérateur dont l'environnement de signature est compromis peut manquer à ses obligations ou, dans le pire des cas, signer des messages contradictoires et faire face à une réduction (slashing). Le guide des récompenses et pénalités d'Ethereum distingue les pénalités ordinaires pour manquement aux obligations de la réduction pour infractions de consensus prouvables. Une sortie ordonnée planifiée peut réduire le temps pendant lequel une clé de signature potentiellement compromise reste active. Elle ne peut pas annuler les pénalités déjà encourues, et elle ne peut pas indiquer aux clients combien de temps prend l'activation d'un remplaçant.

La distinction établit également une charge de la preuve. Pour affirmer que le principal est sécurisé, il faudrait obtenir la confirmation que les identifiants de retrait restent inchangés et qu'aucune sortie ou aucun retrait non autorisé n'a eu lieu. Pour affirmer une compromission de la clé de signature, il faudrait des preuves concernant le système de garde des clés et le comportement on-chain, et non la seule existence d'une sortie. MetaMask n'a pas publiquement attribué l'incident à l'une ou l'autre catégorie de clé. Son choix de sortir peut être prudent même si les enquêteurs ne trouvent finalement aucune clé de validateur exploitable.

La séparation technique a une conséquence économique. Un client peut conserver l'ETH tout en perdant certaines récompenses attendues pendant la transition. Un validateur qui ne gagne plus de récompenses pendant qu'il est hors service actif ne peut pas rattraper ce temps en affirmant que la mise initiale était sûre. La sécurité du principal et la continuité du rendement sont des promesses de service différentes. Les récents travaux de consolidation de Lido compliquent davantage toute approximation simple du nombre de clés : le type d'identifiant et le solde effectif déterminent combien de mise représente un validateur.

Les chiffres publics ne permettent pas d'établir un total d'exposition

Un calcul courant consisterait à multiplier les validateurs affectés par 32 ETH. Le seul chiffre fourni dans la déclaration d'incident est inexistant : MetaMask n'a pas indiqué combien de validateurs elle sort. Ethereum permet désormais également des validateurs à capitalisation au-delà de 32 ETH. L'arithmétique comporte donc deux termes manquants, et non un seul. Si 100 validateurs hérités hypothétiques étaient affectés, leur mise effective initiale serait de 3 200 ETH. Cet exemple est une conversion d'unités, et non une affirmation concernant cet incident. Il serait erroné de placer 3 200 ETH dans un titre sans un nombre réel de validateurs.

Un autre raccourci tentant consiste à examiner la file de sortie agrégée de la chaîne. Il s'agit d'un total à l'échelle du réseau, et non d'une liste de clients MetaMask. D'autres institutions, pools de staking et opérateurs solo peuvent entrer ou sortir de la file le même jour. Une file en hausse après la divulgation établirait une demande simultanée de sortie, mais pas une attribution à MetaMask. Les indices de validateurs individuels liés à l'opérateur, associés à une déclaration de périmètre publiée, pourraient affiner l'estimation. Un tableau de bord qui regroupe uniquement par graffiti ou par source de dépôt pourrait mal classer les clients, le stake mutualisé ou une réaffectation ultérieure.

Le désengagement antérieur de la Fondation Ethereum montre comment un retrait important visible peut attirer une histoire de marché avant que l'objectif du portefeuille récepteur ne soit clair. L'événement MetaMask est plus opaque. Aucun solde d'incident public actuel ne peut être vérifié à partir du court avis de l'entreprise. Les lecteurs devraient être sceptiques à l'égard d'un chiffre d'ETH en circulation à moins que son auteur ne fournisse une liste reproductible d'indices de validateurs, de types d'informations d'identification et d'adresses de retrait, avec une méthode pour exclure les validateurs non concernés.

Il existe également une distinction de reporting entre les actifs à risque et les actifs retardés. Les premiers dépendent d'un chemin réel vers une perte, tel qu'un slashing, un contrôle non autorisé ou un contrat affecté. Les seconds peuvent résulter d'un changement préventif même lorsque la garde est maintenue. Sans mécanisme d'incident ou déclarations au niveau des clients, ces catégories ne peuvent pas être quantifiées ensemble. Le meilleur chiffre dans cette histoire pourrait rester un chiffre manquant jusqu'à ce que les enquêteurs ou les opérateurs publient davantage.

La capacité de sortie appartient à la chaîne, pas au fournisseur

Ethereum limite la vitesse à laquelle les validateurs peuvent sortir. La file de sortie n'est pas une retenue arbitraire imposée par MetaMask ; c'est un mécanisme de protocole qui répartit les départs dans le temps. Sa longueur dépend du nombre de validateurs à travers Ethereum qui tentent de sortir, de l'ensemble actif de validateurs du réseau et des limites de rotation applicables. Après la sortie, l'éligibilité au retrait et le balayage vers l'information d'identification de retrait ajoutent des étapes. Le guide de retrait du staking avertit les utilisateurs de staking mutualisé de vérifier auprès de leur fournisseur, car les produits gèrent le chemin différemment.

Si un client souhaite continuer à staker, les fonds peuvent faire un second voyage. Une fois accessibles à la destination de retrait autorisée, ils peuvent être redéposés sous une nouvelle clé de validateur et peut-être un opérateur différent. L'activation a également une file d'attente. Ce sont des attentes séquentielles lorsque le service retire et redépose réellement le principal. Un service capable de modifier certaines parties de sa configuration opérationnelle tout en conservant les validateurs peut avoir un chemin différent, mais MetaMask a déclaré qu'il sortait les validateurs concernés, de sorte que le scénario plus rapide de changement d'opérateur ne doit pas être présumé pour ces clés.

Le coût n'est pas un pourcentage fixe. Un exemple simple de coût d'opportunité montre la sensibilité : 32 ETH à un taux brut annuel supposé de 3 % génèrent environ 0,00263 ETH sur une journée, soit environ 0,0395 ETH sur 15 jours. Il s'agit d'arithmétique, pas d'une prévision pour les rendements actuels ou les clients MetaMask. Le type de validateur, les accords de frais, les attestations manquées, les récompenses de la couche d'exécution et la durée hors service actif modifient tous le résultat réel. Le point est que le temps entre une sortie effective et une nouvelle activation compte même lorsque le principal de 32 ETH est intact.

Une estimation spectaculaire de la file d'attente nécessite également de la prudence. Un service peut citer une période de bout en bout à la limite supérieure qui inclut une sortie, un balayage, un traitement client et une réentrée ; un tableau de bord de chaîne peut n'afficher que la première de ces étapes. Comparer les deux comme s'ils mesuraient le même intervalle crée une fausse divergence. Un client concerné a besoin d'une séquence de dates de la part du fournisseur : demande de sortie, sortie effective, époque retirable, fonds reçus à l'information d'identification, autorisation de redépôt et activation d'un remplaçant.

Une sortie préventive est une réponse coûteuse mais défendable

L'argument le plus solide en faveur de l'action de MetaMask est qu'elle limite la durée de l'exposition potentielle pendant que le travail médico-légal se poursuit. Un environnement de signature compromis ne peut pas continuer à produire des signatures risquées pour un validateur après sa sortie complète. Lorsque les limites de l'incident sont incertaines, retirer les clés opérationnelles potentiellement exposées est plus conservateur que de demander aux clients d'attendre une attribution parfaite. La déclaration de l'entreprise selon laquelle elle n'a trouvé aucune menace immédiate pour les portefeuilles est également importante : elle n'a pas demandé aux utilisateurs ordinaires de portefeuilles de migrer des clés ou de retirer des actifs.

Un client peut néanmoins raisonnablement demander pourquoi une sortie était nécessaire si aucun portefeuille n'était menacé. La réponse réside dans les différents domaines de sécurité. L'accès au portefeuille et l'exploitation des validateurs sont des services différents. La formulation de MetaMask ne divulgue pas le composant d'infrastructure ni ne prouve si un attaquant a touché l'un ou l'autre. Une précaution peut s'avérer avoir été plus large que nécessaire ; un rapport médico-légal peut le clarifier plus tard. Il est possible d'accepter une sortie défensive rapide comme prudente tout en insistant pour obtenir un compte rendu précis de son coût et de sa portée.

Des reportages récents sur les opérateurs de staking distribué indiquent un objectif de conception alternatif : réduire la dépendance opérationnelle à un seul signataire ou hôte. De tels systèmes ont leurs propres modes de coordination et de défaillance. Ils n'éliminent pas rétroactivement la nécessité de sortir un validateur dont l'environnement de signature réel peut être suspect. Une institution ne peut pas non plus simplement revendiquer une diversification parce que plusieurs entités juridiques apparaissent sur une page produit. La question pertinente est de savoir où réside l'autorité de signature et comment elle est renouvelée après un incident.

Une bonne mise à jour d'incident séparerait les faits confirmés des choix de remédiation. Elle indiquerait s'il y a eu signature non autorisée, si des tâches ont été manquées, combien d'indices de validateur sont concernés et si les identifiants de retrait ont été vérifiés. Si ces réponses ne sont pas encore connues, la mise à jour devrait le dire. Les clients peuvent alors distinguer une pause opérationnelle d'une perte de principal sans se fier à des graphiques de file d'attente anonymes.

Les clients doivent cartographier leur propre contrat, pas seulement la chaîne

Un client de staking non-custodial a toujours un contrat de service, une relation avec un opérateur et une destination de retrait spécifique. Ces détails déterminent qui initie une sortie, qui peut décider où va l'ETH après le retrait, qui supporte un coût d'indisponibilité et quelle communication le client reçoit. Si le produit utilise un protocole de staking mutualisé, les détenteurs de jetons peuvent avoir une créance sur un pool plutôt qu'un contrôle direct sur chaque validateur. S'il s'agit de staking de validateurs dédiés, un client peut être en mesure d'identifier des indices de validateur et des identifiants spécifiques.

Commencez par les enregistrements de dépôt. La clé publique du validateur et l'identifiant de retrait peuvent être comparés à ce que le produit montrait lors de l'intégration. Un client ne devrait pas coller une phrase de récupération dans un formulaire d'incident ni accepter un message disant qu'un transfert de clé d'urgence est obligatoire. La divulgation de MetaMask n'annonce pas de migration de portefeuille. Les canaux officiels du produit et les URL saisies indépendamment importent particulièrement lorsqu'un incident de sécurité crée une ouverture pour des usurpateurs.

Ensuite, distinguez trois champs de statut : sortie en attente, sorti et retiré. Sortie en attente signifie que le validateur reste dans la file d'attente et peut encore avoir des tâches. Sorti signifie qu'il ne participe plus aux tâches normales de consensus. Retiré signifie que le solde a effectivement atteint sa destination. Le tableau de bord interne d'un opérateur peut utiliser « terminé » pour sa propre étape administrative, de sorte que le client devrait demander l'indice de validateur sous-jacent et la preuve de transaction ou d'époque. Le moment où les récompenses s'arrêtent n'est pas nécessairement le moment où l'utilisateur voit de l'ETH dans un portefeuille.

Enfin, posez des questions sur l'autorisation de remplacement. Un fournisseur ne devrait pas supposer qu'un client qui a autorisé le staking via un ensemble de clés souhaite un redépôt automatique après un incident de sécurité. Certains clients préféreront une nouvelle diligence raisonnable sur l'opérateur ; d'autres privilégieront la restauration des récompenses. Le modèle de permission du service décide de ce qui peut se produire sans une nouvelle signature. C'est une question plus importante que de deviner si le marché absorbera l'ETH retiré.

Le registre des pertes comporte quatre colonnes distinctes

Une comptabilité finale devrait distinguer le principal, les pénalités de protocole, les récompenses impayées et les frais de service. Ceux-ci sont souvent regroupés en une seule affirmation selon laquelle les clients étaient soit « en sécurité », soit « affectés ». Le principal est le solde qui arrive finalement à l'identifiant de retrait, net des changements de protocole au solde du validateur. Les pénalités sont des débits causés par des tâches manquées ou une inconduite prouvable pendant que le validateur reste actif. Les récompenses impayées sont contrefactuelles : ce qu'un validateur actif également situé aurait pu gagner pendant l'intervalle. Les frais de service dépendent d'un contrat et peuvent ou non s'accumuler tant qu'aucun validateur n'est actif.

Prenons un validateur hérité dédié avec un dépôt initial de 32 ETH. Supposons qu'il sorte normalement avec un solde de 32,4 ETH et que la totalité des 32,4 atteigne l'identifiant du client. Le principal et le solde accumulé sont arrivés ; cela ne signifie pas que sa sortie et sa réentrée n'ont eu aucun coût. Si son remplaçant était inactif pendant un mois, les récompenses perdues sont mesurées par rapport au rendement qu'un validateur en fonctionnement aurait pu gagner ce mois-là. Ce rendement est variable et ne peut pas être récupéré en soustrayant 32 de 32,4. Cette dernière différence inclut les récompenses accumulées avant la sortie et ne dit rien sur l'intervalle.

Inversement, un solde de retrait inférieur aux attentes n'est pas automatiquement une preuve de vol. Il pourrait refléter des pénalités de consensus, la performance réelle du validateur avant l'incident ou une convention comptable pour les parts de pool. L'opérateur devrait réconcilier le solde à une époque spécifiée, le montant final de retrait, toutes les pénalités de consensus, les récompenses de la couche d'exécution et chaque frais facturé. Ce registre nécessite l'indice de validateur et une période de mesure commune. Si l'opérateur rembourse les récompenses ou pénalités manquées en vertu d'une promesse de service, le paiement doit être enregistré séparément de ce qu'Ethereum a retourné.

Les produits mutualisés ajoutent une couche supplémentaire. Un détenteur individuel peut voir un solde de jetons ou un taux de change tandis que le pool fait tourner les validateurs sous-jacents. Pour ce client, le rapprochement pertinent inclut les passifs du pool, les droits de rachat et la part de toute perte supportée par les opérateurs, les fonds d'assurance ou les détenteurs. Un simple reçu de validateur on-chain ne peut pas établir le résultat pour le détenteur. L'intégration de la garde Lido d'Anchorage illustre pourquoi la partie qui détient un compte, l'opérateur qui signe et le protocole qui comptabilise les créances mutualisées peuvent tous différer. L'avis du 30 septembre n'identifie pas quel arrangement s'applique à chaque client affecté.

C'est la question à laquelle un examen ultérieur de l'incident devrait répondre : qu'est-ce qui a été perdu ou retardé, pour qui, et en vertu de quel contrat ? Un rapport qui se contente de dire que les retraits ont été effectués laisserait les colonnes de récompenses et de pénalités sans réponse. Un rapport qui cite un rendement agrégé masquerait les variations entre les dates de sortie. Le registre, publié après suppression des identifiants clients sensibles, permettrait aux clients d'évaluer une réponse qui, autrement, semble identique que dix validateurs ou des milliers aient été retirés.

Le signal de marché est plus faible que le signal opérationnel

Une longue file d'attente de sortie de validateurs peut affecter les récits sur l'offre d'ETH, mais cette divulgation ne fournit aucun montant. L'ETH sorti n'a pas besoin d'être vendu. Il peut attendre de rentrer sous de nouvelles clés, être déplacé vers un autre produit de staking ou être conservé par le propriétaire d'origine. Un graphique de prix ne peut pas révéler quel choix un client a fait. Le changement directement observable est que les validateurs quittent le service actif, ce qui peut modifier modestement le stake actif du réseau et la distribution des récompenses. L'effet financier pour le client dépend du temps d'arrêt réel et des éventuelles pénalités.

L'incident peut soulever une question plus large pour les fournisseurs de staking : à quelle vitesse peuvent-ils retirer un ensemble de validateurs compromis sans imposer une longue interruption au rendement des clients ? C'est une qualité opérationnelle mesurable. Elle exige de publier le nombre de clés affectées et les dates à chaque étape, et pas seulement de dire que le principal n'est pas sous garde. Les concurrents peuvent vanter une architecture de clés différente ; ces affirmations devraient être testées par rapport à un contrôle documenté des retraits et à des procédures d'incident.

Les limites du dossier actuel sont flagrantes. Il n'y a aucune perte divulguée, aucun chemin d'attaque confirmé, aucune liste de validateurs publiée et aucun stake total vérifié dans l'avis de MetaMask en date du 1er octobre. L'entreprise peut réduire ou élargir la portée. Un observateur de la chaîne peut identifier indépendamment certaines sorties, mais attribuer chacune d'elles à l'incident nécessite une corroboration. Un article qui présenterait aujourd'hui un flux précis d'ETH comblerait ces lacunes par des conjectures.

La réponse au titre est donc conditionnelle mais utile. L'ETH staké reste lié à chaque validateur jusqu'à ce que le protocole le libère vers la destination de retrait désignée de ce validateur. MetaMask affirme que ce sont les clients, et non MetaMask, qui contrôlent les clés de retrait. Ce qui se passe après réception dépend du client et du produit. La sortie opérationnelle est en cours. La destination finale des fonds est une décision distincte qui reste à observer.

Ce qu'un audit indépendant pourrait réellement vérifier

Un examinateur externe commencerait par les données de dépôt et les identifiants de retrait des validateurs affectés, puis les comparerait avec l'inventaire d'incident de MetaMask. La liste n'a pas besoin de révéler les noms des clients. Elle pourrait publier les indices des validateurs ou des engagements cryptographiques ainsi que les soldes agrégés et préciser l'époque de coupure. Cela rendrait la portée reproductible tout en laissant les identités des clients dans les dossiers privés du fournisseur. Si l'entreprise ne peut pas divulguer les indices pendant une enquête active, elle peut tout de même indiquer le nombre, les classes d'identifiants et la méthode utilisée pour les rapprocher.

La deuxième vérification est l'ordre des événements. Chaque validateur affecté a-t-il cessé de signer avant que sa sortie ne prenne effet ? Y a-t-il eu une infraction passible de slashing ou une période de manquement mesurable ? Une transaction de sortie ou un message de sortie signé ne peut pas répondre à la première question ; un validateur peut rester actif pendant qu'il est en file d'attente. Les enregistrements publics de la chaîne Beacon peuvent montrer les attestations, les propositions, les époques de sortie et les retraits pour des indices de validateurs connus. Ils ne peuvent pas révéler quel serveur a été compromis ni à quoi un attaquant pouvait accéder. Une affirmation médico-légale sur la cause racine nécessiterait des journaux, des enregistrements d'accès et des tests indépendants de l'infrastructure affectée.

La quatrième vérification est de savoir qui a payé pour l'interruption. Un fournisseur pourrait créditer les clients pour le temps d'arrêt, renoncer à des frais ou invoquer des conditions selon lesquelles les récompenses variables du réseau n'ont jamais été garanties. Aucun de ces résultats n'est impliqué par un retrait réussi. Pour les validateurs dédiés, l'audit peut indiquer les récompenses réalisées et les pénalités de manquement par cohorte. Pour un pool, il devrait rapprocher la comptabilisation des parts et toute assurance ou caution d'opérateur utilisée pour absorber les pertes. Un seul pourcentage de rendement en titre masquerait les deux.

Un examen indépendant qui rapporte ces quatre vérifications répondrait à la question que se posent réellement les lecteurs. Il montrerait si la précaution a protégé le contrôle des retraits, si la signature a produit une perte de protocole, où le solde a atterri et qui a supporté le coût de la réintégration. En l'absence de ce registre, le public peut évaluer la logique de la réponse mais pas certifier son résultat. La prochaine mise à jour de l'entreprise devrait réduire cette frontière.

Ce qu'il faut surveiller

• Divulgation de la portée : Une mise à jour de MetaMask qui donne le nombre d'indices de validateurs affectés, de stake et de lignes de produits.
• Vérifications des identifiants : Une déclaration confirmant les identifiants de retrait et si une signature non autorisée ou un slashing s'est produit.
• Achèvement de la sortie : Des époques de sortie vérifiables publiquement pour les validateurs affectés identifiés, distinguées des demandes encore en file d'attente.
• Reçus de retrait : La preuve que les soldes sont arrivés aux destinations de retrait autorisées, avec la comptabilisation des pénalités ou des récompenses manquées.
• Activation du remplacement : Les redépôts approuvés par le client, les nouvelles clés de signature et la date à laquelle les validateurs de remplacement reprennent leurs fonctions.

FAQ