Peut-on encore retirer ses fonds de Base ou d'Arbitrum si le séquenceur tombe en panne ?

Un rollup peut maintenir une route Ethereum ouverte pour les utilisateurs dont les transactions sont bloquées au niveau du séquenceur. Cette route gère l'inclusion des transactions. Récupérer les fonds vers Ethereum dépend aussi de la capacité à prouver et à finaliser le retrait du rollup selon les règles du bridge.

Considérons deux utilisateurs qui détiennent de l'ETH, l'un sur Base et l'autre sur Arbitrum One. Tous deux utilisent le bridge officiel, mais ils tentent de partir à des moments différents d'une panne. Un retrait figure déjà dans les registres du rollup. L'autre doit encore faire accepter une transaction.

Ethereum peut offrir une alternative à la route normale du séquenceur. Que cela permette à l'un ou l'autre utilisateur d'aller au bout dépend de l'étape suivante du bridge et de si les personnes capables de modifier ou de suspendre les contrats ont agi.

Un retrait comporte plus d'une étape

En fonctionnement ordinaire, un utilisateur commence par envoyer une transaction de retrait sur le rollup. Le séquenceur l'ordonne avec d'autres transactions. Le retrait via le bridge peut ensuite être établi sur Ethereum une fois l'état pertinent du rollup disponible et les exigences applicables de preuve et d'attente satisfaites.

Les deux transactions peuvent sembler être une seule action dans un portefeuille. La première enregistre le retrait sur le rollup. Une action ultérieure peut le finaliser sur Ethereum. Un utilisateur qui peut voir la première transaction dans un explorateur a la preuve qu'elle a été incluse, même si les fonds ne sont toujours pas disponibles sur Ethereum.

La route contournant le séquenceur

La documentation d'Arbitrum sur les transactions forcées décrit une route passant par son Delayed Inbox sur Ethereum. Une transaction peut y attendre avant de devenir éligible à l'inclusion forcée. Cette période est distincte du temps nécessaire pour finaliser un retrait vers Ethereum.

La spécification de dérivation de Base décrit les dépôts dérivés d'Ethereum, y compris la route du protocole pour l'inclusion forcée. La comparaison utile est de savoir si l'utilisateur peut initier l'action nécessaire via Ethereum, combien de temps le protocole peut prendre pour l'inclure et ce qui doit encore se produire après l'inclusion.

Le recours peut impliquer des frais de transaction Ethereum. Il dépend aussi de la capacité de l'utilisateur ou du service agissant pour lui à soumettre le bon message. Un portefeuille dont la connexion à son point de terminaison habituel est rompue peut avoir besoin d'une interface différente pour utiliser une route de chaîne fonctionnelle.

Une mise à niveau d'urgence teste une protection différente

Une panne soulève la question de savoir si une transaction peut atteindre le rollup. Une mise à niveau soulève la question de savoir qui peut modifier les contrats qui déterminent si le retrait sera honoré. Une route de transaction forcée ne préserve pas en soi les règles existantes jusqu'à ce qu'un utilisateur puisse finaliser le retrait.

ETHBEAT liste Base et Arbitrum One comme Stage 1. Son évaluation ne montre aucune fenêtre de sortie pour Base et distingue les mises à niveau régulières des mises à niveau d'urgence pour Arbitrum One. Le chemin régulier d'Arbitrum liste une fenêtre de 10 jours, tandis que le chemin d'urgence n'a pas une telle fenêtre.

Cette différence explique pourquoi une note de Niveau 1 seule ne peut pas répondre au temps dont dispose un utilisateur pour partir. Un délai de préavis doit être considéré avec le temps nécessaire pour initier, prouver et finaliser un retrait. La période pertinente est le temps restant après prise en compte des étapes que l'utilisateur doit accomplir.

Un pont tiers ajoute ses propres conditions

Un pont rapide peut payer l'utilisateur à partir de la liquidité qu'il détient déjà sur Ethereum tandis qu'il règle sa propre position plus tard. Cela peut rendre le retrait visible plus rapide en fonctionnement normal. Cela introduit également un fournisseur dont la liquidité et la politique opérationnelle comptent lorsque le rollup est sous tension.

L'actif compte aussi. Un solde émis via un pont tiers peut dépendre des contrats de ce pont même s'il est détenu sur Base ou Arbitrum. Une évaluation du mécanisme de sortie officiel du rollup ne peut pas à elle seule établir ce qu'un émetteur externe remboursera.

