---
title: "Comment vérifier un jeton reçu après un bridge"
description: "Un jeton bridgé doit être vérifié par son réseau et son contrat, la filiation de son émetteur ou bridge, son modèle d'émission et de couverture, ses autorités, sa comptabilité en transit, ses conditions de rachat et sa valeur de sortie exécutable."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Comment vérifier un jeton reçu après un bridge
> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
## Réponse directe
Un jeton reçu après un bridge n'est pas authentifié par son nom, son symbole, son icône, son prix affiché ou un événement `Transfer`. L'identité commence par le réseau ou domaine de destination et le contrat du jeton ou l'indicateur d'actif natif ; elle comprend ensuite l'implémentation actuelle du proxy ou le beacon, l'émetteur ou le bridge, la route et sa version déployée, l'actif d'origine et l'instantané de bloc.
Il faut ensuite classifier la créance. Il peut s'agir d'une offre native de l'émetteur, d'une représentation désignée par un bridge de protocole, d'un jeton enveloppé par un tiers, d'un reçu de liquidité ou d'intention, ou d'une contrefaçon. Ces catégories correspondent à des émetteurs, actifs, droits de rachat et modes de défaillance différents. Une représentation d'un bridge canonique n'est pas nécessairement native de l'émetteur, et la liste de contrats d'un émetteur ne prouve ni les réserves ni la liquidité d'un bridge tiers.
La vérification exige donc quatre registres : identité et autorités ; réserves et créances en circulation ; messages de bridge en transit ; rachat exécutable ou sortie de marché. Un solde de portefeuille peut être un état contractuel réel tout en représentant le mauvais actif, une créance sous-couverte, un jeton gelé ou une position invendable au prix affiché.
## Fonctionnement
Les symboles, noms et décimales sont des métadonnées ERC-20, pas une authentification de l'émetteur. Une contrefaçon peut les copier, émettre des événements ordinaires, publier un code source vérifié et alimenter une pool de liquidité. La vérification du source relie seulement le code affiché au bytecode d'une adresse. Avec un proxy, les utilisateurs interagissent avec le proxy et y détiennent leurs soldes, tandis que l'implémentation ou le beacon fournit la logique ; l'administrateur et la voie de mise à niveau sont des faits distincts.
Il faut classifier le modèle comptable avant de calculer la couverture. Une route lock-and-mint doit rapprocher l'escrow source éligible de toutes les représentations qu'il garantit et des créances valides en transit. Une route burn-and-mint de l'émetteur transfère l'offre entre domaines et peut ne pas conserver d'escrow propre à chaque route. Un bridge de liquidité avance des stocks ou crée une créance de solver ou de LP ; sa pool n'est pas automatiquement une réserve du jeton. Les réserves partagées ne doivent être comptées qu'une fois pour l'ensemble des réseaux et versions pris en charge.
Pour un périmètre lock-and-mint défini, un diagnostic utile est `coverage = eligible reserves / supported outstanding claims`. Les réserves éligibles doivent être constituées du bon actif, contrôlées par la voie de garde promise, non grevées et non réutilisées comme garantie. Les créances peuvent comprendre l'offre en circulation sur plusieurs réseaux ou versions ainsi que les verrous finalisés mais pas encore émis, moins les destructions déjà reflétées dans l'offre. Un ratio supérieur à un ne prouve ni l'exactitude du code, ni l'honnêteté des administrateurs, ni la finalité source, ni l'accès actuel au rachat, ni la profondeur de marché.
Les autorités modifient la nature de la créance. Il faut examiner les rôles d'émission et de destruction, les correspondances enregistrées des jetons distants, les validateurs ou attestateurs du bridge, l'administrateur du proxy, l'implémentation, le timelock, les plafonds, la pause, le gel, la denylist et les pouvoirs de migration d'urgence. Le comportement du jeton compte aussi : décimales, frais sur transfert, rebase, hooks ou callbacks, valeurs de retour non standard et logique évolutive peuvent faire différer les montants demandés de ceux effectivement placés en escrow ou reçus à destination.
Le rachat et la vente sont deux sorties distinctes. Un rachat direct auprès de l'émetteur ou du bridge peut exiger un compte éligible, une direction prise en charge, un montant minimal ou maximal, une file d'attente, une preuve ou attestation, la finalité, du gas natif, des frais et des contrats non suspendus. Une sortie sur DEX exige une route exécutable pour la taille concernée, ses frais, sa profondeur, son impact de prix, un montant minimal reçu et l'horodatage de l'état. Une petite cotation proche d'un dollar ne prouve ni la couverture ni la valeur de sortie d'une position importante.
Une migration peut séparer identité et liquidité. Une ancienne représentation peut continuer de se négocier après qu'un remplacement devient privilégié, tandis que la conversion peut être plafonnée, unidirectionnelle, retardée ou fermée. Il faut vérifier la correspondance officielle entre ancien et nouveau jeton, le ratio de conversion, l'échéance et l'état actuel du rachat ; ne jamais échanger uniquement parce qu'un message d'assistance ou un symbole indique une mise à niveau.
Suivez ce processus :
1. Fixez le réseau ou domaine, le proxy du jeton ou l'indicateur natif, l'implémentation ou le beacon, l'administrateur, les décimales, le bloc et l'heure, l'émetteur ou le bridge, la route et sa version, ainsi que l'actif d'origine.
2. Recoupez les registres de l'émetteur et du bridge dans les deux sens ; vérifiez la correspondance du jeton distant, l'état du déploiement, l'avis de remplacement ou d'abandon et si le détenteur dispose de droits natifs de l'émetteur ou uniquement du bridge.
3. Classez le mécanisme : burn-and-mint de l'émetteur, lock-and-mint, réserve partagée, wrapper tiers, reçu de liquidité ou d'intention, ou autre modèle documenté.
4. Reconstituez en unités brutes les réserves, l'offre de chaque réseau et version pris en charge, les créances finalisées en transit, les destructions ou libérations en attente et les frais ; définissez les actifs éligibles et évitez de compter plusieurs fois une réserve partagée.
5. Examinez les pouvoirs d'émission, destruction, pause, gel, denylist, plafond, validation ou attestation, administration du proxy, implémentation et mise à niveau, ainsi que les transferts, rebases et hooks du jeton.
6. Testez la voie de rachat réellement accessible au détenteur et une sortie de marché dimensionnée : éligibilité, limites, file, preuve, finalité, gas, frais, route, profondeur, minimum reçu et jeton ou espèces effectivement obtenus.
7. Rapprochez le reçu source, la variation réelle de l'escrow ou la destruction, l'état du message, le reçu de destination, le solde exact du jeton, l'offre, les frais et la sortie nette ; surveillez mises à niveau et migrations, et arrêtez-vous devant toute divergence inexpliquée.
## Exemples
- **Les métadonnées ne déterminent ni les unités ni l'identité.** Le même montant brut `123,456,789` s'affiche comme `123.456789` pour un contrat avec `6 decimals`, mais comme `0.000000000123456789` avec `18 decimals`, soit un écart d'échelle de `10^12`. Un même symbole ne rend pas ces contrats ou créances identiques.
- **Des frais sur transfert peuvent créer immédiatement un déficit.** Un utilisateur demande le verrouillage de `1,000-token`. Des frais de transfert de `1%` retirent `10`, si bien que l'escrow reçoit `990` ; le bridge prélève ensuite des frais distincts de `2-token`. L'émission correcte à destination est `1,000 - 10 - 2 = 988`. Émettre `998` face à `990` de réserves éligibles crée immédiatement un déficit de `8-token`.
- **Une réserve partagée impose un dénominateur système.** L'escrow éligible vaut `12.0 million` ; l'offre en circulation sur le réseau B est `10.5 million`, celle du réseau C `0.4 million`, et une créance finalisée d'émission en transit vaut `0.6 million`. Les créances prises en charge totalisent `10.5 + 0.4 + 0.6 = 11.5 million` ; la couverture est donc `12 / 11.5 = 1.0434782609`, soit `104.34782609%`. Ne retenir que le réseau B donne `12 / 10.5 = 1.1428571429` et surestime la couverture.
- **La capacité de rachat diffère de la valeur sur DEX.** Un détenteur possède `100,000 tokens`. La voie officielle ne peut racheter immédiatement que `60,000` avec des frais de `0.20%`, ce qui verse `60,000 * (1 - 0.002) = 59,880` unités sous-jacentes et laisse `40,000` en attente. Une route DEX vend la totalité à un prix exécutable de `0.972` avant des frais de `0.30%` : le brut est `97,200`, les frais `291.60` et le net `96,908.40`, hors gas et MEV. Une icône ou petite cotation à `$1` ne prouve aucun de ces résultats.
## Risques
- Confondre la même adresse sur un autre réseau ou domaine avec l'actif recherché.
- Un symbole, un nom ou une icône copiés masquent un contrat différent.
- Le proxy est confondu avec son implémentation ou son beacon.
- Un code source vérifié est pris pour une approbation de l'émetteur.
- L'implémentation, l'administrateur ou l'historique des mises à niveau ne sont pas contrôlés.
- Une ancienne version du bridge ou du jeton reste utilisée.
- Une contrefaçon émet des événements normaux et crée une liquidité artificielle.
- Un wrapper tiers ou reçu de LP est pris pour une offre native de l'émetteur.
- Le mauvais modèle de verrouillage, destruction, émission, réserve partagée ou liquidité est appliqué.
- Les réserves éligibles comprennent des actifs gelés, empruntés, grevés ou non conformes.
- La même réserve est comptée une fois pour chaque réseau pris en charge.
- Les créances d'autres réseaux, anciennes versions ou en transit sont omises.
- Les destructions, émissions et instantanés d'offre en attente utilisent des heures incompatibles.
- Une autorité d'émission, destruction, attestation, validation ou mise à niveau est compromise.
- La pause, le gel, la denylist ou les limites de débit bloquent le transfert ou la sortie.
- Les décimales, unités brutes, frais sur transfert, rebases ou hooks faussent la comptabilité.
- Une réorganisation source ou une finalité insuffisante invalide la preuve de couverture.
- L'éligibilité au rachat, son plafond, sa file, son échéance, sa finalité ou ses frais sont ignorés.
- La profondeur du DEX, la dérive d'état, le slippage, le MEV ou les frais rendent la cotation inexécutable.
- Migration, remplacement, remboursement et reçus finaux sont mal rapprochés ou détournés par phishing.
## Idées reçues
- **Le même nom et la même icône désignent le même actif.** L'identité commence par le réseau ou domaine et par le contrat exact ou l'indicateur natif.
- **Les jetons d'un bridge officiel ou canonique sont toujours natifs de l'émetteur.** La désignation du bridge et les droits d'émission ou de rachat de l'émetteur sont distincts.
- **Une couverture proche ou supérieure à un prouve la sécurité et un rachat immédiat.** Elle ne renseigne pas à elle seule sur le code, les autorités, la finalité, la liquidité ou l'éligibilité du détenteur.
- **Le label vérifié d'un explorateur prouve que le jeton est approuvé et immuable.** Il ne vérifie ni les affirmations de l'émetteur, ni les réserves, ni l'administration du proxy, ni les futures mises à niveau.
- **Un prix DEX affiché à un dollar signifie qu'une grande position peut sortir à un dollar.** Le produit réel dépend du sens, de la taille, de la route, de la profondeur, des frais, du gas, du MEV et du moment.
## Sujets connexes
- [Jetons canoniques, natifs et enveloppés](/fr/crypto/canonical-vs-wrapped-token/)
- [Bridge canonique](/fr/crypto/canonical-bridge/)
- [Bridge inter-chaînes](/fr/crypto/cross-chain-bridge/)
## Sources
- [USDC contract addresses](https://developers.circle.com/stablecoins/usdc-contract-addresses) - Circle Developers (consulté le : 2026-08-13)
- [CCTP technical guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (consulté le : 2026-08-13)
- [Routes](https://docs.wormhole.com/products/connect/concepts/routes/) - Wormhole Docs (consulté le : 2026-08-13)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (consulté le : 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consulté le : 2026-08-13)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consulté le : 2026-08-13)
- [USDC Terms](https://www.circle.com/legal/usdc-terms) - Circle (consulté le : 2026-08-13)
- [Uniswap v3 Core](https://uniswap.org/whitepaper-v3.pdf) - Uniswap (consulté le : 2026-08-13)
Source: https://wiki.fcontext.com/fr/crypto/bridge-token-verification/index.mdx