Rabby Wallet et la détection de token clone : Quand deux ERC-20 portent le même symbole sur deux chaînes différentes

Un utilisateur DeFi observe deux tokens affichant le même symbole « USDC » sur deux blockchains différentes. L’un circule sur Ethereum, l’autre sur Arbitrum. Tous deux apparaissent dans son portefeuille après un transfert, mais l’un pourrait être un clone malveillant ou un emballage mal configuré. La question n’est pas théorique : les tokens homonymes cross-chain créent une surface d’attaque réelle où l’interface du portefeuille, l’adresse du contrat, et la diligence de l’utilisateur doivent fonctionner ensemble pour éviter une confusion coûteuse.

Rabby Wallet, développé par DeBank et disponible sur 141+ blockchains EVM, offre des capacités de détection et de simulation de transactions qui atténuent ce risque. Mais aucun portefeuille non-dépositaire ne peut éliminer entièrement la confusion entre tokens homonymes : il peut seulement rendre la vérification plus visible et l’erreur plus difficile. Comprendre comment Rabby signale les anomalies, et comment un utilisateur peut valider manuellement un token avant transfert, constitue la différence entre une gestion d’actifs tranquille et une perte irréversible.

Les homonymes cross-chain : une confusion structurelle, pas une faille

L’existence de plusieurs tokens avec le même symbole est une conséquence directe de la manière dont les blockchains fonctionnent. Un token ERC-20 est défini par son adresse de contrat et par sa blockchain. Sur Ethereum, l’adresse officielle d’USDC est 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48. Sur Arbitrum, c’est 0xFF970A61A04b1cA14834A43f5dE4533eBDDB5F86. Deux entités différentes, même symbole, deux comportements en cas de transfert cross-chain.

Les portefeuilles comme Rabby Wallet doivent gérer automatiquement la détection de réseau, mais la responsabilité finale repose sur l’utilisateur. Lorsqu’un utilisateur voit « USDC » dans l’interface, il doit pouvoir consulter l’adresse sous-jacente, la blockchain active, et confirmer que la destination correspond à ce qu’il attend. Un clone ou un token enveloppé mal configuré aura une adresse différente et comportera différemment lors du transfert. Rabby by DeBank inclut des alertes de phishing et une détection proactive qui peuvent signaler certains contrats suspects, mais l’identification d’un véritable token haut de gamme dépend davantage de la vérification manuelle que d’une détection automatique.

Le risque est amplifié lors du transfert. Si un utilisateur initialise un pont cross-chain ou une passerelle d’échange sans vérifier l’adresse de destination, il peut envoyer des tokens vers un contrat d’enveloppe défectueux, vers un service qui ne supporte pas cette version du token, ou pire encore, vers un contrat conçu pour vol. Aucune simulation de transaction ne peut prédire si une adresse distante honora correctement le destinataire du token enveloppé.

Comment Rabby détecte les abus et les anomalies

La phishing detection intégrée à Rabby analyse les contrats de tokens et les adresses destinataires contre une base de contrats suspects connus. Cette détection fonctionne en deux directions : elle peut identifier un contrat qui prétend être USDC mais qui ne dispose pas des bonnes propriétés, ou elle peut avertir si une adresse de destinataire est associée à une arnaque connue. Cet avertissement apparaît avant que l’utilisateur signe la transaction, ce qui rend l’erreur plus visible.

La simulation de transactions constitue un deuxième rempart. Lorsqu’un utilisateur prépare un transfert d’USDC d’Ethereum vers Arbitrum via un pont, Rabby peut simuler l’exécution sans la soumettre au réseau. Cela permet de vérifier que le contrat réagit comme prévu, que l’adresse destinataire existe et est appropriée, et que les changements d’état prédits sont cohérents avec l’intention déclarée. Si le pont utilise un contrat d’emballage ou une logique de swap complexe, la simulation peut révéler une incohérence de prix, un slippage excessif, ou une adresse destinataire inattendue.

L’identification par adresse est la troisième couche. Rabby affiche l’adresse du contrat de chaque token en texte lisible. Un utilisateur chevronné comparera cette adresse avec une source fiable : le site officiel de Circle pour USDC, la liste vérifiée d’un agrégateur comme CoinGecko ou DeBank lui-même. Si l’adresse correspond au registre officiel, le token est authentique. Si elle diffère, il s’agit d’un clone, d’un enveloppe, ou d’une imposture. Rabby ne fait pas cette comparaison automatiquement ; elle rend seulement l’adresse accessible et visible.

Les alertes de revoke (révocation en masse d’approbations) constituent un quatrième outil de sécurité. Si un contrat a été compromis ou si un utilisateur a approuvé un contrat douteux, Rabby peut lister toutes les approbations actives et permettre à l’utilisateur d’annuler celles qui ne sont plus souhaitables. Cela n’empêche pas un transfert incorrect, mais cela réduit l’exposition à long terme si un token a été mal acheminé vers un contrat malveillant ou si un bridge a échoué.

Vérification manuelle : la procédure infaillible