Une comparaison équitable ferait passer le même type d'actif par les deux ponts officiels et enregistrerait les premières étapes d'inclusion, de preuve et de finalisation. Elle comparerait ensuite ce qui change si le séquenceur s'arrête et ce qu'une mise à niveau d'urgence peut faire avant que l'un ou l'autre retrait ne se termine.

Commencez par le même retrait sur les deux réseaux

Prenez un utilisateur qui détient de l'ETH natif sur chaque réseau et souhaite récupérer l'ETH sur Ethereum. Utiliser le même actif facilite la comparaison car cela évite les règles de remboursement distinctes qui peuvent s'appliquer aux jetons enveloppés. Le pont officiel a toujours besoin de preuves que le retrait a commencé et que l'état le contenant a été accepté selon les règles du rollup.

En fonctionnement ordinaire, l'utilisateur soumet une instruction sur le rollup. Son inclusion produit un enregistrement que le système de retrait peut ensuite reconnaître. L'utilisateur ou une interface agissant pour lui peut alors effectuer les étapes requises sur Ethereum. Les fonds deviennent disponibles sur Ethereum une fois que le contrat de pont concerné exécute le retrait.

Le portefeuille peut afficher plusieurs types de progression. Il peut montrer que le séquenceur a accepté la transaction, qu'un lot a atteint Ethereum ou qu'un retrait est prêt pour une étape ultérieure. Ces libellés décrivent des événements différents. Une interface qui affiche une transaction comme confirmée peut encore décrire son statut sur le rollup.

Un retrait qui a commencé avant une panne est également différent d'un retrait que l'utilisateur n'a pas encore initié. Si la transaction et l'état nécessaires pour la soutenir ont déjà atteint Ethereum, le travail restant peut avoir lieu là-bas. Si la seule preuve est une réponse récente du séquenceur, l'utilisateur a encore besoin des données et de l'état pertinents pour traverser le reste du système.

La distinction aide à expliquer pourquoi la première question utile lors d'une panne est de savoir où le retrait s'est arrêté. Une transaction de rollup manquante appelle une voie vers l'inclusion. Un retrait déjà enregistré sur le rollup peut attendre l'étape de preuve ou de finalisation. L'action suivante dépend de l'étape que le réseau a atteinte.

Ce qui change lorsque le séquenceur s'arrête

Le séquenceur donne normalement à l'utilisateur une voie rapide pour faire ordonner une transaction. Si le service cesse de répondre, une transaction soumise peut ne pas apparaître même si Ethereum continue de fonctionner. Une voie passant par Ethereum donne aux utilisateurs un moyen d'insérer un message dans les entrées du rollup sans attendre le retour de son point de terminaison normal.

Sur Arbitrum One, Ethereum enregistre les messages dans la Delayed Inbox. Un séquenceur peut les inclure dans le cours normal. Si un message y reste au-delà de l'attente applicable, la voie d'inclusion forcée peut l'intégrer à la séquence. La transaction Ethereum enregistrant le message et la transaction de rollup l'exécutant restent des observations distinctes.

Sur Base, les dépôts enregistrés sur Ethereum deviennent des entrées pour les règles de dérivation du rollup. Le terme dépôt peut être trompeur dans ce contexte car il désigne aussi un type de message par lequel une transaction Ethereum peut déclencher une action sur le rollup. L'opération de rollup souhaitée par l'utilisateur doit encore s'exécuter avec succès après inclusion.

Les pages de projet d'ETHBEAT décrivent le délai dans les conditions qu'elles modélisent. L'estimation s'applique à l'étape de repli et peut différer entre les deux réseaux. Elle ne transforme pas un pont rollup-vers-Ethereum en retrait immédiat. Un paiement final dépend encore de l'acceptation par le pont de l'état résultant et de l'achèvement de ses propres étapes.

L'utilisateur a également besoin des moyens de soumettre la transaction Ethereum. Quelqu'un dont tout le solde est sur le rollup peut avoir besoin d'accéder à de l'ETH sur Ethereum pour le repli. Une application qui gère cela pour les utilisateurs dans des conditions ordinaires peut faire face à la même contrainte pratique si elle dépend du point de terminaison défaillant ou n'expose pas la voie Ethereum.

