# Seul l’USDC traverse, et cela prend quinze minutes

> La plupart des plans couvrent plus d’un réseau sans le dire. Deux contraintes les façonnent, et les deux surprennent.

- Source: https://defiloops.com/fr/blog/only-usdc-crosses-and-it-takes-fifteen-minutes
- Published: 2026-06-23
- Category: Architecture
- Tags: bridging, multi-chain, cctp, execution
- Author: DeFiLoops

---
« Mon portefeuille détient 1 000 USDC sur Base, 1 000 sur Ethereum et 1 000 sur Arbitrum.
Prête chacun à un pool de prêt. »

« Prends 100 USDC sur Base et achète du XAUT depuis Ethereum. »

Ce sont deux vraies demandes. La première n’a pas besoin de pont ; la seconde ne peut pas
l’éviter. Les distinguer représente l’essentiel de ce qui se passe entre votre phrase et une
transaction, et deux contraintes décident de la forme de la réponse.

## Contrainte une : seul l’USDC traverse

La traversée du catalogue est le CCTP de Circle, et le CCTP transporte de l’USDC. Pas du WETH,
pas du cbBTC, pas d’or tokenisé.

Ce seul fait réécrit des plans. Prenez la demande sur l’or : vous avez des dollars sur Base,
vous voulez un actif qui vit sur Ethereum. Deux formes existent en principe —

<Compare left="Acheter ici, faire passer l’actif" right="Faire passer les dollars, acheter là-bas" verdict>
  <Fragment slot="left">
    Échanger l’USDC contre du XAUT sur Base, puis déplacer le XAUT vers Ethereum.

    Inexprimable. Il n’existe pas de traversée pour le XAUT, donc ce plan est refusé au moment
    où il est écrit.
  </Fragment>
  <Fragment slot="right">
    Déplacer l’USDC vers Ethereum, puis échanger là-bas.

    La seule forme qui existe, donc celle que vous obtenez — que vous y ayez pensé ou non.
  </Fragment>
</Compare>

<Callout type="danger" title="Un pont dimensionné depuis un swap qui a produit du WETH est refusé">
  C’est la version qui surprend ceux qui font attention. Si une étape antérieure produit du
  WETH et que vous dimensionnez la traversée à partir de là, la validation refuse — à juste
  titre, puisque la traversée ne peut pas transporter de WETH. La phrase ne parlait pas d’USDC,
  donc le refus semble sortir de nulle part.
</Callout>

## Contrainte deux : quinze minutes, et cela ne s’accélère pas

Une traversée n’est pas une transaction un peu longue. La valeur quitte une chaîne, le temps
passe, et la valeur arrive sur une autre. Environ quinze minutes, fixées par Circle, pas par
nous.

Tout le reste en découle.

<Spec title="Ce que l’attente fait à un plan" rows={[
  ['Les étapes de l’autre côté ne peuvent pas démarrer plus tôt', 'Le plan se construit autour du trou plutôt que sur un espoir'],
  ['Un montant d’exécution ne peut pas la traverser', 'Une étape après un pont ne peut pas dépenser « ce que le swap a renvoyé » : ce sont deux transactions, sur deux chaînes'],
  ['L’exécution doit y survivre', 'Quinze minutes suffisent pour que nous livrions une mise à jour en cours de route, donc la progression vit dans une base de données, pas dans la mémoire d’un processus'],
  ['Les ponts en dernier quand c’est possible', 'Tout ce qui peut être fait d’un côté l’est avant l’attente, pas après'],
]} />

<Callout type="warn" title="Le bus ne peut pas traverser une transaction">
  Dans une même transaction, une étape peut dépenser exactement ce que la précédente a produit.
  À travers une traversée, non : il n’y a pas d’instant partagé où ce nombre puisse vivre. Un
  plan qui essaie renvoie `NothingDelivered`, ce qui est le bon refus et une erreur déroutante
  tant qu’on n’en connaît pas la raison.
</Callout>

## Ce que l’ordonnancement fait réellement

Compte tenu de ces deux contraintes, un plan multi-chaînes n’est pas « les étapes que vous avez
listées, dans l’ordre où vous les avez listées ».

Prenez la demande aux trois portefeuilles. Prêter sur Base ne dépend en rien de prêter sur
Arbitrum : elles ne font donc pas la queue, elles s’exécutent en même temps. Aucune traversée
n’est nécessaire, car l’argent est déjà là où il doit être. Le bon plan pour cette phrase ne
contient aucun pont, et un système qui supposerait que « multi-chaînes veut dire ponter »
aurait ajouté trois traversées inutiles et vous les aurait facturées.

Maintenant un plan qui doit vraiment traverser :

<Steps>
  <Step title="Repliez ce qui peut l’être">
    Les étapes qui peuvent partager une transaction sont fusionnées. « Approuver puis déposer »
    en une seule transaction signifie que l’approbation ne peut pas survivre à un dépôt raté.
  </Step>
  <Step title="Regroupez par chaîne">
    Tout ce qui est faisable sur Base est regroupé, pour que le plan traverse le moins possible.
  </Step>
  <Step title="Placez les traversées tard">
    Une traversée est l’étape la plus lente et la plus chère. Tout ce qui peut se faire avant
    l’attente se fait.
  </Step>
  <Step title="Coupez là où la valeur ne peut pas être portée">
    Là où un montant d’exécution ne peut pas survivre jusqu’à l’étape suivante, une nouvelle
    transaction commence. Le tableau l’affiche en pointillés avant que vous n’approuviez.
  </Step>
</Steps>

## Ce que cela coûte

Fixe, ce qui compte plus que le pourcentage.

<StatRow>
  <Stat value="0,50 $" label="par traversée" note="Fixe, quelle que soit la taille." />
  <Stat value="0,1 %" label="frais de traversée" note="Du montant envoyé." />
  <Stat value="~15 min" label="par traversée" accent note="Fixé par Circle. Ne s’accélère pas." />
</StatRow>

Comme les frais sont fixes, ils dominent un petit plan et disparaissent dans un gros. Trois
traversées sur un plan de 1 000 $ font 1,50 $ de pont — environ 0,15 %, soit un mois de
rendement sur une position de prêt. Les mêmes trois traversées sur 100 000 $ font 0,0015 %, et
à ce stade le glissement sur les swaps compte bien plus que les ponts.

<Callout type="note" title="Vous ne pontez jamais le gas">
  Une clé distincte à nous paie les frais de réseau sur chaque chaîne et se rembourse depuis le
  plan dans un actif qu’il détient déjà. Vous n’avez pas à détenir la monnaie native d’une
  chaîne que vous n’avez jamais utilisée, ce qui est d’ordinaire la partie la plus pénible du
  travail multi-chaînes.
</Callout>

## Demandez avant de planifier

Comme les contraintes sont précises, « puis-je faire ceci ? » veut généralement dire en réalité
« puis-je faire ceci **sur ce réseau** ? » — et les réponses diffèrent assez souvent pour que
cela compte.

Demander quels actifs, réseaux et opérations existent ne coûte rien et prend une question.
C’est un bien meilleur usage de trente secondes que de découvrir la réponse dans une erreur de
validation après avoir écrit le plan.