Pendant une grande partie de son histoire, STON.fi a surtout été compris comme un teneur de marché automatisé (AMM) et une bourse décentralisée sur TON.
Cette description reste exacte, mais ne reflète plus l’ensemble de l’architecture.
STON.fi fait désormais fonctionner Omniston en tant que couche distincte d’agrégation de liquidités et d’exécution inter-chaînes. Au lieu de s’appuyer sur un seul pool AMM, Omniston peut demander des devis à plusieurs sources de liquidité, comparer des parcours exécutables et coordonner le règlement. Sa nouvelle architecture inter-chaînes étend ce modèle au-delà de TON.
La distinction compte.
STON.fi est l’AMM et le DEX. Omniston est la couche de routage, d’agrégation et d’exécution qui peut se situer au-dessus de plusieurs sources de liquidité.
Comprendre cette séparation est important pour toute personne qui cherche à comprendre ce que STON.fi a réellement construit.
❑ D’une AMM vers une architecture d’exécution plus large
Un AMM, ou market maker automatisé, permet aux utilisateurs d’échanger contre des pools de liquidité plutôt que de correspondre directement avec un autre trader.
Dans un modèle d’AMM conventionnel, un utilisateur sélectionne une paire de tokens et le protocole calcule le taux d’échange à partir des actifs détenus dans le pool concerné.
Ce modèle fonctionne, mais il a une limite évidente : la liquidité est fragmentée.
Un trader peut trouver un prix sur STON.fi, un autre sur DeDust, et un autre chez un market maker. L’utilisateur ou l’application doit ensuite disposer d’un mécanisme pour déterminer quel itinéraire fournit l’exécution la plus appropriée.
C’est le problème qu’Omniston a été initialement conçu pour résoudre.
La documentation de STON.fi décrit Omniston comme un protocole d’agrégation de liquidité qui extrait de la liquidité de plusieurs sources et détermine des routes entre DEX et resolveurs. Le guide développeur montre des swaps impliquant STON.fi V1, STON.fi V2 et DeDust.
Cela signifie qu’Omniston ne doit pas être confondu avec un autre pool d’AMM.
C’est une couche d’agrégation.
❑ Le changement important a consisté à passer des pools aux cotations
Le mécanisme central derrière Omniston est un RFQ — Request for Quote (demande de cotation).
Au lieu de demander simplement à un pool un prix, une application peut demander des cotations aux sources de liquidité participantes.
La séquence de base est :
Demande → Cotation → Sélection → Exécution → Règlement
Les resolveurs sont des entités qui fournissent des cotations exécutables à Omniston. Plusieurs resolveurs peuvent être en concurrence pour une commande, puis une cotation est sélectionnée pour exécution.
Cela crée un modèle de liquidité différent de celui d’une AMM conventionnelle.
Une AMM engage de la liquidité dans un pool.
Un resolveur peut plutôt répondre à des commandes individuelles avec un prix et une proposition d’exécution.
Pour les utilisateurs, l’implication pratique est que la liquidité ne doit pas nécessairement provenir d’un seul pool, ni même d’un seul DEX.
❑ Pourquoi l’agrégation est importante sur TON
La fragmentation de la liquidité est un problème structurel dans les marchés décentralisés.
Si la liquidité est répartie entre plusieurs échanges, les applications ont deux choix.
Ils peuvent s’intégrer à chaque échange séparément, ou ils peuvent utiliser une couche d’agrégation qui gère ces connexions.
La documentation d’Omniston de STON.fi décrit la deuxième approche : une intégration unique peut interroger plusieurs sources de liquidité et router les trades via la source appropriée.
La documentation développeur fournit aussi un exemple dans lequel une application demande un RFQ et Omniston détermine un itinéraire à travers plusieurs DEX.
Cela est particulièrement pertinent pour des applications qui ne souhaitent pas maintenir des intégrations distinctes avec chaque DEX.
L’architecture change donc le rôle de STON.fi.
Au lieu de seulement demander :
Quel pool doit exécuter ce trade ?
l’application peut demander :
Quelle source de liquidité disponible peut fournir un itinéraire exécutable pour ce trade ?
C’est une couche d’abstraction substantiellement différente.
❑ Octobre 2025 : une transition importante
Omniston n’a pas toujours été le chemin d’exécution par défaut pour les utilisateurs de STON.fi.
En octobre 2025, STON.fi a annoncé que Omniston était passé d’une fonctionnalité optionnelle au système intelligent de routage par défaut dans son dApp.
L’annonce indiquait qu’Omniston fournirait de la liquidité à partir de plusieurs DEX et que le système avait déjà traité plus de 29 millions d’échanges et plus de 6,5 milliards de dollars de volume de transactions à ce moment-là.
C’est une distinction historique importante.
Omniston a commencé comme un mécanisme d’agrégation, mais son intégration dans l’interface de trading principale de STON.fi en a fait une partie du chemin d’exécution normal.
L’étape suivante a consisté à étendre la même architecture au-delà d’une seule blockchain.
❑ L’exécution cross-chain modifie le problème
Déplacer des tokens entre blockchains introduit une couche de complexité supplémentaire.
Un flux de travail cross-chain conventionnel implique souvent un pont ou une infrastructure d’intermédiation qui transfère de la valeur entre les réseaux.
Omniston adopte une approche différente.
Son architecture actuelle utilise des resolveurs et des HTLC liés — Hash Time-Locked Contracts — pour coordonner les deux côtés d’une transaction cross-chain.
L’architecture actuelle de STON.fi décrit le flux comme suit :
1. Un utilisateur demande un échange cross-chain.
2. Omniston envoie une RFQ aux resolveurs.
3. Les resolveurs renvoient des cotations exécutables.
4. La liquidité sélectionnée est verrouillée dans des contrats HTLC liés.
5. La transaction se règle soit de manière atomique, soit les parties sont remboursées.
Le concept important ici est que la liquidité de destination est fournie par le resolveur.
STON.fi décrit les resolveurs comme fournissant de la liquidité côté destination pour des commandes individuelles plutôt que d’exiger qu’une application conserve des soldes pré-alimentés sur chaque réseau pris en charge.
❑ Les HTLC sont ce qui relie les deux côtés
HTLC signifie Hash Time-Locked Contract (contrat à hash et verrouillage temporel).
Le mécanisme combine deux conditions.
Un hashlock nécessite de connaître un secret avant de pouvoir réclamer les fonds.
Un timelock fixe une date limite après laquelle la transaction peut être annulée et les fonds retournés.
Dans un swap atomique cross-chain, ces conditions peuvent relier les transactions côté source et côté destination.
Le résultat visé est simple :
Soit le swap se termine conformément aux conditions convenues, soit les fonds peuvent être retournés.
La description actuelle d’Omniston par STON.fi indique explicitement que des contrats HTLC liés sont utilisés entre les chaînes et que le swap se règle de manière atomique, ou que les participants sont remboursés.
Cela ne signifie pas que l’architecture est sans risque.
La sécurité d’un tel système dépend encore de la justesse des contrats, des chaînes participantes, de l’implémentation du resolveur et des conditions d’exécution.
Le point pertinent est plus étroit : la conception cross-chain d’Omniston cherche à coordonner des swaps d’actifs natifs par règlement atomique, plutôt que de dépendre d’un modèle classique de pont pour actifs « enveloppés ».
❑ Omniston n’élimine pas le rôle des fournisseurs de liquidité
Cela change d’où peut provenir la liquidité.
Pour une AMM traditionnelle, les fournisseurs de liquidité déposent des actifs dans des pools et reçoivent des jetons LP représentant leur position.
Avec le modèle de resolveurs d’Omniston, un resolveur répond aux RFQ et, pour les transactions cross-chain, fournit la liquidité côté destination nécessaire pour exécuter une commande.
STON.fi indique que les resolveurs rivalisent sur les prix et l’exécution, le resolveur gagnant fournissant la liquidité de destination requise.
Cela crée une structure de marché dans laquelle les fournisseurs de liquidité peuvent rivaliser pour le flux d’ordres.
Le resolveur n’est donc pas simplement une autre API back-end.
C’est un participant à l’exécution.
❑ Le modèle de resolveur introduit une nouvelle couche de confiance et d’infrastructure
Les resolveurs doivent interagir avec l’infrastructure technique d’Omniston et répondre aux demandes de cotation.
La documentation de STON.fi décrit un resolveur comme une entité qui fournit des cotations et exécute des transactions via le protocole d’agrégation.
Cela crée plusieurs dépendances qui valent la peine d’être reconnues.
Le système dépend de :
des cotations exactes ;
infrastructure de resolveur fonctionnelle ;
contrats de règlement ;
exécution blockchain ;
Deadlines des RFQ ;
comportement HTLC correct ;
et une liquidité de resolveur suffisante.
L’architecture déplace donc une partie de la complexité hors de l’utilisateur et du développeur d’application, mais cette complexité ne disparaît pas.
Elle passe dans la couche d’exécution.
❑ La prise en charge cross-chain s’est étendue au-delà de TON
Le site web actuel d’Omniston liste TON, TRON, Ethereum, Base, BNB Chain, Polygon, Arbitrum, Avalanche et Robinhood Chain comme réseaux actifs.
Il y a une divergence importante dans la documentation qui mérite d’être notée.
Certaines anciennes documentations d’Omniston décrivent encore TRON comme à venir, tandis que la page produit actuelle liste TRON comme actif.
Plutôt que de considérer l’ancienne documentation comme une référence définitive, l’interprétation la plus sûre est que la documentation et le déploiement en production ont été mis à jour à des moments différents.
Pour la disponibilité réelle, l’infrastructure RFQ en temps réel est la source opérationnelle la plus pertinente.
C’est aussi pour cela que les listes de chaînes prises en charge doivent être considérées comme sensibles au temps plutôt que comme des spécifications de protocole permanentes.
❑ L’architecture est aussi conçue pour les développeurs
Omniston n’a pas vocation à être utilisé uniquement via l’interface STON.fi.
STON.fi fournit des outils développeur aux applications qui souhaitent intégrer le système.
La documentation inclut une intégration basée sur le SDK pour demander des cotations, construire des transactions et suivre les échanges. Le guide actuel montre une intégration avec React et la connectivité du wallet TON, tandis que la plateforme Omniston fournit un SDK, une API/RFQ et une infrastructure de widget.
Cette distinction est significative.
Si Omniston n’était qu’une fonctionnalité à l’intérieur de l’application STON.fi, son rôle architectural serait relativement limité.
En exposant l’infrastructure d’exécution à d’autres applications, STON.fi cherche à faire d’Omniston une couche réutilisable de liquidité et d’exécution.
L’architecture est donc mieux comprise comme une infrastructure plutôt que comme une simple fonctionnalité front-end de trading.
❑ Les frais font partie du modèle d’exécution
La page produit actuelle d’Omniston décrit deux composantes de frais :
des frais de protocole déterminés par paire d’actifs ;
des frais d’intégrateur configurés par l’application via Omniston.
La plage de frais d’intégrateur annoncée est de 0,01 à 100 points de base, les frais étant collectés dans l’actif de destination et appliqués au niveau du smart contract.
Un point de base correspond à un centième de point de pourcentage.
Donc :
1 point de base = 0,01%
10 points de base = 0,10%
100 points de base = 1%
L’existence de frais configurables signifie qu’Omniston n’est pas simplement une API de routage ouverte sans couche économique.
Il existe un modèle d’exécution dans lequel les intégrateurs peuvent intégrer leurs propres frais dans la transaction cotée.
❑ La question de l’échelle nécessite une interprétation attentive
À l’heure actuelle, STON.fi présente Omniston comme alimentant chaque swap sur STON.fi et décrit le système comme traitant des dizaines de millions de swaps et des milliards de dollars de volume.
Cependant, il existe une limitation analytique importante.
Les données publiques ne isolent pas proprement le volume propre à Omniston du volume historique du DEX STON.fi sous-jacent.
Ceci compte, car Omniston est devenu le mécanisme de routage par défaut uniquement après son intégration dans le dApp de STON.fi.
À l’heure actuelle, DefiLlama rapporte STON.fi comme une AMM basée sur TON avec environ 27,15 millions de dollars de TVL et 104,21 millions de dollars de volume DEX sur 30 jours au moment de la dernière capture récupérée. Il indique également environ 8,50 milliards de dollars de volume DEX cumulé.
Ces chiffres décrivent le protocole STON.fi selon la méthodologie de DefiLlama.
Elles ne doivent pas être présentées comme des statistiques indépendamment vérifiées propres à Omniston.
Cette distinction est importante pour évaluer l’échelle de la couche d’exécution.
❑ Il existe des preuves de sécurité, mais elles ont des limites
Les affirmations de sécurité doivent aussi être séparées par périmètre.
Les contrats plus larges de STON.fi (AMM v2) ont été revus par Trail of Bits en janvier 2025.
Par ailleurs, STON.fi a annoncé que ses contrats d’escrow Omniston ont fait l’objet d’un audit par TonTech en août 2025.
Ce sont des signaux de sécurité utiles, mais un audit ne revient pas à prouver qu’un protocole est sûr.
Un audit représente un examen du code et du périmètre spécifiés à un moment donné.
L’architecture cross-chain introduit également plusieurs composants et réseaux, ce qui signifie que la question de sécurité dépasse un simple smart contract.
Pour cette raison, la conclusion appropriée est qu’Omniston a fait l’objet d’un examen de sécurité documenté des composants pertinents, tandis que l’existence d’un audit ne doit pas être interprétée comme une garantie contre des vulnérabilités futures.
❑ Ce qu’Omniston change pour STON.fi
L’évolution peut être vue en trois étapes.
1. AMM
STON.fi fournit des pools de liquidité et une infrastructure de market-making automatisé sur TON.
2. Agrégateur
Omniston connecte plusieurs sources de liquidité et utilise des RFQ pour déterminer des itinéraires exécutables.
3. Couche d’exécution cross-chain
La nouvelle architecture étend l’exécution basée sur RFQ au-delà de TON et coordonne la liquidité côté source et côté destination via des mécanismes de règlement atomique.
Cette progression modifie le périmètre de l’infrastructure.
L’AMM est principalement un lieu de liquidité.
Omniston est un coordinateur d’exécution.
Les deux systèmes sont liés, mais ne sont pas interchangeables.
❑ Les questions sans réponse sont aussi importantes que l’architecture
Plusieurs détails restent difficiles à vérifier à partir de documents accessibles publiquement.
Le nombre exact de resolveurs actifs n’est pas clairement divulgué dans la documentation publique actuelle.
La liste complète des sources de liquidité DEX agrégées à un instant donné n’est pas non plus présentée comme une liste publique permanente.
Les paramètres exacts de timeout HTLC peuvent dépendre du flux d’exécution plutôt que d’être représentés par un seul nombre universel.
Et les données publiquement disponibles ne fournissent pas un tableau de bord propre et indépendant montrant le volume propre à Omniston pour chaque application et chaîne intégrées.
Il ne s’agit pas nécessairement de défauts dans l’architecture.
Ce ne sont que des limitations sur ce qui peut actuellement être établi à partir de preuves publiques.
Une évaluation basée sur la recherche devrait préserver ces distinctions plutôt que de les combler avec des hypothèses.
❑ Où se situe Omniston dans l’architecture plus large de STON.fi
Le moyen le plus simple de comprendre le système est de séparer ses composants.
AMM STON.fi :
Fournit du market-making automatisé et des pools de liquidité sur TON.
Omniston :
Agrège la liquidité et demande des cotations exécutables.
Resolveurs :
Fournir des cotations et, pour l’exécution cross-chain, de la liquidité côté destination.
Règlement HTLC :
Coordonne les côtés source et destination des transactions cross-chain prises en charge.
SDK/API :
Permet aux applications externes d’intégrer l’infrastructure d’exécution.
Ensemble, ces composants représentent un passage d’un seul exchange décentralisé vers une architecture plus large d’acheminement de liquidité et d’exécution.
Le fait que cette architecture devienne finalement largement utilisée dans l’ensemble des applications et des chaînes est une question d’adoption qui ne peut pas être tranchée simplement à partir de l’existence de la technologie.
Ce qui peut être établi aujourd’hui est plus précis :
Omniston a évolué d’une agrégation de liquidité centrée sur TON vers une infrastructure d’exécution cross-chain que STON.fi utilise pour ses propres swaps et qu’elle met à disposition pour des intégrations externes.
C’est la description la plus précise de ce qu’est le système.
❑ Références
Sources officielles
STON.fi — Omniston
https://ston.fi/omniston
Documentation STON.fi — Vue d’ensemble Omniston
https://docs.ston.fi/developer-section/omniston/overview
Documentation STON.fi — Resolveurs Omniston
https://docs.ston.fi/developer-section/omniston/resolvers
Documentation STON.fi — Guide développeur Omniston
https://docs.ston.fi/developer-section/quickstart/omniston
GitHub STON.fi — SDK Omniston
https://github.com/ston-fi/omniston-sdk
Blog STON.fi — Omniston alimente désormais chaque swap sur STON.fi https://blog.ston.fi/omniston-now-powers-every-swap-on-ston-fi/
STONfi x
https://x.com/ston_fi
Recherche & Analyses
DefiLlama — Métriques STON.fi
https://defillama.com/protocol/ston.fi
Trail of Bits — Revue de sécurité STON.fi TON AMM DEX v2 https://github.com/trailofbits/publications/blob/master/reviews/2025-01-stonfi-ton-amm-dex-v2-securityreview.pdf
HackenProof
— Bounty Bug des contrats intelligents DEX STON.fi v2 https://hackenproof.com/programs/ston-dot-fi-dex-smart-contracts-v2
CertiK — Profil de sécurité STON.fi https://skynet.certik.com/projects/ston-fi
Sources Communauté & Programme
STONbassadors — Programme officiel https://ston.fi/stonbassadors
Lignes directrices STONbassadors https://ambassadors.ston.fi/
Rédigé par Binnoreen
X : https://x.com/Bin_noreen
Telegram https://t.me/binnoreen