Un destinataire doit également distinguer une demande échouée d'une soumission onchain réussie qui n'a pas encore pris effet. Un hash de transaction provenant d'Ethereum établit que le message de repli a été soumis si son reçu le confirme. Il n'établit pas le résultat de l'exécution ultérieure sur le rollup.

Quand le réseau continue de produire des blocs mais que les retraits stagnent

Un réseau peut produire des transactions tandis qu'une autre partie du processus de retrait est retardée. Les contrats sur Ethereum ont besoin d'un compte rendu reconnu de ce qui s'est passé sur le rollup. Un retard dans la publication ou l'établissement de cet état peut laisser les utilisateurs en attente après que le séquenceur a déjà renvoyé un résultat réussi.

La distinction provient des différentes tâches impliquées. Le séquenceur ordonne les transactions. La disponibilité des données permet à d'autres parties de reconstruire ce qui a été ordonné. Les systèmes de proposition et de preuve établissent quel état résultant les contrats Ethereum doivent reconnaître. Un service peut accomplir l'une de ces tâches tandis qu'une autre est en attente.

Pour un observateur, un explorateur de blocs affichant encore de l'activité est donc un test incomplet. L'observateur peut comparer l'inclusion récente de transactions sur le rollup avec les enregistrements Ethereum de l'état ou des revendications dont dépendent les retraits. Un écart entre les deux aide à identifier si le goulot d'étranglement se situe plus tôt ou plus tard.

ETHBEAT distingue la défaillance du séquenceur de la défaillance du proposeur parce que le repli de l'un ne résout pas nécessairement l'autre. Ses catégories sont un moyen de voir quel acteur peut intervenir lorsque l'opérateur habituel est absent. Elles doivent être lues avec les conditions et le délai décrits pour chaque projet.

Le même principe s'applique aux signalements de service dégradé. Un front end peut être indisponible tandis que les contrats restent appelables. Un explorateur peut être en retard tandis que la chaîne avance. Une interface de pont peut désactiver les soumissions pendant un incident même si une autre interface peut encore atteindre les contrats. Chaque cas doit être vérifié à la couche où il se produit.

Crypto.news a rapporté que Base a subi une panne de 33 minutes en août 2025. Cet incident fournit un cas pour demander quelles actions des utilisateurs ont été interrompues et quelles alternatives restaient disponibles. Sa durée n'établit pas comment un événement futur impliquant un composant différent affecterait les retraits.

L'attente après l'inclusion appartient au pont

Une fois qu'un retrait est dans l'état du rollup, il doit encore satisfaire les conditions de preuve et de finalisation du pont. Les conceptions optimistes donnent aux participants la possibilité de contester une revendication incorrecte. Le délai peut être une partie délibérée de ce processus plutôt qu'un signe que le séquenceur est hors ligne.

Le chronométrage commence à partir de l'événement défini par le pont, qui ne coïncide pas nécessairement avec l'instant où l'utilisateur clique pour la première fois sur retirer. L'attente peut dépendre du moment où la sortie ou la revendication pertinente est disponible et si la preuve requise a été soumise. Un utilisateur peut passer du temps à attendre avant que la période de contestation qui apparaît dans une description de pont ne commence à compter.

Le compte à rebours d'un portefeuille peut donc décrire une estimation plutôt qu'une date de paiement inconditionnelle. Il peut dépendre de la poursuite de l'activité normale de publication et de preuve. Si l'état est contesté, le temps jusqu'à la finalité peut changer même si l'instruction de retrait elle-même apparaît déjà sur le rollup.

Le système de preuve d'Arbitrum et la conception de preuve de Base ont des détails de mise en œuvre différents. La comparaison pratique pour un utilisateur est de savoir qui peut soumettre une revendication, qui peut la contester, et ce qui se passe si l'acteur qui soumet normalement la revendication suivante s'arrête. Le même mot, retrait, couvre des séquences différentes à travers ces systèmes.

Le délai affecte également les comparaisons avec les ponts tiers. Un service qui peut payer l'utilisateur immédiatement sur Ethereum utilise sa propre liquidité ou un réseau distinct de participants. Le paiement rapide peut se terminer avant que le retrait officiel derrière lui ne soit éligible au règlement.

