Comment Omniston gère les swaps EVM-vers-EVM sur STON.fi
Le trading cross-chain est souvent présenté comme si le fait de transférer un actif d’une blockchain à une autre devait être aussi simple que d’échanger deux tokens sur une bourse décentralisée.
En réalité, le processus sous-jacent peut être beaucoup plus complexe.
Un échange DEX conventionnel se produit généralement au sein d’une seule blockchain. La liquidité est disponible sur ce réseau, les transactions sont exécutées par des contrats sur le même registre, et l’intégralité de l’échange suit l’environnement d’exécution d’une chaîne.
Le trading EVM-to-EVM inter-chaînes entre Ethereum, BNB Chain, Base, Polygon et d’autres réseaux pose un problème différent : les actifs échangés existent sur des blockchains distinctes qui ne partagent pas un historique de transaction unique.
C’est là que l’approche d’Omniston par STON.fi se distingue.
Plutôt que de forcer le trade via une séquence bridge-and-swap traditionnelle, Omniston traite l’interaction comme un ordre inter-chaînes. Le système combine un modèle RFQ (Request for Quote), une liquidité concurrentielle de resolveurs et des Hashed Timelock Contracts (HTLC) jumelés pour coordonner le règlement entre des réseaux EVM indépendants.
Le résultat est une expérience utilisateur qui peut donner l’impression d’un seul swap, tandis que le règlement sous-jacent est réalisé via des mécanismes coordonnés sur plusieurs chaînes.
Que fait Omniston différemment ?
Au cœur d’Omniston, le système est conçu pour abstraire une grande partie de la complexité liée à l’exécution inter-chaînes.
Au lieu d’exiger qu’un utilisateur complète manuellement plusieurs actions sur différents réseaux, l’interface présente une seule intention inter-chaînes : l’actif que l’utilisateur veut vendre, l’actif qu’il veut recevoir et les réseaux impliqués.
Derrière cette demande, les resolveurs s’affrontent pour fournir la liquidité côté destination et exécuter la transaction selon les termes cotés.
Cela crée une distinction importante.
Omniston n’a pas besoin de faire de TON un arrêt intermédiaire pour chaque route inter-chaînes. Dans un scénario EVM-to-EVM, l’actif source et l’actif destination peuvent rester sur leurs réseaux EVM respectifs tandis que le protocole coordonne le règlement entre eux.
Le support de la phase 1 inclut des réseaux majeurs comme Ethereum, BNB Chain, Base et Polygon, créant une base pour l’échange multi-réseaux d’actifs sans obliger l’utilisateur à construire manuellement une route de bridge.
Le modèle RFQ : la liquidité s’affronte pour l’ordre
L’un des composants les plus importants de l’architecture d’Omniston est son modèle RFQ.
RFQ signifie Request for Quote (demande de cotation).
Au lieu de dépendre exclusivement d’un unique pool de liquidité pour déterminer le prix d’exécution, le système permet aux resolveurs de se concurrencer en fournissant des cotations pour un ordre inter-chaînes.
Un flux simplifié ressemble à ceci :
Le trader spécifie l’actif qu’il souhaite vendre et l’actif qu’il souhaite recevoir.
Omniston diffuse l’ordre aux resolveurs éligibles.
Les resolveurs évaluent la demande, la liquidité destination, les coûts d’exécution, les conditions réseau et d’autres facteurs.
Ils renvoient des cotations décrivant ce qu’ils peuvent fournir.
Le système peut alors sélectionner un chemin d’exécution approprié en fonction des offres disponibles.
Ce modèle est particulièrement important pour le trading inter-chaînes, car la liquidité peut être fragmentée entre les réseaux.
Un resolveur peut fournir efficacement de la liquidité là où le trader en a besoin sur la chaîne destination tout en coordonnant séparément la transaction côté source.
Pour le trader, cela réduit le besoin de comprendre l’infrastructure derrière la route.
Pourquoi les HTLC jumelés sont importants
Le deuxième composant majeur est l’utilisation de Hashed Timelock Contracts, communément appelés HTLC.
Le défi d’une transaction inter-chaînes est simple :
Comment deux parties peuvent-elles échanger des actifs qui existent sur des blockchains différentes, sans dépendre d’une transaction partagée unique ?
La réponse est de créer des conditions cryptographiques correspondantes sur les deux réseaux.
Dans un exemple simplifié, le trader verrouille un actif à l’intérieur d’un HTLC côté source.
Ce contrat inclut :
Un hashlock, qui définit le secret nécessaire pour réclamer les fonds.
Un timelock, qui définit ce qui se passe si l’échange n’est pas terminé dans la période autorisée.
Pendant ce temps, le resolveur verrouille l’actif destination correspondant en utilisant une condition HTLC compatible.
Les deux côtés sont donc connectés via le même secret cryptographique sous-jacent.
Le secret coordonne le règlement
L’élément important dans le processus est le secret utilisé par le hashlock.
Les actifs ne peuvent pas simplement être réclamés arbitrairement. Les conditions intégrées dans les contrats déterminent comment un règlement peut avoir lieu.
Lorsque le bon secret est révélé pour réclamer un côté de l’échange, ce secret peut être utilisé pour satisfaire la condition correspondante de l’autre côté.
Cela crée un mécanisme de règlement synchronisé entre des blockchains indépendantes.
L’idée clé n’est pas qu’Ethereum et Base partagent soudainement un registre commun.
Ils ne le font pas.
Au lieu de cela, les contrats sur des réseaux distincts appliquent des règles compatibles qui permettent d’achever l’échange selon la même condition cryptographique.
C’est ce qui donne au mécanisme ses caractéristiques de règlement atomique.
Que se passe-t-il si le trade échoue ?
L’infrastructure inter-chaînes doit aussi gérer l’échec.
Les réseaux peuvent être congestionnés. Les transactions peuvent être retardées. Un resolveur peut échouer à terminer l’exécution. Une condition de règlement peut ne pas être satisfaite dans la période requise.
C’est là que le timelock devient critique.
Si les conditions requises pour le règlement ne sont pas satisfaites avant le délai pertinent, le mécanisme HTLC permet à la partie appropriée de rembourser les actifs verrouillés conformément aux règles du contrat.
Le système n’est donc pas dépendant du fait que chaque transaction réussisse parfaitement.
Au lieu de cela, c’est conçu autour de deux issues possibles :
Règlement réussi : la condition cryptographique est satisfaite et les actifs peuvent être réclamés.
Délai : le règlement ne se termine pas dans la fenêtre requise et le mécanisme de remboursement devient disponible.
Cela rend l’ordre inter-chaînes plus robuste qu’un processus où les utilisateurs doivent coordonner manuellement plusieurs transactions indépendantes.
Pourquoi c’est différent d’un DEX traditionnel
Un swap DEX normal est relativement simple, car les deux actifs sont généralement disponibles sur la même blockchain.
Par exemple, un trader qui échange un token contre un autre sur Ethereum peut interagir avec un pool de liquidité ou un système de routage qui fonctionne entièrement dans l’environnement d’exécution d’Ethereum.
La blockchain fournit déjà l’état partagé nécessaire pour exécuter le trade.
Les swaps EVM-to-EVM sont différents.
Ethereum et Polygon, par exemple, conservent des états indépendants. Une transaction confirmée sur l’un n’exécute pas automatiquement une transaction équivalente sur l’autre.
Omniston ne peut donc pas traiter un swap multi-chaînes comme une seule transaction littérale sur une blockchain.
Au lieu de cela, il crée une seule intention de trading soutenue par plusieurs étapes d’exécution coordonnées.
L’interface peut sembler unifiée, mais le règlement sous-jacent se produit encore séparément sur chaque réseau.
Cette distinction est importante.
L’atomicité vient des règles du protocole, des conditions cryptographiques et des mécanismes de timeout, pas d’une transaction magique unique s’étendant sur plusieurs blockchains.
Aucun intermédiaire TON requis
Un autre aspect important de la conception EVM-to-EVM d’Omniston est que TON n’a pas besoin d’être au milieu de la transaction.
Pour une route EVM-to-EVM, le trader n’a pas nécessairement besoin de convertir l’actif source en TON, de passer par l’écosystème TON, puis de reconvertir vers l’actif destination souhaité.
Au lieu de cela, Omniston peut coordonner directement les chaînes source et destination via son architecture d’exécution inter-chaînes.
Cela peut réduire des étapes inutiles du point de vue de l’utilisateur et rendre le trading multi-réseaux beaucoup plus proche d’un swap normal.
L’abstraction importante est donc :
un ordre, plusieurs réseaux, règlement coordonné.
Exécutions partielles pour des ordres plus importants
Le trading inter-chaînes a aussi un problème de liquidité qui devient plus visible lorsque la taille de l’ordre augmente.
Un gros ordre n’est pas toujours rempli efficacement par une seule source ou un seul resolveur.
Omniston peut prendre en charge des exécutions partielles, permettant de traiter des ordres plus importants via plusieurs opportunités d’exécution plutôt que de dépendre entièrement d’une seule source de liquidité.
Cela peut être utile car la liquidité inter-chaînes est rarement distribuée de manière uniforme.
Un resolveur peut proposer une exécution attrayante pour une partie de l’ordre, tandis qu’un autre est mieux placé pour une autre portion.
Un système capable de gérer une exécution partielle peut donc être plus flexible lorsqu’il s’agit de liquidité fragmentée.
L’expérience utilisateur vs. l’infrastructure
L’une des idées les plus solides derrière Omniston est la séparation entre ce que l’utilisateur voit et ce que le protocole doit réellement faire.
Du point de vue du trader, le flux peut rester relativement simple :
Choisissez l’actif à vendre.
Choisissez l’actif à recevoir.
Consultez la cotation disponible.
Approuver la transaction.
Laissez le processus d’exécution inter-chaînes se terminer.
Derrière cette interface simple, plusieurs choses peuvent toutefois se produire.
Les resolveurs se font concurrence pour l’ordre.
La liquidité est évaluée.
Les coûts de gas sont pris en compte.
Les contrats source et destination sont en cours de préparation.
Les conditions HTLC sont en cours d’établissement.
Les transactions sont soumises indépendamment aux réseaux concernés.
Le règlement est coordonné via les conditions cryptographiques.
Cette abstraction est importante car les utilisateurs ne veulent généralement pas devenir des experts en coordination de transactions inter-chaînes juste pour déplacer un actif entre deux réseaux EVM.
Ce qui compte encore : cotations, gas et liquidité
Omniston n’élimine pas tous les défis associés au trading inter-chaînes.
La qualité de l’exécution dépend encore de plusieurs facteurs pratiques.
La qualité de la cotation compte. Une route inter-chaînes n’est utile que si le montant reçu est compétitif.
Les coûts de gas comptent. Chaque réseau participant peut introduire des frais de transaction qui influencent le coût total d’exécution.
La liquidité compte. Un resolveur a besoin d’une liquidité suffisante du côté destination pour exécuter l’ordre efficacement.
Les conditions réseau comptent. La congestion, les délais de confirmation et la fiabilité des transactions peuvent influencer l’exécution.
Ainsi, même si l’interface peut simplifier le processus, l’économie sous-jacente du trading ne disparaît pas.
L’abstraction inter-chaînes rend l’expérience plus simple ; elle ne rend pas la liquidité, les frais ou les conditions réseau sans importance.
La sécurité par la coordination, pas par la centralisation
Une autre façon utile de comprendre l’architecture est qu’Omniston ne nécessite pas un seul coffre inter-chaînes partagé, contrôlé par un unique intermédiaire, pour le swap lui-même.
À la place, les chaînes source et destination conservent leurs propres contrats et appliquent leurs propres conditions.
La coordination se fait via la logique d’exécution du protocole et des garanties cryptographiques.
Cette structure est significative car elle réduit l’écart conceptuel entre l’intention de l’utilisateur et le mécanisme de règlement réel.
L’utilisateur ne fait pas que faire confiance à un intermédiaire pour déplacer éventuellement les actifs.
Le trade est structuré de sorte que les contrats sur les réseaux concernés définissent comment l’échange doit se dérouler et ce qui se passe si ces conditions ne sont pas remplies.
La vue d’ensemble du trading inter-chaînes
Le modèle EVM-to-EVM d’Omniston illustre un changement plus large dans le trading décentralisé.
L’avenir de l’UX inter-chaînes ne dépend peut-être pas du fait que les utilisateurs apprennent comment fonctionne chaque blockchain individuelle.
Au lieu de cela, l’infrastructure peut gérer le routage, la découverte de liquidité et la coordination du règlement sous une expérience de trading unifiée.
Vu sous cet angle, le problème inter-chaînes devient moins une question de déplacement manuel d’actifs entre chaînes, et davantage une question d’exprimer une intention :
« Je veux vendre cet actif ici et recevoir cet autre actif là-bas. »
Les resolveurs s’affrontent ensuite pour satisfaire cette intention, tandis que les mécanismes de règlement cryptographique garantissent que l’exécution suit des règles définies.
C’est fondamentalement différent de la simple ajout d’une autre interface de bridge.
Un bridge se concentre principalement sur le fait de déplacer des actifs ou des représentations d’actifs entre réseaux.
Un système centré sur l’ordre vise à exécuter un trade à travers les réseaux.
Cette distinction peut devenir de plus en plus importante à mesure que le nombre d’écosystèmes blockchain, d’actifs et de lieux de liquidité continue de croître.
Conclusion finale
L’approche d’Omniston pour les swaps EVM-to-EVM repose sur une idée simple, avec une infrastructure sophistiquée en dessous.
Au lieu de traiter le trading inter-chaînes comme une séquence de transactions bridge et DEX sans lien, il traite l’opération comme un seul ordre inter-chaînes.
Les resolveurs se font concurrence via un modèle RFQ.
La liquidité destination est fournie là où le trader en a besoin.
Des HTLC jumelés établissent des conditions cryptographiques entre les réseaux participants.
Les hashlocks coordonnent les réclamations réussies.
Les timelocks fournissent un chemin vers des remboursements lorsque le règlement ne se termine pas.
Les exécutions partielles peuvent aider à couvrir des ordres plus importants.
Et surtout, le trade ne nécessite pas que TON agisse comme un actif ou un réseau intermédiaire pour une route EVM-to-EVM.
Le résultat est un système où le trader interagit avec un flux de swap unifié, tandis que plusieurs blockchains indépendantes coordonnent en dessous.
C’est la vraie valeur de l’infrastructure inter-chaînes : ne pas rendre les blockchains identiques, mais rendre leurs différences moins visibles pour l’utilisateur.
À mesure que la liquidité multi-chaînes devient de plus en plus fragmentée, des systèmes comme Omniston pourraient jouer un rôle important pour transformer cette fragmentation en une expérience de trading plus simple — où l’utilisateur se concentre sur l’actif qu’il veut échanger et l’actif qu’il veut recevoir, tandis que l’infrastructure sous-jacente gère la complexité liée au règlement du trade.
À retenir : Omniston combine une compétition de liquidité basée sur la RFQ avec un règlement inter-chaînes basé sur des HTLC, transformant un swap EVM-to-EVM d’un processus compliqué en plusieurs étapes en un ordre coordonné conçu pour s’exécuter ou se dénouer en toute sécurité selon des règles prédéfinies.
EXPLORE PLUS SUR STON.FI EVM-TO-EVM SWAP : https://app.ston.fi/swap?mode=cross-chain&in=bnb%3AUSDT&out=ethereum%3AUSDT
Faites-vous confiance à une architecture RFQ + HTLC pour de gros swaps inter-chaînes, ou préférez-vous encore des routes basées sur des bridges traditionnels ?