Le RFQ de Dexalot permet à un trader sur n’importe quelle chaîne prise en charge d’échanger contre le carnet d’ordres de l1 de Dexalot dans une seule transaction atomique — pas de pont, pas d’actif encapsulé, pas de fenêtre d’attente.
December 24, 2024 |
Le trading multi-chaînes dans la crypto est généralement un problème de pont déguisé en problème d’UX. Vous voulez AVAX, mais votre USDC est sur Arbitrum. La réponse standard consiste à faire un pont : verrouiller votre USDC sur une chaîne, frapper une représentation tokenisée (wrapped) sur une autre, attendre la finalité, accepter que vous détenez désormais un actif dont le remboursement dépend de la solvabilité d’un contrat tiers, puis trader. Chaque étape ajoute du délai, des hypothèses de confiance et un risque d’exécution.
Le SimpleSwap de Dexalot ne fait pas ça. Un utilisateur sur Arbitrum peut acheter en direct un token sur Dexalot L1, payer avec son USDC natif, et recevoir le token de sortie nativement sur Avalanche — sans actif wrapped, sans transaction de pont et sans salle d’attente. Le mécanisme qui rend cela possible est un système RFQ que la plupart des utilisateurs ne voient jamais. Cet article explique ce que cela fait réellement.
RFQ signifie Request for Quote (Demande de cotation). C’est l’une des structures de marché les plus anciennes de la finance, antérieure de plusieurs siècles aux carnets d’ordres des exchanges. Dans un RFQ TradFi, un acheteur demande à un dealer un prix pour une taille précise d’un actif précis. Le dealer répond avec une cotation ferme : “Je vous vends 10 000 actions à 42,17 $ , valable 30 secondes.” Si l’acheteur accepte dans la durée de vie de la cotation, la transaction se fait à exactement ce prix.
La propriété déterminante d’un RFQ est que le prix est un engagement de la part d’un contrepartiste spécifique. Ce n’est pas un instantané d’un carnet public susceptible d’évoluer entre la demande et l’exécution. Ce n’est pas non plus une courbe qui bougera contre vous de manière déterministe. C’est un prix que quelqu’un a accepté d’honorer, signé, et mis sur la table.
Structurationnellement, c’est différent de la manière dont fonctionne la plupart des échanges sur DEX. Les AMM vous fixent le prix via une courbe de bonding (voir notre article précédent sur le slippage). Les carnets d’ordres en streaming vous permettent de voir la liquidité en attente, mais le prix auquel vous êtes réellement exécuté dépend de ce qui reste disponible lorsque votre transaction arrive. Le RFQ supprime cette ambiguïté : la cotation est le prix, point final.
La solution par défaut pour le trading multi-chaînes, c’est le pont. La mécanique varie — lock-and-mint, burn-and-mint, optimistic, zk-vérifiée — mais l’expérience utilisateur converge vers la même forme.
Pour un trader qui veut simplement échanger un actif contre un autre, le pont constitue à lui seul un workflow entier placé entre l’intention et l’exécution. C’est aussi le niveau où la plupart de la valeur multi-chaînes se perd, soit à cause d’exploits directs, soit à cause du slippage du côté de l’actif wrapped.
Dexalot est construit sur un modèle hub-and-spoke (hub et rayons). Le hub est Dexalot L1 — la chaîne dédiée à l’application où vit le carnet d’ordres canonique. Les spokes sont des smart contracts déployés sur chaque chaîne prise en charge (Avalanche, Arbitrum, Base, BNB Chain), chacun détenant un petit inventaire des tokens base et quote pour les paires qu’ils servent.
Deux éléments d’infrastructure rendent le RFQ multi-chaînes possible :
Le carnet d’ordres lui-même ne quitte jamais Dexalot L1. Il n’y a pas de carnet d’ordres fragmenté, pas de moteur d’appariement multi-chaînes, et pas de liquidité dupliquée entre les déploiements. Il n’y a qu’une seule source de vérité pour le prix, ainsi que de petits pools d’inventaire aux bords pour servir les utilisateurs là où ils se trouvent déjà.
Passons par un exemple concret. Un utilisateur sur Arbitrum souhaite échanger 5.000 USDC contre AVAX. Le couple AVAX/USDC s’échange sur le carnet d’ordres Dexalot L1. L’utilisateur n’a jamais utilisé de pont, n’a aucune intention de passer par un pont, et interagit uniquement avec son wallet sur Arbitrum.
Du point de vue de l’utilisateur, l’interaction entière correspond à une seule transaction sur Arbitrum. Pas de dialogue de pont. Aucun actif encapsulé dans son wallet. Aucune fenêtre de délai.
Cette expression est surutilisée dans le marketing crypto ; il vaut donc la peine d’être précis sur ce qu’elle veut dire ici.
L’utilisateur ne détient jamais un actif ponté. Le jeton d’entrée est natif sur la chaîne source, et le jeton de sortie est natif sur la chaîne de destination. Lorsque le swap se règle sur Arbitrum, les AVAX que l’utilisateur reçoit sont les mêmes AVAX que détient n’importe qui d’autre sur le réseau — et non un dérivé encapsulé échangeable contre un pont via un contrat.
Le règlement lui-même est atomique sur la chaîne de l’utilisateur. Il n’y a pas de commit en deux phases, pas d’attente de confirmations sur une deuxième chaîne avant que l’utilisateur soit intégralement servi. La partie de la transaction côté utilisateur se termine en une seule transaction Arbitrum, signée une fois, et soit elle s’exécute entièrement soit elle se révoque.
Ce qui traverse la frontière de chaîne, c’est l’infrastructure de messages : les mises à jour du carnet d’ordres et le flux de rebalancing de l’inventaire entre les chaînes via LayerZero, mais uniquement côté opérateur. Les utilisateurs ne signent jamais une transaction de pont. Ils n’attendent jamais un pont. Le pont n’est plus sur leur chemin.
Les agrégateurs DEX comme 1inch, Kyberswap, Odos, Velora et OpenOcean routent les transactions à travers le paysage DEX disponible afin de trouver la meilleure exécution pour l’utilisateur. Les AMM font naturellement partie de ce paysage, mais elles ont un problème de routage que le RFQ résout de manière élégante.
Lorsqu’un agrégateur route via une AMM, le prix de remplissage réel dépend de la courbe, des autres transactions qui arrivent dans le même bloc, et de ce que toute tentative de sandwich que produit le mempool. Les agrégateurs gèrent cela avec des tolérances de slippage et des reverts, mais l’incertitude est structurelle.
Lorsqu’un agrégateur route via le RFQ de Dexalot’s, la cotation est un engagement signé. L’agrégateur connaît le résultat exact, peut l’afficher à l’utilisateur avec confiance, et la transaction se remplit à ce prix ou ne se remplit pas du tout. Il n’y a pas de variable de slippage à modéliser et pas de surface MEV pour que des bots de sandwich l’exploitent.
Du point de vue de l’agrégateur, une source RFQ est l’intégration la plus simple possible : prix clair, règlement atomique, comportement prévisible. C’est pourquoi chaque grand agrégateur prend désormais en charge un flux RFQ en parallèle du routage via AMM, et pourquoi les intégrations de Dexalot à travers toutes les chaînes qu’il prend en charge se traduisent directement en volume routé vers le carnet d’ordres L1.
La combinaison d’un CLOB on-chain, d’une architecture hub-and-spoke et d’une couche inter-chaînes pilotée par RFQ produit une UX qui ne donne pas l’impression d’être inter-chaînes. Un trader sur Arbitrum, un trader sur Avalanche, un trader sur Base et un trader sur BNB Chain interagissent tous avec la même liquidité, aux mêmes prix, au même instant — sans qu’aucun d’entre eux ne touche un bridge.
Pour le projet référencé sur Dexalot, cela signifie qu’une seule source de liquidité sert de nombreux marchés. Pour l’utilisateur, cela signifie que l’inter-chaînes cesse d’être une étape du workflow et devient une propriété de l’infrastructure sous-jacente. Pour l’écosystème DEX dans son ensemble, cela signifie qu’il existe désormais un moyen de délivrer une exécution via carnet d’ordres à des chaînes où construire un carnet d’ordres directement n’aurait jamais été viable.
Les bridges ont résolu le problème du transfert d’un actif entre chaînes. Le RFQ résout le problème de ne pas avoir besoin de le faire.