L'utilisateur dépend alors de la capacité et de la volonté du tiers d'effectuer le paiement. Si la liquidité est épuisée ou si le fournisseur cesse d'accepter des demandes, la vitesse annoncée pour les échanges courants peut ne plus s'appliquer. Les protections de sortie du rollup sous-jacent et les conditions de paiement du service commercial restent distinctes.

La question de la mise à niveau porte sur les règles qui s'appliqueront demain

Une défaillance du séquenceur empêche un utilisateur d'atteindre la route normale vers la chaîne. Une mise à niveau peut modifier les règles régissant la route elle-même. Cela rend le délai de mise à niveau pertinent même si le séquenceur est sain et que chaque transaction est acceptée.

Dans le cadre d'un processus de gouvernance ordinaire, une mise à niveau annoncée peut devoir passer par un délai avant de pouvoir prendre effet. Pendant cette période, les utilisateurs peuvent évaluer la proposition et commencer à partir si le pont reste ouvert. La fenêtre de sortie utile est ce qui reste après avoir tenu compte des étapes de retrait normales.

Dans le cadre d'une procédure d'urgence, des signataires désignés peuvent parfois agir sans le délai ordinaire. Cela peut aider à répondre rapidement à un incident de sécurité. Cela donne aussi aux utilisateurs une garantie différente de celle qu'ils voient lorsque la gouvernance emprunte sa voie ordinaire.

L'évaluation d'Arbitrum One indique dix jours pour la voie ordinaire et aucune fenêtre de sortie pour une mise à niveau d'urgence. L'évaluation de Base n'indique aucune fenêtre de sortie. La note de stade principale peut être la même alors que ces pouvoirs diffèrent en pratique.

Une pause est une autre action à distinguer d'une mise à niveau. Une pause peut arrêter une opération spécifique selon les règles contractuelles existantes. Une mise à niveau peut remplacer ou modifier ces règles. Le signataire et le seuil requis pour une pause peuvent différer du signataire et du seuil requis pour une nouvelle implémentation.

Crypto.news a couvert un exemple concret d'autorité d'urgence lorsque le Conseil de sécurité d'Arbitrum a déplacé des fonds liés au piratage de Binance. Ce cas concernait des fonds identifiés et une modification contractuelle temporaire. Sa pertinence ici réside dans le fait que l'autorité d'urgence peut être exercée en pratique et peut être distincte du processus ultérieur qui détermine où vont les fonds.

Comment lire le stade 1 sans le confondre avec une garantie de sortie

Les classifications par stade regroupent plusieurs dimensions d'un rollup. Elles indiquent dans quelle mesure un système s'est éloigné de sa dépendance aux opérateurs ou aux conseils selon les critères du cadre. Une étiquette de stade ne peut pas fournir la réponse pour chaque mode de défaillance, car chaque protection répond à une fonction différente.

Pour un utilisateur, les détails importants sont les conditions qui s'appliquent à sa transaction. Un mécanisme de repli du séquenceur importe si la transaction ne peut pas être incluse. La capacité de proposer un état importe si le proposeur habituel du rollup s'arrête. Un délai de mise à niveau importe si quelqu'un peut modifier ce que fera le pont pendant que l'utilisateur attend.

La disponibilité des données relève de la même comparaison. Si les données nécessaires pour reconstruire le rollup sont accessibles sur Ethereum, un autre participant dispose d'une base pour suivre la chaîne. L'existence des données ne réalise pas en soi une preuve ni ne soumet une transaction Ethereum au nom de l'utilisateur.

Base et Arbitrum One peuvent tous deux offrir une route via Ethereum pour un problème de séquenceur tout en conservant des permissions différentes en matière de mises à niveau. Une évaluation pratique enregistre les deux au lieu de les moyenner en un score unique. Un utilisateur qui tente de partir a besoin de l'étape pertinente la plus faible pour l'événement auquel il fait face.

Les hypothèses varient également selon le jeton. L'ETH natif peut suivre les propres règles du pont officiel. Un jeton arrivé via un contrat tiers peut ajouter des contrôles d'émetteur ou de pont. Deux portefeuilles sur le même rollup peuvent faire face à des conditions de rachat différentes même lorsque leurs interfaces affichent les deux soldes dans les mêmes termes en dollars.

L'incident du pont Ankr fournit un autre exemple de la manière dont la logique du pont peut déterminer si un retrait est valide. Il concernait un système différent. Sa pertinence réside dans la distinction entre l'activité sur une chaîne et les règles que le pont utilise pour accepter des messages et libérer des actifs.