Aucune automatisation ne remplace la vérification manuelle pour les transferts de valeur significative. La procédure est simple mais demande de la discipline. Avant d’approuver une transaction impliquant un token sur une chaîne peu familière, un utilisateur doit : premièrement, identifier l’adresse du contrat exact affiché par Rabby ; deuxièmement, comparer cette adresse avec la source officielle du token ; troisièmement, vérifier que la blockchain est correcte dans l’interface du portefeuille ; quatrièmement, simuler la transaction et lire les résultats attendus ; cinquièmement, approuver seulement si l’adresse, la blockchain, et le montant correspondent exactement à l’intention.

Les sources officielles varient selon le token. Pour USDC, c’est le site de Circle ou son documentation technique. Pour les tokens DEX comme Uniswap, c’est le contrat affiché sur Uniswap.org avec l’adresse correcte pour chaque chaîne. Pour les tokens propriétaires, c’est le site officiel du projet, jamais une annonce Twitter ou un message Discord (ces canaux sont fréquemment compromis). Si un utilisateur ne trouve pas une source officielle fiable, ou si les sources diffèrent sur l’adresse, il ne doit pas envoyer le token.

Une vérification secondaire utile consiste à envoyer un montant test d’abord. Certains contrats ERC-20 enveloppés ou des ponts défectueux refuseront un transfert test de quelques unités. Cela détecte une incompatibilité avant la perte d’une quantité importante. Une fois le transfert test confirmé à la destination et bridé ou échangé avec succès, le reste peut suivre. Cette approche n’est pas raisonnable pour des transactions fréquentes en trading, mais elle l’est pour des entrées ou sorties de fonds importants.

Rabby Wallet facilite cette vérification en affichant l’adresse du contrat de manière évidente et en permettant la copie rapide pour comparaison. Sur les blockchains EVM supportées par Rabby, l’utilisateur peut aussi consulter le contrat sur un explorateur de blocs (Etherscan, Arbiscan, etc.) pour vérifier la source du code, les événements de transfert, et l’historique des interactions. Un token authentique aura un code source vérifiable et une activité compatible avec son utilisation déclarée.

Quand un token apparaît deux fois dans le portefeuille

Un scénario courant dans les portefeuilles multi-chaînes : un utilisateur voit « USDC » sur Ethereum et « USDC » sur Optimism, mais il n’a transféré que sur Ethereum. Comment l’autre a-t-il atterri sur Optimism ? Les réponses sont : transfert manuel oublié, airdrop, transfert automatique d’un service d’échange, ou contrat clone détecté par Rabby mais pas gelé dans l’affichage.

Rabby regroupe les tokens par symbole mais les différencie par adresse de contrat dans les détails. Cliquer sur chaque instance révèle l’adresse exacte et la blockchain. Si deux USDC ont des adresses différentes, l’un au moins n’est probablement pas le véritable USDC officiel. Certains portefeuilles affichent les tokens enveloppés (« USDC.e » ou « USDC Bridged ») avec un symbole distinct ; Rabby en mentionne l’existence mais peut les grouper sous le symbole principal. Cette ambiguïté est une limitation de la conception du portefeuille, pas une faille de sécurité.

Un utilisateur devrait donc examiner l’adresse de chaque instance USDC avant de supposer que c’est la même entité. Si l’une est l’adresse officielle (par exemple, 0xFF970A61A04b1cA14834A43f5dE4533eBDDB5F86 sur Arbitrum) et l’autre une adresse inconnue, il doit ignorer ou supprimer la seconde. Rabby permet la suppression de tokens non désirés du portefeuille sans affecter les fonds réels ; cela améliore la clarté sans détruire les actifs.

La chaîne des responsabilités : portefeuille, bridge, et destination

Lorsqu’un utilisateur transfère un token d’une chaîne à une autre, trois entités sont impliquées. D’abord, le portefeuille (Rabby en l’occurrence) qui signe la transaction. Ensuite, le bridge ou le service de transfert cross-chain qui reçoit le token sur la chaîne d’origine et le délivre (ou le remplace par un équivalent enveloppé) sur la chaîne de destination. Enfin, le contrat ou le service destinataire qui reçoit ou accepte le token sur la chaîne de destination.

Rabby contrôle le premier point : il peut vérifier l’adresse du contrat et avertir de phishing avant signature. Le bridge (Stargate, Across, Connext, etc.) repose sur sa propre sécurité et configuration. Le service de destination dépend de l’utilisateur qui vérifie l’adresse avant approbation. Si le bridge effectue une erreur ou si l’adresse de destination est mal saisie, Rabby ne peut pas le corriger après transmission. C’est pourquoi l’instruction « Rabby offre une protection » doit être comprise comme « Rabby rend la vérification plus visible », et non « Rabby garantit la sécurité ».

Les portefeuilles multi-chaînes comme Rabby réduisent la friction entre chaînes, ce qui est utile. Mais cette réduction de friction crée un risque : une erreur facile devient plus facile à commettre. C’est pourquoi des mesures comme la simulation de transactions et la détection de phishing ne sont pas optionnelles ; elles compensent la rapidité de l’interface. Un utilisateur qui envoie sans vérifier l’adresse destinataire, même si Rabby n’avertit pas, supporte la responsabilité complète de toute perte.

