---
title: "Tokens canoniques, natifs et wrapped"
description: "Guide fondé sur la vérification de l'identité des tokens, des actifs natifs de l'émetteur, des représentations désignées par un protocole, des wrappers sur une même chaîne, de la couverture, du rachat et de la 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.
# Tokens canoniques, natifs et wrapped
> À 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
Canonique et wrapped ne sont pas des catégories de tokens opposées. Canonique décrit le mapping ou l'itinéraire désigné par un écosystème donné ; wrapped décrit un mécanisme de représentation. Un bridge token désigné par un protocole peut lui-même être wrapped, tandis que WETH est un wrapper sur la même chaîne et que l'USDC natif de l'émetteur sur une chaîne compatible peut utiliser un mécanisme de burn-and-mint contrôlé par l'émetteur plutôt qu'un séquestre de bridge.
Commencez par l'identité, non par le symbole : `chainId`, marqueur d'actif natif ou contrat du token, implémentation du proxy et bloc. Déterminez ensuite qui l'émet ou le désigne, quel actif ou passif le couvre, qui peut le mint, le burn, le mettre en pause ou le mettre à niveau et si un détenteur éligible peut réellement effectuer un unwrap, un rachat, un bridging ou une vente. Solvabilité, disponibilité du rachat et liquidité de marché sont trois questions distinctes.
## Fonctionnement
1. Fixez l'instantané : chaîne, `chainId`, marqueur natif ou adresse du token, bloc et heure, décimales, implémentation du proxy ou `codeHash` et version de la documentation de l'émetteur ou du protocole. Nom, symbole, logo ou token list du wallet ne constituent pas une identité.
2. Classez selon deux axes. Le statut peut être natif de la chaîne, natif de l'émetteur, désigné par le protocole ou tiers. Le mécanisme peut être un wrapper sur la même chaîne, une créance sur un bridge lock-and-mint, un transfert burn-and-mint, un wrapper conservé par un dépositaire, une part de vault ou un reçu de réseau de liquidité. Un token peut relever de plusieurs qualifications.
3. Retracez précisément la provenance et le graphe des pouvoirs : actif d'origine, contrepartie distante enregistrée, contrat de séquestre ou de burn, messager ou attesteur, minter de destination, administrateur du proxy, rôles de mint et burn, pouvoirs de pause ou denylist, timelock, limites et plan de migration.
4. Reconstituez les livres de couverture et de passif en unités brutes et affichées. Pour le lock-and-mint, rapprochez le séquestre éligible pour la paire de l'offre de la représentation et des créances en transit. Pour le burn-and-mint de l'émetteur, rapprochez les offres par chaîne et le passif de l'émetteur ; n'inventez pas un séquestre de bridge inexistant.
5. Vérifiez le cycle de rachat exécutable : éligibilité, direction, approvals, unwrap ou burn, preuve ou attestation, finalisation ou claim, gas sur chaque chaîne, frais, limites, pauses et récupération après échec. Un test limité ne prouve que cet itinéraire et cet instantané.
6. Comparez les sorties. Consignez séparément le bid DEX exécutable et la profondeur, le slippage, les frais de protocole et de LP, le gas, le délai et l'acceptation par un dépositaire ou un exchange, sans les confondre avec la couverture. Un token couvert peut coter sous le pair et un prix liquide ne prouve pas la couverture.
7. Rapprochez reçus, événements, soldes, offre, séquestre, créances en attente et allowances restantes. Séparez les soldes natifs, wrapped, bridged et natifs de l'émetteur ; surveillez implémentation, rôles, mapping, migration, pauses, publications sur les réserves et liquidité ; dimensionnez l'exposition selon la pire sortie exécutable crédible.
## Exemples détaillés
- **La couverture doit inclure les créances en attente.** Le séquestre éligible pour la paire vaut `2,500.000000 units`, l'offre émise à destination `2,400.000000 units` et les créances verrouillées mais pas encore émises `100.000000 units`. Les passifs économiques sont `2,400 + 100 = 2,500` ; la couverture ajustée est donc `2,500 / 2,500 = 100%`. Ignorer les créances en attente donne `2,500 / 2,400 = 104.1666666667%`, un excédent trompeur. Même une couverture correcte ne prouve ni la sécurité du contrat ni la liquidité immédiate.
- **Un même symbole peut représenter des créances différentes.** Un détenteur possède `2,500 units` de chacun de deux contrats. Le contrat natif de l'émetteur affiche un bid exécutable de `$0.998`, soit `2,500 * 0.998 = $2,495` ; le contrat d'un bridge tiers affiche un bid de `$0.920`, soit `2,500 * 0.920 = $2,300`. L'écart est de `$195` malgré un nom et des décimales identiques.
- **Wrapped n'implique pas un transfert inter-chaînes.** Un wallet commence avec `5.000 ETH`, dépose `3.000 ETH` dans un contrat WETH sur la même chaîne et paie `0.002 ETH` de gas. Il termine avec `1.998 ETH` et `3.000 WETH` ; le ratio réserve/offre du wrapper est `3 / 3 = 100%` ; l'exposition économique est `1.998 + 3.000 = 4.998 ETH` avant risque du contrat. Ajouter encore la réserve reviendrait à la compter deux fois.
- **La sortie de marché diffère du rachat différé.** Pour `10,000 tokens`, le bid DEX est `$0.985`, l'impact de prix `0.60%`, les frais LP ou de protocole `0.10%` et le gas `$12`. Dans cet ordre, le produit net est `10,000 * 0.985 * (1 - 0.006 - 0.001) - 12 = $9,769.05`. Un rachat éligible restitue `$9,987` après frais dans `7 days` ; à un taux d'opportunité annuel simple de `8%`, la valeur actuelle est `9,987 / (1 + 0.08 * 7 / 365) = $9,971.7009519641`, soit `$202.6509519641` de plus. Il ne s'agit pas d'un arbitrage garanti et le calcul omet les risques de défaut, finalité, fiscalité et prix.
## Risques
- Utiliser une chaîne, un marqueur natif ou un contrat de token incorrect.
- Se fier à un symbole, nom, icône ou token list falsifiés.
- Mal interpréter les décimales, unités brutes, offres ou soldes.
- Omettre l'implémentation du proxy, son administrateur ou une mise à niveau du code.
- Accepter un registre, une paire, un router ou un mapping de gateway obsolète.
- Perdre le contrôle après compromission d'un rôle d'émetteur, mint, burn ou attestation.
- Traiter des réserves mélangées, nanties ou grevées comme une couverture éligible.
- Compter deux fois séquestre, offre représentative et créances en attente.
- Omettre dépôts, burns, retraits, frais ou messages en transit.
- Supposer une comptabilité standard pour des tokens fee-on-transfer, rebasing ou avec hooks.
- Subir un gel de l'émetteur, une pause du bridge, une denylist, une limite ou une censure.
- Accorder une allowance excessive ou approuver le mauvais spender du bridge.
- Confondre finalité source, validité du message et exécution à destination.
- Dépendre de relayers, séquenceurs, provers, attesteurs ou données indisponibles.
- Subir replay, double mint, burn défaillant, reorg source ou défaut comptable.
- Découvrir que le détenteur n'a pas accès au rachat direct.
- Subir fragmentation de liquidité, depeg, slippage, MEV ou profondeur insuffisante.
- Omettre gas, frais, délai, coût d'opportunité ou acceptation du dépositaire.
- Rester bloqué dans un contrat obsolète ou une migration inachevée.
- Cumuler des risques corrélés de chaîne, bridge, émetteur, oracle, UI, RPC, fiscalité, sanctions et conservation.
## Idées reçues
- Canonique signifie toujours natif de l'émetteur, officiel, trustless et sûr.
- Wrapped signifie toujours que le token a changé de chaîne.
- Des tokens ayant le même symbole et les mêmes décimales sont des créances fongibles.
- Une qualification un-pour-un, un solde de contrat ou un chiffre d'offre prouvent la possibilité de rachat.
- La couverture par les réserves garantit une valeur monétaire immédiate un-pour-un sur tout marché et tout compte.
## Sujets connexes
- [Bridge canonique](/fr/crypto/canonical-bridge/)
- [Vérification des bridge tokens](/fr/crypto/bridge-token-verification/)
- [Wrapped token](/fr/crypto/wrapped-token/)
## Sources
- [Bridges](https://ethereum.org/developers/docs/bridges/) - Ethereum.org (consulté : 2026-08-12)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consulté : 2026-08-12)
- [WETH9.sol](https://github.com/gnosis/canonical-weth/blob/master/contracts/WETH9.sol) - Gnosis (consulté : 2026-08-12)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (consulté : 2026-08-12)
- [Bridged token addresses](https://docs.optimism.io/app-developers/reference/tokens/tokenlist) - Optimism Documentation (consulté : 2026-08-12)
- [USDC contract addresses](https://developers.circle.com/stablecoins/usdc-contract-addresses) - Circle Docs (consulté : 2026-08-12)
- [Cross-Chain Transfer Protocol](https://developers.circle.com/cctp) - Circle Docs (consulté : 2026-08-12)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consulté : 2026-08-12)
Source: https://wiki.fcontext.com/fr/crypto/canonical-vs-wrapped-token/index.mdx