Ce qu'une comparaison des sorties peut établir

Comparez deux utilisateurs qui initient des retraits ordinaires avant une panne du séquenceur. Si chaque retrait fait déjà partie de l'état disponible pour le pont sur Ethereum, les étapes restantes dépendent du processus de preuve et de finalisation. La panne peut avoir peu d'effet direct sur un retrait déjà arrivé à maturité si l'exécution sur Ethereum reste disponible.

Déplacez maintenant la panne plus tôt. Aucun des deux utilisateurs n'a de transaction de retrait incluse. Les deux doivent atteindre la route du rollup côté Ethereum ou attendre le service normal. Le temps jusqu'à l'inclusion peut différer, et l'attente propre au pont vient ensuite.

Enfin, imaginez une action contractuelle d'urgence pendant que les retraits sont en attente. Les preuves pertinentes deviennent l'autorité derrière l'action, les contrats exacts concernés et les étapes que la nouvelle configuration permet. Une transaction précédemment incluse peut encore nécessiter que le pont la reconnaisse selon les règles en vigueur au moment où l'utilisateur tente de la finaliser.

Ces cas montrent pourquoi une comparaison équitable commence par le même état. Un utilisateur qui a soumis un message à Ethereum mais n'a pas encore vu l'exécution du rollup ne devrait pas être comparé directement à quelqu'un dont la preuve de pont a déjà été acceptée. Les horloges démarrent à des événements différents.

Crypto.news a rapporté les efforts visant à faire fonctionner les rollups Ethereum ensemble. Une interface plus fluide peut masquer plusieurs étapes d'une transaction normale. En situation de stress, l'utilisateur bénéficie de savoir quelles parties de l'opération se déroulent sur quelle chaîne et qui est responsable de chaque partie.

La couverture par Crypto.news de la proposition de récupération Arbitrum liée à Binance montre également pourquoi une action de gouvernance doit être lue conjointement avec la transaction qu'elle autorise. Une proposition décrit le résultat escompté. Les registres Ethereum et du rollup montrent quand et où elle a été exécutée.

Une voie de sortie n'est utile que dans la mesure où un détenteur peut l'utiliser depuis sa position actuelle. Le registre le plus clair identifie l'actif, la chaîne sur laquelle il se trouve, la transaction déjà effectuée et la partie ou le contrat contrôlant l'étape suivante. Ce registre indique à l'utilisateur si l'attente restante appartient au séquenceur, au pont ou à une autorité capable de modifier l'un ou l'autre.

Pourquoi une preuve plus rapide ne raccourcit pas nécessairement chaque sortie

La mise à niveau Azul de Base a introduit de nouvelles options de preuve. Crypto.news a rapporté une voie potentielle vers des retraits en un jour. Une capacité cible ou de preuve doit être distinguée du délai de retrait sur lequel un utilisateur particulier peut compter sous la configuration active.

Une preuve peut aider à établir l'état dont dépend un retrait. Le pont peut encore appliquer d'autres conditions avant de libérer les fonds. La séquence peut également varier selon la voie de preuve utilisée par le réseau et ce qui se passe lorsque cette voie est indisponible.

Une comparaison des sorties devrait donc indiquer la voie qu'elle mesure. Une voie optimiste peut avoir une période de contestation. Une route utilisant une preuve différente peut raccourcir une partie du processus. Un risque de mise à niveau concerne la question de savoir si les contrats ou les permissions régissant l'une ou l'autre route peuvent changer avant qu'elle ne se termine.

Un retrait Ethereum nécessite également une transaction qui peut être soumise et exécutée sur Ethereum. Un site tiers peut proposer d'effectuer cette étape, mais sa capacité à accepter une demande est distincte de la question de savoir si le contrat officiel peut la traiter. Un utilisateur qui voit l'action devenir disponible a encore besoin d'un portefeuille ou d'un service capable de la soumettre.

La distinction devient importante si l'utilisateur détient des actifs pour le compte d'une application ou d'un client. Une trésorerie peut nécessiter plusieurs approbations avant toute action sur Ethereum. Un utilisateur ordinaire peut avoir besoin d'une connexion de portefeuille et de gaz. Le délai de sortie disponible du protocole et le temps dont la personne a besoin pour agir peuvent différer.

Ce que le registre public peut montrer après une panne

