Idée clé : pourquoi « $1 » sur différents réseaux n’a pas la même qualité de “monnaie”
Vous apprendrez à distinguer rapidement un stablecoin native d’une « enveloppe » bridged, et à vérifier trois points :
de quel token il s’agit, où se trouve la garantie, et s’il existe des restrictions / goulets d’étranglement pour convertir en
Les stablecoins soutiennent les règlements en DeFi et sur les exchanges, mais dans un monde multichaîne, un ticker identique ne garantit pas une fiabilité identique.
À l’écran, cela ressemble à
Objectif : expliquer la mécanique des stablecoins native et bridged, montrer les points de défaillance typiques des bridges et donner un repère pratique : où vérifier la garantie, les limites de volume / les statuts de retrait, et les signaux précoces de dégradation du “chemin de sortie” (discount, hausse des délais / files d’attente).
Termes dans le contexte de l’article : deux définitions qui reviendront constamment.
Stablecoin native : le token est émis par l’émetteur lui-même sur ce réseau ; c’est lui qui fixe les règles d’émission et de rachat. Dans l’écosystème, c’est généralement la version « canonique » sur laquelle s’alignent les protocoles et les exchanges.
Stablecoin bridged : un token créé par un bridge comme « enveloppe » ; la garantie se trouve le plus souvent sur un autre réseau (généralement sous forme de coins originaux verrouillés), et la possibilité de rachat dépend du fonctionnement du bridge, de ses limites et de la liquidité disponible.
Avant de transférer : 3 vérifications en une minute
— Adresse du contrat → ouvrez le token dans l’explorateur et comparez le contrat pour ne pas confondre des versions au ticker similaire.
— Origine → identifiez qui a émis le token sur ce réseau — l’émetteur ou un bridge (docs de l’émetteur/du bridge et marquage dans l’écosystème).
— Chemin de retour → vérifiez s’il existe un itinéraire réel vers le réseau « principal » ou vers un exchange liquide, sans pause, limites strictes ni goulots d’étranglement.
Native vs Bridged : ce qui change vraiment dans vos actions
La différence n’est pas dans le nom, mais dans la mécanique de sortie : qui émet le token et comment fonctionne le rachat (redemption chez l’émetteur / burn → release via le bridge), où se trouve la garantie, et si vous avez un accès rapide à un marché liquide (CEX / réseau « canonique ») sans pauses ni limites.
Un stablecoin native est émis par l’émetteur sur ce réseau ; le “chemin vers la liquidité” est donc généralement plus simple : les dépôts/retraits sur les exchanges sont plus souvent disponibles, il y a davantage d’intégrations dans les wallets et la DeFi, et la dépendance clé concerne les règles de l’émetteur et l’accessibilité du rachat, ainsi que la stabilité du réseau lui-même.
Un stablecoin bridged est un token distinct sur le réseau cible, qui existe grâce à un bridge. Vous détenez une enveloppe, proche de $1 tant que trois conditions sont réunies : la garantie est réellement verrouillée, le bridge peut exécuter la conversion inverse, et il existe de la liquidité sur le marché (pools DEX / carnets) pour sortir sans discount.
- Verrouillage → le token canonique (native) est immobilisé sur le réseau source (contrat du bridge ou dépositaire).
- Émission → sur le réseau cible, une version bridgée est frappée pour un montant équivalent.
- Retour → la version bridgée est brûlée, et l’original est déverrouillé — s’il n’y a pas de pause, limites ni files d’attente.
| Paramètre | Native | Bridged |
|---|---|---|
| Qui émet | Émetteur (Circle, Tether, etc.) |
Bridge / protocole (infrastructure tierce) |
| Où est la garantie | Chez l’émetteur (réserves et règles de rachat) |
Sur le réseau source (garantie dans un contrat / dépositaire) |
| Risque principal | Décisions de l’émetteur (compliance, disponibilité du rachat) |
Défaillance du bridge (code, clés, validateurs, pause) |
| Ce qui casse en premier | Disponibilité des opérations pour certaines adresses |
Conversion et liquidité (discount, files d’attente, arrêt) |
| Conclusion pratique | Adapté au stockage et aux gros règlements |
Plutôt pour le transit et des tâches DeFi courtes |
Mini-règle : pour le stockage et les gros règlements, on privilégie souvent le native. Pour un “aller-retour” ponctuel dans un autre réseau pour une opération précise, le bridged est acceptable — mais seulement si vous comprenez le chemin de retour et les limites.
Architectures de bridges : où se cachent les risques dans le “transfert” entre réseaux
Examinons 4 schémas populaires de bridges et voyons à quel endroit “$1 = $1” se casse : dans les règles mint/burn, dans la profondeur de liquidité des pools, dans les droits admin (pause/upgrade) et dans la confirmation des messages.
🔒 Lock/Mint — un “reçu” sur une garantie dans un autre réseau
Le modèle le plus courant : l’actif ne “voyage” pas vers un autre réseau — une enveloppe apparaît sur le réseau cible, adossée à une garantie.
- Ce qui se passe : le token canonique (native) est verrouillé sur le réseau A → sur le réseau B, une enveloppe est frappée pour le même montant.
- Ce que cela signifie pour vous : le prix de l’enveloppe tient tant que la garantie est réellement verrouillée et que le bridge peut exécuter correctement l’opération inverse (burn → release).
✅ Points forts
- Logique simple → garantie verrouillée → enveloppe équivalente sur l’autre réseau.
- Transparence → il est souvent clair ce qui garantit le token et dans quel contrat se trouve la garantie.
- Très répandu → souvent le format le plus supporté par les réseaux et les tokens.
❌ Où ça casse
- Règles Mint/Burn → erreur de vérification / logique d’émission → risque d’émission non garantie.
- Accès admin → pause/upgrade et rôles de gouvernance = point unique de défaillance.
- Concentration de TVL → un gros “coffre” de garantie devient une cible prioritaire pour les attaques.
Avant de garder de gros montants en enveloppe, identifiez qui contrôle mint/burn et quels droits existent pour pause/upgrade.
Dans Lock/Mint, le risque se situe dans le “coffre” et dans les droits de contrôle. Avec les liquidity pools, l’actif se trouve déjà sur le réseau de destination : le risque se déplace vers la liquidité — y aura-t-il assez de profondeur pour sortir près de $1 en situation de stress ?
💧 Liquidity pools — “sur place”, mais vous payez en liquidité
Vous recevez l’actif immédiatement sur le réseau cible, car il se trouve déjà dans un pool de liquidité local.
- Ce qui se passe : vous retirez le token du pool sur le réseau B → le déséquilibre est corrigé plus tard (rebalancement inter-chaînes des pools / arbitrage).
- Ce que cela signifie pour vous : le risque principal est le prix de sortie : en cas de déséquilibre, vous payez du slippage ou un discount.
✅ Points forts
- Vitesse → vous recevez l’actif “sur place”, sans attendre l’émission d’une enveloppe.
- Moins de concentration → moins de dépendance à un seul énorme contrat-coffre.
- Scénario plus simple → souvent moins d’étapes et un UX plus clair.
❌ Où ça casse
- Slippage → en cas de déséquilibre du pool, la sortie devient nettement plus chère.
- Discount → en scénario de stress, le “dollar” peut se trader sous la valeur nominale.
- Dépendance à l’arbitrage → l’équilibrage exige du capital et un marché actif.
Le bridge peut “fonctionner”, mais si le pool est mince, votre risque n’est pas dans le transfert — il est dans le prix de sortie.
Les pools offrent de la vitesse, mais le prix de sortie fluctue. Burn/Mint tente de supprimer cette faiblesse : le token n’est pas copié contre une garantie, il “se déplace” via un burn sur le réseau A et un mint sur le réseau B après un événement confirmé.
🔥 Burn/Mint — moins de “coffres”, plus d’exigences de synchronisation
Le token n’est pas copié : il est brûlé sur un réseau et émis sur un autre après confirmation de l’événement.
- Ce qui se passe : burn sur le réseau A → mint sur le réseau B après vérification du message.
- Ce que cela signifie pour vous : moins de “coffres” de garantie, mais les droits d’émission et la fiabilité des confirmations deviennent critiques.
✅ Points forts
- Pas de copies adossées à une garantie → transfert basé sur burn → mint via un événement.
- Moins de cibles → pas de gigantesque réserve à vider avec la garantie.
- Moins de confusion → moins de risque de voir deux “versions” parallèles du même actif s’installer durablement.
❌ Où ça casse
- Droits d’émission → qui peut mint sur le réseau de destination — risque central.
- Vérification des événements → un problème de confirmations casse l’émission / le rachat.
- Transfert bloqué → si les confirmations sont en pause, le transfert “reste coincé” entre réseaux.
Condition de sécurité : le modèle n’est bon que si les droits de mint sont transparents et que les confirmations ne dépendent pas d’un opérateur unique ni d’actions “manuelles”.
Burn/Mint répond à “qu’arrive-t-il au token”. Le message passing répond à “comment le réseau B sait que l’événement sur le réseau A a vraiment eu lieu”. Donc, l’important n’est pas le ticker, mais la qualité des confirmations : qui forme/signe les messages et comment ils sont vérifiés.
📨 Message passing — le bridge comme “livraison de preuves”
Le bridge ne transfère pas des tokens, il transfère une preuve : “sur le réseau A, l’événement a eu lieu — sur le réseau B, on peut exécuter l’action”.
- Ce qui se passe : l’événement est enregistré sur le réseau A → sur le réseau B, on autorise le mint / le déverrouillage (release) ou l’appel d’une fonction de contrat.
- Ce que cela signifie pour vous : la sécurité dépend de qui confirme les messages et de la rigueur de vérification des confirmations par le bridge.
✅ Points forts
- Flexibilité → confirmer des événements et déclencher des actions sans “transporter” des tokens.
- UX omnichaîne → plus simple de construire une expérience unifiée entre réseaux (transferts, appels, synchronisation).
- Moins d’enveloppes → parfois on peut réduire le nombre de “versions” d’un même actif.
❌ Où ça casse
- Confirmations → validation faible des messages = voie ouverte aux falsifications.
- Hypothèses de confiance → validateurs / relayers / oracles ajoutent une couche de risque infrastructurel.
- Complexité d’audit → plus de composants = plus de chances d’erreur dans la vérification des messages.
Point de départ : commencez par la question “qui et comment confirme les messages”, pas par une belle interface.
Risques des stablecoins bridgés : 4 zones où la “stabilité” se brise
Décomposons les risques des stablecoins bridgés en 4 zones pour repérer vite le maillon faible : l’émetteur, le bridge, la liquidité ou les opérations / la version du token — et comprendre quoi vérifier avant de garder un gros montant.
Un stablecoin bridgé ajoute une deuxième couche de confiance : au-delà du “dollar”, il y a l’infrastructure de transfert. Ci-dessous — quatre zones où les pannes surviennent le plus souvent, et des vérifications concrètes pour chacune.
🧾 Stablecoin
- Essence → qualité de la garantie et disponibilité réelle de la redemption (rachat) chez l’émetteur.
- Conséquence → doutes sur les réserves ou restriction du rachat → discount et liquidité “nerveuse”.
- Signal → rapports dégradés / moins fréquents, changements contestés dans le PoR / attestations, news sur banques / dépositaires.
- Vérification → quelles réserves sont déclarées, comment fonctionne le rachat, s’il existe des restrictions par adresses / juridictions et un chemin direct vers
native (bridge back) ou vers un CEX.
🔑 Bridge
- Essence → sécurité du mint/burn de l’“enveloppe” et fiabilité de la confirmation des événements inter-chaînes.
- Conséquence → hack ou falsification des confirmations → émission non garantie, blocage des retraits ou perte de la garantie.
- Signal → pauses fréquentes, upgrades soudains, hausse des délais, manque de transparence sur multisig / rôles (qui peut pause/upgrade/mint).
- Vérification → qui contrôle pause/upgrade, présence de multisig et timelock (délai des changements), audit, modèle de validation et post-mortems / updates publics sur les incidents.
🌊 Liquidité
- Essence → pourrez-vous sortir votre montant près de $1 sur ce réseau — pas “en théorie”.
- Conséquence → la sortie devient du slippage, et en panique — un discount au lieu de $1.
- Signal → déséquilibre des pools stables, baisse de profondeur, spread qui s’élargit, volumes en recul.
- Vérification → profondeur des pools / carnets pour votre montant et existence d’un itinéraire alternatif vers le réseau où la version
native /canonique existe, ou vers un grand CEX.
🧭 Opérations et version
- Essence → ticker identique ≠ token identique : ce sont le réseau et l’adresse du contrat qui comptent.
- Conséquence → dépôt de “la mauvaise version”, envoi vers le mauvais réseau ou vers un contrat tiers.
- Signal → tickers dupliqués dans le wallet/DEX et support variable des versions selon protocoles et exchanges.
- Vérification → adresse du contrat dans l’explorateur, nom exact / étiquettes (Bridged/Wrapped) et où le chemin de retour via le bridge (bridge back) vers
native est réellement disponible.
Où vérifier la garantie et les limites : checklist de contrôle
Suivez ces 6 étapes et vous comprendrez : quel contrat correspond au token, où se trouve la garantie, qui contrôle l’émission / la pause et quel est le prix de sortie en scénario de stress.
-
Version et contrat →
fiez-vous à l’adresse, pas au ticker. Ouvrez le token dans l’explorateur et vérifiez le nom exact et le contrat.
Les mentions Bridged/Wrapped et les suffixes
.e /.axl indiquent souvent une version bridgée. - Où est “le dollar” → trouvez la description du mécanisme de garantie : sur quel réseau la garantie est stockée, quel contrat émet le token sur votre réseau et comment fonctionne le retour via le bridge (burn → release). Si vous ne pouvez pas résumer ce mécanisme en une phrase, évitez d’y garder de gros montants.
- Correspondance “garantie ↔ émission” → comparez le volume du token canonique (native) verrouillé sur le réseau source (garantie) et le volume de l’enveloppe émise sur le réseau cible. Un écart est un red flag. Un dashboard aide, mais il vaut mieux recouper les chiffres dans l’explorateur via les adresses du vault et du minter.
- Qui tient “l’interrupteur” → vérifiez l’existence de pause (arrêt), upgrade (mise à jour de la logique) et des rôles mint/burn. Ensuite, le point clé est : qui contrôle ces droits — multisig + timelock (délai des changements) ou une seule clé / un admin. Une seule clé = risque de pause soudaine ou de “sortie fermée”.
- Limites (caps) et files d’attente → les caps sont des quotas quotidiens ou des volumes max pour émettre/retirer. En panique, la limite s’épuise vite, et même sans hack la sortie devient une attente : vérifiez le cap pour votre montant et ce qui se passe après (file d’attente / pause / validation manuelle par l’opérateur).
-
Prix de sortie →
évaluez la profondeur des pools DEX / carnets non pas “en général”, mais pour votre taille. Vérifiez le coût de conversion sans slippage important,
et s’il existe un itinéraire alternatif vers
native ou vers un exchange (y compris bridge back) sans goulots d’étranglement.
Cas : comment le peg a été perdu et pourquoi c’est crucial pour bridged et native
Deux classes d’échec : le modèle du stablecoin casse ou le transfert et la “sortie” cassent. Pour chaque cas : cause, point de défaillance et conclusion pratique.
📍 Quand le modèle du stablecoin flanche
Autre scénario : le stablecoin de base peut être robuste, mais le risque apparaît dans le bridge et dans la disponibilité de la conversion inverse.
🧷 Quand le bridge casse ou que la “sortie” se ferme
Conclusion générale : chez les stables native, le point faible est souvent le modèle et les réserves (surtout en cas de rachats massifs) ; chez les bridged, c’est l’infrastructure de transfert et l’accès à la sortie. Plus la somme est grande, plus il est important de connaître à l’avance le chemin de conversion, les limites et les goulots d’étranglement.
USDC et USDC.e : deux “dollars” avec des règles de sortie différentes
USDC et USDC.e ne diffèrent pas par le ticker, mais par la “sortie” : qui émet le token, où se trouve la garantie, et ce qui se passe si le bridge est mis en pause.
Sur certains réseaux, une version bridgée USDC.e est apparue en premier : le USDC canonique (native) était verrouillé sur le réseau source, et une enveloppe d’un montant équivalent était émise sur le réseau cible. Lorsque plus tard apparaît le USDC native (émission directe par l’émetteur sur ce réseau), deux versions similaires coexistent — avec des risques différents en termes de liquidité, support des services et vitesse de retour via le bridge (bridge back) ou de sortie vers un CEX.
| Ce que l’on compare | USDC native | USDC.e (bridgé) |
|---|---|---|
| Qui émet | Émetteur sur ce réseau | Bridge (enveloppe) |
| De quoi dépend la “sortie” | Règles de l’émetteur et disponibilité du rachat | Garantie sur le réseau source + fonctionnement du bridge (mint/burn, confirmations) |
| Support des services | Souvent le standard “principal” du réseau | Parfois pas accepté partout |
| Scénario de stress | Généralement plus stable sur le prix de sortie | Plus souvent en discount lors de pause/caps/files d’attente |
En marché calme, la différence est presque invisible. Mais si le bridge est mis en pause, si l’on bute sur des limites (caps) ou si la file d’attente de retrait s’allonge, l’enveloppe peut passer en discount — même si tout va bien pour USDC. D’où l’importance de vérifier non pas le “ticker”, mais la mécanique de redemption (rachat) et la réalité du chemin de retour : bridge back vers le réseau canonique ou sortie vers un CEX.
Signaux précoces de problèmes : quoi repérer avant un depeg
Observations “avant la panique” : où regarder et quels signes indiquent que la sortie peut devenir chère, limitée ou temporairement indisponible.
✅ Signaux auxquels il faut réagir
-
Le bridge ralentit ou passe en maintenance :
les délais augmentent, les statuts ne donnent pas d’échéance, des files apparaissent.
Que faire : réduire le montant en version bridgée et éviter d’y entrer avec de gros montants tant que le mode normal n’est pas rétabli.
-
La TVL baisse dans les paires de stables :
la TVL (valeur verrouillée) quitte les pools clés de cette version du stable — la profondeur baisse, la sortie devient plus chère.
Que faire : vérifier le slippage pour votre montant et l’existence d’un itinéraire alternatif.
-
Les pools de stables deviennent déséquilibrés :
le balance penche d’un côté — le marché “bascule” hors d’une version particulière du stable.
Que faire : préparer à l’avance le chemin de retour : bridge back vers le réseau canonique ou sortie vers un CEX tant que le prix de sortie reste acceptable.
-
Les droits et paramètres du bridge changent :
changement des signataires multisig, upgrades, activation de pause, modification des limites ou hausse brutale d’actions depuis des adresses système.
Que faire : stopper les gros transferts et réduire l’exposition jusqu’à clarification du statut et des raisons des changements.
-
Le discount dure des heures :
un prix sous $1 persiste longtemps — c’est déjà une évaluation du risque de sortie, pas un bruit de quelques minutes.
Que faire : sortir par petites tranches, sans écraser une liquidité mince.
Que choisir : quand privilégier le Native et quand le Bridged est pertinent
Le choix porte sur le contrôle de la sortie (bridge back, CEX et coût de sortie). Pour le stockage, l’important est un chemin de conversion fiable ; pour les tâches multichaînes — compatibilité et vitesse, en tenant compte de la pause (pause), des limites (caps) et du coût de sortie pour votre montant.
🟩 Stablecoin native
Adapté au stockage et aux règlements, quand l’émission existe directement via l’émetteur sur le réseau. Règle : si la somme est significative — commencez par le native.
- Scénarios : stockage, règlements, collatéral/marge, sortie vers un exchange ou vers des canaux fiat.
- Vérification : réserves et reporting, redemption (rachat chez l’émetteur), support par les CEX/wallets/protocoles DeFi majeurs de ce réseau.
✅ Avantages
- Moins de points de défaillance → pas de bridge séparé comme couche obligatoire pour sortir.
- Standard du réseau → plus souvent accepté “par défaut” par les protocoles, wallets et exchanges.
- Liquidité plus prévisible → moins de risque de buter sur une pause/file d’attente à cause de problèmes de bridge.
❌ Inconvénients
- Contraintes de compliance → chez les émetteurs centralisés, gel possible de certaines adresses.
- Politique de l’émetteur → les règles sont définies “d’en haut” et peuvent changer.
- Couverture par réseaux → le native n’existe pas partout et apparaît parfois après les versions bridgées.
En pratique : si le native est disponible sur le réseau, il devient souvent l’option de base pour les gros montants et les règlements.
🟦 Stablecoin bridgé
Adapté au scénario “j’ai transféré → j’ai fait l’action → je sors”, quand on a besoin du cross-chain ou quand il n’y a pas de native sur le réseau. Règle : ne gardez que ce qui est nécessaire à l’opération.
- Scénarios : transit entre réseaux, actions DeFi courtes, écosystèmes sans émission officielle.
- Vérification : qui contrôle pause/upgrade, quels caps (limites) s’appliquent, s’il existe de la liquidité et combien coûte la sortie pour votre montant.
✅ Avantages
- Accès à de nouveaux réseaux → permet d’opérer là où le native n’est pas encore lancé.
- Transfert opérationnel → facilite le déplacement de capital entre écosystèmes et apps.
- Pratique pour une tâche → utile quand le chemin de retour (bridge back) vers
native /réseau canonique ou la sortie vers un CEX est clair.
❌ Inconvénients
- Point de défaillance → erreur / hack du bridge affecte la garantie et la confiance dans l’enveloppe.
- Restrictions de retrait → pause/caps/files d’attente peuvent bloquer la sortie dans le temps.
- Discount de marché → en stress, l’enveloppe s’écarte plus souvent de $1 à cause de l’incertitude du retour (bridge back).
En pratique : bridged — un outil puissant pour les opérations, mais un mauvais candidat pour le stockage long terme.
❓ FAQ : Native vs Bridged — réponses rapides avant de stocker et de transférer
Réponses courtes avant action : comment reconnaître une version bridgée, pourquoi un discount apparaît, pourquoi regarder les caps (limites) et en quoi pause (pause) / upgrade (upgrade) sont risqués.
Comment savoir si le stablecoin sur ce réseau est bridgé et non native ?
Dans l’interface, se fier au ticker est risqué : ce sont le réseau et l’adresse du contrat qui décident.
Les signes d’une version bridgée : mentions Bridged/Wrapped, suffixes
Le critère pratique est simple : si vous ne pouvez pas répondre brièvement “où est la garantie” et “à quoi ressemble le retour (bridge back)”, le risque de sortie est plus élevé, même si le prix est proche de $1.
Pourquoi un stablecoin bridgé peut-il se trader sous $1, même si la version canonique (native) est stable ?
Le discount reflète généralement non pas la “qualité du dollar”, mais le risque et le coût de sortie.
Si le retour vers
Causes typiques : pause (pause) activée, caps (limites) épuisés, files d’attente de retrait, baisse de profondeur des pools DEX / carnets et hausse du slippage (slippage — pertes de glissement).
Que sont les limites d’un bridge (caps) et pourquoi sont-elles importantes ?
Les caps (limites) sont des restrictions sur l’émission/retrait par période ou sur un volume total par actif/route. Leur but est de réduire les dégâts en cas d’incident, mais en stress, les caps deviennent souvent un “goulot d’étranglement” : la limite est saturée, et la sortie est décalée dans le temps (file) ou indisponible jusqu’au renouvellement du quota.
C’est pourquoi il faut évaluer les caps en fonction du montant : ce qui suffit pour de petits transferts peut être critique pour une grosse sortie “ici et maintenant”.
Pourquoi les fonctions pause et upgrade sont-elles risquées dans les bridges ?
Pause arrête les dépôts/retraits, et upgrade — souvent via proxy (contrat upgradable) — permet de modifier la logique du bridge sans changer l’adresse du contrat. C’est utile pour corriger vite des failles, mais cela ajoute un risque de gouvernance : multisig et timelock (délai avant changements) comptent.
Plus il est facile d’arrêter le système ou de changer les règles d’émission/vérification “à la main”, plus il est probable qu’en situation de stress, le risque principal ne soit pas le cours, mais la disponibilité de la sortie.
Qu’est-ce qui est mieux : une “enveloppe” bridgée ou un transfert burn-and-mint ?
Le burn-and-mint (brûler → émettre) transfère l’actif via un événement : le token est brûlé sur un réseau et émis sur un autre après confirmation du message. Ce schéma réduit la dépendance à un “gros coffre” de garantie, cible privilégiée des attaques dans les modèles lock/mint.
Mais le risque ne disparaît pas : il se déplace vers la qualité des confirmations (qui signe/vérifie les messages) et vers les droits d’émission (qui peut mint), ainsi que vers les fonctions de gouvernance pause/upgrade. En pratique, le critère est le même — transparence du contrôle et réalité du chemin de retour.
Conclusion finale : choisissez selon le chemin de sortie, pas selon le ticker
Le ticker n’est pas le risque : l’origine du token, le contrôle de l’infrastructure et le coût de sortie en scénario de stress sont décisifs.
Native et Bridged peuvent sembler identiques dans l’interface, mais ce sont des constructions différentes. Native est émis par l’émetteur sur ce réseau — c’est lui qui définit les règles de circulation et de rachat. Bridged est une enveloppe : son prix tient tant que la garantie est réellement verrouillée (et visible sur le réseau source), que le bridge exécute correctement mint/burn (émission/brûlage) et qu’un chemin de retour reste disponible.
Avant de garder une version bridgée pour un montant notable, répondez à trois questions : pause — que se passe-t-il si les dépôts/retraits sont arrêtés ; itinéraire — comment vous faites exactement le bridge back vers le réseau canonique ou la sortie vers un CEX ; coût — les caps (limites), la file d’attente ou le slippage vont-ils “manger” la sortie pour votre montant ? Si vous ne pouvez pas nommer l’itinéraire et les limites — réduisez l’exposition.
Règle principale :