Bonnes pratiques pour les portefeuilles multi-blockchain

La première pratique est de ne pas transférer automatiquement. Chaque chaîne a son propre réseau, ses propres frais, et sa propre dynamique de token. Un utilisateur qui duplique son portefeuille sur cinq chaînes crée cinq cibles potentielles pour les arnaqueurs. Sur chaque chaîne, des clones et des jetons enveloppés attendent. La meilleure approche consiste à utiliser activement seulement les chaînes où les fonds sont nécessaires et à transférer intentionnellement, en vérifiant chaque fois.

La deuxième pratique consiste à conserver une distinction mentale claire entre les versions d’un token. USDC sur Ethereum n’est pas identique à USDC.e (enveloppé) sur Optimism ou à USDC Bridged sur Arbitrum, même s’ils ont tous le même symbole. Chacune a son adresse de contrat, son bridge d’origine, et ses conditions de conversion. Lorsqu’un échange ou un service demande « quelle version de USDC », l’utilisateur doit répondre par l’adresse exacte, pas simplement le symbole.

La troisième pratique est de tester les ponts et les destinations peu familiers avec un montant petit d’abord. Si un utilisateur n’a jamais utilisé Stargate ou un bridge spécifique, un test d’une valeur nominale (par exemple, 10 USDC) permet de vérifier que la destination reçoit correctement, que la conversion de prix est honnête, et que le service supporte bien le token enveloppé attendu. Une fois confirmé, le reste peut suivre sans risque de surprise.

La quatrième pratique concerne la sauvegarde et la récupération. Rabby, en tant que portefeuille non-dépositaire, conserve les clés privées sur l’appareil et chiffre les sauvegardes. Une phrase de récupération doit être stockée hors ligne et testée en cas de changement d’appareil. Si un utilisateur perd accès à Rabby sans sauvegarde, il perd l’accès aux fonds sur toutes les chaînes. Cette dépendance vis-à-vis d’une seule phrase justifie de la stocker avec autant de soin que les clés elles-mêmes.

Quand la détection de phishing ne suffit pas

Les alertes de phishing de Rabby fonctionnent sur la base de contrats et d’adresses connus comme malveillants. Mais un contrat neuf, authentiquement enregistré sur une blockchain, et qui ne fait que copier un token légitime, n’apparaîtra pas immédiatement dans la liste noire. Un attaquant astucieux peut créer un contrat ERC-20 valide avec le symbole « USDC », ajouter une légère variante au nom (par exemple, « USD Circle »), et le diffuser via un lien de swap trompeur. Rabby détectera l’adresse du contrat comme inconnue, mais ne signalera peut-être pas un « clonage de phishing » si le contrat ne correspond pas exactement à un modèle suspect préexistant.

C’est un cas où l’interface du portefeuille atteint ses limites. Aucun portefeuille ne peut inventer automatiquement la vérité sur l’identité d’un token avant sa vérification auprès d’une source autorisée. La détection de phishing gagne en efficacité à mesure que l’écosystème signale les contrats suspects et que les fournisseurs mettent à jour leurs listes. Mais elle reste réactive, pas prophétique.

La couche ultime de protection est donc la connaissance de l’utilisateur. Quelqu’un qui comprend que chaque token a une adresse de contrat unique, que cette adresse peut être vérifiée, et que cette vérification prend quelques secondes sera nettement plus difficile à tromper. Rabby facilite cette vérification en affichant l’adresse et en permettant de consulter le contrat sur un explorateur. Mais le portefeuille ne peut pas forcer l’utilisateur à vérifier, et il ne peut pas éliminer les cas où un utilisateur ne prend pas le temps de le faire.

L’avenir de la détection cross-chain et les standards en développement

L’industrie reconnaît progressivement le problème des homonymes cross-chain. Des efforts comme Token Lists, chain-agnostic registries, et des approches de « token sovereignty » tentent de créer des sources de référence permanentes pour les tokens authentiques. Si ces standards gagnent en adoption, Rabby et d’autres portefeuilles pourraient importer directement ces registres et afficher des indicateurs de confiance plus détaillés (par exemple, « token officiel de Circle » ou « version enveloppée de Stargate »).

Les hardware wallets comme Ledger intègrent également des éléments de ce travail. Lorsqu’un utilisateur approuve une transaction sur un Ledger via Rabby, le dispositif peut afficher des informations plus riches sur le contrat et ses symboles. Cela rend l’approbation consciente du symbole plus facile, puisque l’écran du hardware wallet peut montrer à la fois le symbole et une indication de confiance basée sur des listes de tokens vérifiées.

Pour l’instant, la responsabilité reste partagée entre la technologie et l’utilisateur. Rabby fournit la visibilité et les avertissements. L’utilisateur effectue la vérification finale. C’est une répartition saine du risque : elle n’existe que parce que les portefeuilles ne devraient pas être détenteurs, et qu’une détention non-dépositaire exige une participation consciente à la gestion des risques.