Un compte rendu d'incident peut commencer par la dernière réponse normale du séquenceur et la première transaction retardée. Il peut ensuite identifier si les données et l'état ont continué d'atteindre Ethereum. Les registres peuvent aider à expliquer pourquoi certains utilisateurs ont subi une interruption tandis que d'autres pouvaient encore finaliser des retraits antérieurs.

La chronologie la plus utile nomme également l'application et l'actif concernés. Un portefeuille signalant des soldes obsolètes est différent d'un pont refusant d'accepter une transaction de finalisation. Un fournisseur tiers suspendant un paiement est différent du pont officiel modifiant ses règles.

La couverture par Crypto.news d'une intervention d'urgence sur Arbitrum illustre la nécessité de séparer une action effectuée par un conseil du processus de gouvernance qui suit. L'existence d'un registre Ethereum peut établir qu'une action contractuelle a eu lieu. Cela n'élimine pas la nécessité de lire quelle autorité l'a effectuée et ce qu'elle a affecté.

La réponse directe à la question du retrait dépend du moment où la défaillance se produit. Avant l'inclusion, examinez le mécanisme de repli Ethereum et le délai qui y est attaché. Après l'inclusion, examinez les exigences d'état, de preuve et de finalisation. Lors d'un changement d'urgence, l'autorité de suspendre ou de modifier les contrats devient décisive même si les autres systèmes fonctionnent.

Un utilisateur peut également avoir plusieurs retraits à différents points de cette séquence. L'un peut être prêt à être finalisé tandis qu'un autre attend encore d'être inclus. Un avis de panne donnant un seul délai de rétablissement prévu ne peut pas régler le statut des deux.

Le reçu de retrait est la vérification finale

Une interface de bridge peut indiquer qu'un retrait est prêt avant que l'utilisateur n'ait soumis la transaction pour le finaliser. Le reçu de transaction Ethereum est un enregistrement distinct. Pour l'ETH natif, le destinataire peut également vérifier que le transfert a atteint l'adresse prévue et que le destinataire peut l'utiliser.

Cette distinction est importante lorsqu'un utilisateur réessaie une action après une panne. Deux tentatives de soumettre une instruction peuvent produire des messages différents ou une seule transaction acceptée, selon la manière dont les requêtes ont été effectuées. L'historique d'un portefeuille peut aider l'utilisateur à identifier quel message le bridge reconnaît avant de tenter l'étape suivante.

Un rollup et un bridge peuvent également se rétablir selon des calendriers différents. Le séquenceur peut reprendre alors que d'anciens retraits attendent encore un état ou une preuve. De nouvelles transactions de rollup qui réapparaissent constituent une preuve de rétablissement du service pour l'ordonnancement, mais les utilisateurs qui attendent de recevoir de l'ETH sur Ethereum doivent encore vérifier leur propre statut de finalisation.

Le même principe s'applique à un avis de mise à niveau. Une annonce peut indiquer qu'un bridge est en pause sans changer ce que le rollup continue de traiter. Les utilisateurs doivent déterminer si la pause affecte l'initiation, la preuve, la finalisation ou une autre opération. Un seul avis peut avoir une importance différente pour les détenteurs selon le stade où ils se trouvent dans le processus.

Pour les deux utilisateurs de la comparaison, la preuve finale est la même. Leurs retraits via le bridge officiel sont terminés lorsque Ethereum enregistre la libération de l'ETH au destinataire prévu. Tout ce qui précède leur indique quelle partie de l'itinéraire fonctionne et ce qui reste à faire.

Points à surveiller

• Statut du séquenceur : Un avis de statut et les enregistrements de transactions cumulés peuvent montrer quand l'ordonnancement normal s'est arrêté et a repris.
• Boîte de réception Ethereum : Un reçu Ethereum réussi peut établir que le message de repli a été soumis et quand il est devenu éligible à l'inclusion.
• Publication de l'état : Les enregistrements Ethereum peuvent montrer si le pont dispose de la réclamation ou de la sortie dont il a besoin pour traiter le retrait.
• Actions d'urgence : Les signataires autorisants, les contrats concernés et l'heure de la transaction déterminent si une pause ou une mise à niveau a modifié l'itinéraire de l'utilisateur.
• Adossement des actifs : L'émetteur du jeton et le pont déterminent si la comparaison officielle des retraits s'applique à ce solde.

FAQ