Uniswap : De zéro à l'infini
TechFlow SélectionTechFlow Sélection
Uniswap : De zéro à l'infini
Uniswap continue de repousser les limites pour résoudre ces problèmes et améliorer l'expérience utilisateur.
Dédié à des analyses Web3 approfondiesRédaction : Luke, investisseur et chercheur chez SevenX Ventures
Remerciements particuliers à Alex de Maru Network, Brad d'Uniswap Labs, Dong Mo de CelerNetwork, Shumo de Manta Network et Suning de Hyperoracle pour leurs précieuses discussions, analyses et retours sur ce document.
Introduction
Sans conteste, Uniswap est l'application décentralisée la plus utilisée. Fidèle à son esprit innovant, elle repousse constamment les limites et redéfinit les standards du secteur. Ce document explore en profondeur le parcours remarquable d'Uniswap, passant du zéro à l'infini. En analysant chaque version d'Uniswap, nous montrons comment elle a su faire face efficacement aux nouveaux défis et s'adapter aux besoins changeants. Nous examinons également comment les avancées récentes en cryptographie façonnent l'avenir des échanges décentralisés (DEX). Préparez-vous à embarquer dans un voyage allant du zéro à l'infini.
v0 : Preuve de concept
Avant Uniswap, EtherDelta était le seul DEX notable. Pourtant, l'expérience utilisateur était très médiocre.
De nombreux leaders du secteur (Alan Lu de Gnosis et Vitalik) ont proposé le concept de market-making automatisé (AMM), offrant une alternative à la structure traditionnelle basée sur le carnet d'ordres, pour faciliter les échanges sur chaîne.
Caractéristiques
AMM à produit constant
Uniswap utilise la formule du produit constant (x * y = k) pour calculer le prix des actifs. Ici, x représente les réserves du jeton échangé, et y celles du jeton de référence. Lorsqu'un jeton est retiré (achat), une quantité proportionnelle doit être déposée (vente) afin de maintenir k constant. Le prix du jeton est déterminé par le ratio entre les réserves.
Source : Uniswap
Il convient de noter que d'autres AMM utilisent différentes formules mathématiques pour représenter la courbe de liquidité. Par exemple, Stableswap de Curve ou les pools pondérés de Balancer.
Problèmes
Uniswap v0 est essentiellement une preuve de concept, laissant plusieurs problèmes non résolus. Les deux principaux sont :
1. Ne supporte que les paires ETH/ERC20.
2. Limité à un seul fournisseur de liquidité (LP).
v1 : DEX fonctionnel
Caractéristiques
Le 2 novembre 2018, Uniswap v1 a été lancé sur le réseau principal d'Ethereum. Cette version permet à plusieurs fournisseurs de liquidité d'utiliser des jetons internes pour suivre les frais et les collatéraux. Grâce à un contrat usine, n'importe qui peut ajouter un jeton ERC20 pour échanger contre ETH natif. Ce système fournit un DEX pleinement fonctionnel. Toutefois, certains problèmes subsistent.
Problèmes
Comme tous les jetons sont appariés avec ETH, les utilisateurs peuvent facilement échanger un jeton ERC20 contre un autre via ETH comme intermédiaire en une seule transaction. Toutefois, cette méthode présente un inconvénient : lorsqu'on échange fréquemment entre stablecoins comme DAI/USDT, passer par ETH devient inefficace. Dans ces cas, un appariement direct est préférable.
v2 : Lego Financier (Money Lego)
En mai 2020, Uniswap v2 a été lancé, apportant plusieurs améliorations au protocole, augmentant la flexibilité et l'accessibilité des échanges.
Caractéristiques
Paires ERC20/ERC20
La différence majeure d'Uniswap V2 est qu'il permet désormais d'ajouter des pools de liquidité entre deux jetons ERC20, plutôt que seulement entre un jeton ERC20 et ETH. Cela rend le système plus pratique pour les fournisseurs de liquidité, qui peuvent maintenant maintenir des positions diversifiées en jetons ERC20, notamment pour les paires de stablecoins.
Oracle de prix
Uniswap v2 fournit des informations de prix fiables sur chaîne, utilisables par de nombreuses applications DeFi. Ces données sont difficiles à manipuler, ce qui leur confère une grande valeur. Le mécanisme ajoute le prix à la fin de chaque bloc à une variable cumulative dans le contrat principal, pondérée par la durée de stabilité du prix. Cette variable représente essentiellement la somme des prix Uniswap par seconde depuis l’historique complet du contrat.
Source : Uniswap
Les contrats externes peuvent utiliser cette variable pour calculer précisément le prix moyen pondéré dans le temps (TWAP) sur n'importe quel intervalle. En lisant la valeur cumulative au début et à la fin de l'intervalle, puis en divisant la différence par la durée, on obtient le TWAP.
Source : Uniswap
Flash Swaps
Uniswap v2 introduit aussi les flash swaps, inspirés des flash loans popularisées par Aave. Cette fonction permet à tout utilisateur de retirer autant de jetons ERC20 qu’il souhaite d’un pool, sans garantie ni coût initial, à condition de rembourser la même valeur (plus les frais) avant la fin de la transaction.
Les flash loans ont mauvaise presse car souvent associées à des attaques contre des protocoles DeFi. Mais le vrai problème ne réside pas dans les flash loans elles-mêmes, mais dans les vulnérabilités existantes des protocoles. L'atomicité des flash loans supprime le besoin de capital initial pour des opérations comme l'arbitrage inter-pools ou l'utilisation de levier.
Problèmes
Bien que cet AMM soit innovant et favorise la création de nouveaux marchés, il souffre encore d'inefficacités. Par exemple, pour les jetons à faible volatilité, la liquidité n'est nécessaire que sur une plage de prix restreinte. Or, la conception actuelle répartit uniformément la liquidité sur toute la courbe.
v3 : Efficacité du capital
Uniswap v3 adopte une conception innovante de liquidité concentrée, visant à devenir l'AMM le plus flexible et le plus efficace.
Caractéristiques
Liquidité Concentrée (CL)
Dans Uniswap v2, la liquidité est uniformément répartie selon la courbe x*y=k, couvrant toute la plage de prix de zéro à l’infini. Pourtant, dans la plupart des pools, celle-ci reste sous-utilisée.
Dans Uniswap v3, les fournisseurs de liquidité peuvent concentrer leur capital sur une plage de prix spécifique, obtenant ainsi une liquidité accrue autour du prix attendu. Grâce à cette personnalisation, ils peuvent créer une courbe de prix adaptée à leurs préférences. Ces positions individuelles sont ensuite agrégées en un seul pool, formant une courbe unifiée utilisée par les traders. Résultat : un bénéfice mutuel — les traders bénéficient de moins de glissement, et les LP gagnent davantage de frais.
La liquidité concentrée est particulièrement utile pour les paires de stablecoins ou de jetons de mise en jeu liquides, dont le prix varie peu. En revanche, pour les paires volatiles, elle exige des techniques avancées de gestion de liquidité. Pour les petits LP, cela peut s’avérer difficile à gérer efficacement.
Ordres à plage
Grâce à la liquidité concentrée, v3 introduit un nouveau type d’ordre appelé « ordre à plage », complémentaire aux ordres au marché. Un LP peut déposer un seul jeton dans une plage définie (au-dessus ou en dessous du prix actuel). Si le prix entre dans cette plage, l’actif est vendu progressivement contre l’autre, tout en générant des frais.
Ce mécanisme ressemble à un « ordre limite », mais avec une particularité : il est réversible — si le prix rebrousse chemin, l’ordre fait de même. Néanmoins, des frais continuent d’être perçus pendant l’exécution. Barry Fried (@BarryFried1) propose dans son post un exemple détaillé d’utilisation des ordres à plage.
Plusieurs niveaux de frais
Uniswap v3 abandonne le modèle à frais fixes, introduisant trois niveaux distincts par paire : 0,05 %, 0,30 % et 1,00 %. Cela permet aux LP d’être mieux rémunérés selon le risque pris.
Oracles avancés
Uniswap v3 améliore considérablement ses oracles de prix. Au lieu d’une seule variable cumulative, il stocke un ensemble de variables, permettant de construire plus facilement et à moindre coût des oracles sophistiqués — moyennes mobiles simples (SMA), exponentielles (EMA), filtrage des valeurs aberrantes, etc.
Problèmes
Manque de flexibilité
Malgré la souplesse offerte par la liquidité concentrée et les niveaux de frais, Uniswap v3 peine à s’adapter aux innovations rapides des AMM et des marchés. Intégrer des fonctionnalités comme les ordres TWAP, les ordres limites, les oracles avancés ou les frais dynamiques nécessite une refonte complète du protocole central.
Certaines fonctions (comme l’oracle de prix introduit initialement dans v2) ont permis d’utiliser des données de prix décentralisées, mais au prix d’une hausse des coûts en gaz pour les traders, et d’un manque d'options personnalisables pour les intégrateurs.
Gestion complexe de la liquidité
Comme mentionné, la gestion de la liquidité concentrée est ardue pour les nouveaux LP, surtout sur les paires volatiles. Bien que plusieurs protocoles d’automatisation existent, leurs stratégies de rééquilibrage sont souvent trop simples, conçues pour des actifs corrélés. Malheureusement, elles échouent souvent sur les paires volatiles, où les longs blocs, les frais élevés et les coûts de couverture limitent leur efficacité.
De plus, comme chaque position CL est unique, les jetons LP deviennent intrinsèquement non fongibles. Ils doivent donc être représentés par des jetons non fongibles (NFT), ce qui pose problème aux autres protocoles DeFi souhaitant les intégrer.
De nombreux projets excellents explorent des solutions variées (rééquilibrage, couverture dynamique, contrats perpétuels, options). Atis Elsts (@atiselsts_eth) a publié une série d’articles très complets sur les stratégies LP, fortement recommandés.
Fuite de valeur
Parmi tous les problèmes, la fuite de valeur est le plus critique. Elle n’est pas exclusive à Uniswap v3, mais s’est aggravée avec l’augmentation du volume et de l’adoption des AMM. Elle se manifeste principalement par :
- Des slippages excessifs dus aux sandwich attacks et front-running.
- Des pertes de valeur pour les LP via l’arbitrage CEX-DEX (aussi appelées pertes relatives).
Pour résoudre ces problèmes, nous avons besoin d’un DEX plus expressif et puissant que v3, doté de fonctionnalités personnalisables et de conceptions complexes.
v4 : La plateforme ultime
Uniswap v4 s’appuie sur les modèles AMM des versions précédentes, et introduit des « hooks » pour devenir la plateforme DEX ultime, efficace et hautement personnalisable.
Efficacité
Singleton
Dans Uniswap v3, chaque pool est créé comme un contrat séparé via un contrat usine. Dans v4, tous les pools coexistent dans un seul contrat intelligent (appelé singleton). Cette architecture réduit considérablement les coûts liés à la création de pools et aux transactions multi-sauts.
Comptabilité Flash (Flash Accounting)
Le modèle singleton utilise la comptabilité flash pour optimiser les transferts d’actifs. Contrairement à v3 où les actifs entrent et sortent après chaque swap, v4 ne transfère que les soldes nets, réduisant drastiquement les coûts. Grâce au stockage transitoire (proposé dans l’EIP-1153), le coût de configuration et de suppression des slots de stockage est moindre, ce qui est essentiel pour le bon fonctionnement de la comptabilité flash.
Source : Uniswap
ETH natif
Uniswap v4 réintroduit le support de l’ETH natif, offrant plusieurs avantages : coûts en gaz réduits, transferts simplifiés et suppression des frais d’enveloppement.
Personnalisation
Hooks
Les contrats hooks (ou hooks) sont des contrats externes déployés qui exécutent une logique prédéfinie à des moments spécifiques du cycle d’un pool. C’est ce qui rend v4 si expressif et personnalisable. Grâce aux hooks, on peut implémenter des fonctionnalités auparavant intégrées au protocole (comme les oracles), ou des nouveautés nécessitant auparavant un protocole indépendant.
Uniswap v4 prend actuellement en charge huit callbacks de hook :
-
beforeInitialize/afterInitialize
-
beforeModifyPosition/afterModifyPosition
-
beforeSwap/afterSwap
-
beforeDonate/afterDonate
L’image ci-dessous illustre le flux logique d’un hook de swap. Un indicateur booléen dédié permet d’exécuter du code personnalisé avant et après l’échange. Cela constitue la base pour développer des fonctionnalités avancées comme les oracles, les systèmes de frais dynamiques, les enchères ou des types d’ordres complexes. Nous explorerons ces concepts plus en détail plus tard.
Flux d’un hook de swap
Oracles
Dans les versions précédentes, les oracles étaient intégrés au cœur d'Uniswap. Bien que cela facilite l’intégration, cela réduit la personnalisation et augmente les coûts pour les swappers. Avec les hooks, les possibilités de conception d’oracles s’élargissent grandement. On peut maintenant créer des oracles résistants à la manipulation, comme les oracles à moyenne tronquée ou volatilité. De plus, on peut choisir qui paie les frais de mise à jour — par exemple, un contrat hook avec solde ETH, plutôt que de laisser le premier swapper supporter ce coût (peu durable). Malgré ces optimisations, les oracles restent un défi — les oracles TWAP peuvent être manipulés ou retardés par rapport au prix réel.
Uniswap Labs a proposé un oracle de prix intéressant : l’oracle tronqué. Il calcule le prix géométrique moyen dans le pool, en limitant les variations de prix par bloc. En tronquant les extrêmes, cet oracle renforce la résistance aux manipulations et atténue l’impact des gros échanges.
Frais dynamiques
Bien que v3 ait ajouté des niveaux de frais, ceux-ci restent statiques, ignorant les conditions du marché. Ainsi, les LP ne sont pas suffisamment compensés.
Alex Nezlobin (@0x94305) a proposé un système simple et efficace de frais dynamiques, tenant compte de l’impact de prix du bloc précédent, appliquant des taux différents aux acheteurs et vendeurs. Comme illustré ci-dessous : lorsque le prix CEX atteint p*, supérieur au prix AMM p_AMM, les frais de vente diminuent de δ, tandis que ceux d’achat augmentent de δ. La valeur de δ est proportionnelle au changement de prix AMM. L’objectif est de distinguer les flux d’arbitrage des flux ordinaires, sachant que les premiers sont plus auto-corrélés.
Concevoir un système robuste de frais dynamiques soulève plusieurs défis. Intégrer des signaux hors chaîne (prix CEX, profondeur de liquidité, volatilité) en est un. Aussi, les signaux chaîne (adresse, taille, horodatage) peuvent être peu fiables pour distinguer les flux informés des autres. Enfin, il est crucial de garantir que les frais ne descendent jamais en dessous de zéro pour protéger les LP.
Enchères
Les hooks permettent aussi de mettre en œuvre des enchères, redistribuant de la valeur aux LP. Selon le moment, on distingue enchères ex ante et ex post.
Les enchères ex ante ont lieu avant le bloc. Ce concept a été introduit dans un article de recherche sur les AMM capturant le MEV (McAMM). Avant qu’un bloc soit validé, on met aux enchères le droit d’effectuer le premier swap dans l’AMM, puis on redistribue les gains. Mais ce processus comporte des difficultés : il implique une tarification d’options, complexe. De plus, le validateur peut rejeter la transaction, posant des problèmes de censure. Assurer une redistribution équitable et efficace des gains est également délicat. Enfin, rien ne garantit que le gagnant sera le premier à exécuter son swap, détériorant potentiellement l’expérience des autres traders.
Les enchères ex post ont lieu après la réalisation de la volatilité — le prix CEX a changé, mais le bloc suivant n’est pas encore validé. Elles sont plus efficaces, mais reposent sur une infrastructure hors chaîne, soit centralisée (« trusted party »), soit décentralisée (trustless). Avec un tiers de confiance, surgissent des questions de censure et de confidentialité. Concevoir un système trustless est bien plus complexe. De plus, le validateur pourrait manipuler l’enchère, par exemple en excluant des trades d’arbitrage. En outre, il existe un délai critique entre la soumission de l’offre, la validation du consensus et la distribution aux bâtisseurs de blocs — tout cela devant se faire avant la finalisation du bloc suivant. Enfin, il peut être difficile d’assurer une concurrence suffisante pour capter assez de valeur. Sorella Labs (@SorellaLabs) joue un rôle de leader grâce à son infrastructure avancée et sa conception de mécanismes.
Hook Diamond
Le protocole Diamond a été conçu comme un AMM minimisant le LVR. Sous Diamond, le validateur organise une enchère pour capter l’opportunité d’arbitrage entre le prix externe du pool et son propre prix. Les revenus sont partagés entre le pool Diamond et le validateur, de manière compatible avec les incitations.
Comme discuté ici, une variante de Diamond inclut un pool de collatéral pour maintenir le prix de fin de bloc selon un prix promis. Le swap n’est exécuté que si suffisamment de collatéral est disponible pour ramener le prix à la valeur promise. Arrakis (@ArrakisFinance) collabore actuellement avec Conor McMenamin (@ConorMcMenamin9), co-auteur de Diamond, pour implémenter cela via les hooks de v4.
Types d’ordres avancés
Les hooks permettent aussi des types d’ordres plus avancés, améliorant grandement l’expérience des traders. Parmi eux : ordres limites, stop-loss, take-profit, TWAP.
Ordres limites
Les traders peuvent soumettre des ordres limites chaîne via un contrat hook. L’ordre s’exécute quand le prix atteint le niveau défini. Toutefois, comparés aux ordres limites traditionnels, ces ordres chaîne ont un inconvénient majeur : ils ne peuvent être annulés sans frais de gaz. Cela crée un problème de ratio ordres/exécutions élevé.
Market Maker Pondéré dans le Temps (TWAMM)
Une solution envisageable est d’implémenter un TWAMM pour exécuter de gros ordres. Cette approche fractionne la commande en petits lots, exécutés en priorité, évitant ainsi les sandwich attacks. On pourrait aussi réduire les frais pour les ordres TWAP, généralement associés à des flux non informés. Mais cela pose le défi des coûts en gaz élevés, et de savoir qui doit les assumer.
Autres hooks
D’autres fonctionnalités peuvent être réalisées via des hooks. Voici quelques idées :
-
Un hook générant des rendements, prêtant la liquidité hors plage aux marchés monétaires pour améliorer l’efficacité du capital.
-
Un pool combinant courbe xy=k et liquidité concentrée.
-
Un pool facturant des frais de retrait aux LP, pour limiter les attaques de liquidité immédiate.
Suning (@msfew_eth) partage sur Github des idées créatives sur les hooks. Aiden (@aiden0x4) a également publié un excellent répertoire ouvert des hooks.
zkAMM et zkHooks
Les coprocesseurs ZK permettent aux contrats intelligents d’accéder à des analyses de données riches (comme Dune Analytics), sans compromettre la confiance grâce aux preuves zero-knowledge. Leur application aux AMM est un domaine de recherche émergent. Grâce aux hooks, l’intégration fluide de ZK dans Uniswap v4 devient possible, inaugurant l’ère des zkAMM.
HyperOracle (@HyperOracle) a démontré une implémentation zkAMM basée sur Uniswap v2, où le calcul d’addLiquidity est déplacé hors chaîne. Quand un utilisateur ajoute de la liquidité, des calculs sont nécessaires (quantités, prix, parts LP). Ici, le zkGraph d’HyperOracle capture l’événement, effectue les calculs, génère une preuve et la publie. Le zkAMM intègre alors une couche automatisée pour vérifier la preuve et frapper les jetons LP.
Diego (@0xfuturistic) présente une implémentation de zkAMM (zkUniswap) basée sur v3, où une partie des calculs de swap est déportée vers le zkVM de Risc Zero (@RiscZero). À chaque swap, plusieurs paramètres sont calculés (montant, frais, prix post-swap). Initialement exécutés en Solidity via l’EVM, ces calculs sont désormais faits hors chaîne par un relais, qui publie les résultats et la preuve. Le contrat AMM valide la preuve et règle l’échange. zkUniswap implémente un mécanisme d’enchère verrouillée pour le contrôle concurrentiel. Bien que la performance actuelle égale celle de l’EVM, la parallélisation par lots pourrait fortement améliorer l’efficacité.
La preuve de volume est un autre cas d’usage. Brevis (@brevis_zk) propose un exemple intéressant : un hook de remise basé sur le volume historique, similaire aux remises CEX. Les VIP peuvent calculer hors chaîne leur volume mensuel, puis soumettre une preuve ZK à faible coût pour valider asynchrone leur statut. Une fois vérifié, leurs futurs swaps peuvent accéder via un hook « après swap » à une « table de frais VIP » alimentée par un coprocesseur ZK, appliquant automatiquement la remise adéquate. Maru Network (@marunetwork) développe actuellement un oracle de volume décentralisé comme cas d’usage initial de son réseau de coprocesseurs ZK. Grâce à cet oracle, les DEX pourront distribuer des récompenses de manière équitable et transparente, incitant proportionnellement la liquidité et l’activité, créant un effet vertueux. En utilisant des services d’agrégation de preuves ZK comme NEBRA (@nebrazkp) UPA (Universal Proof Aggregation), les coûts de vérification peuvent être réduits, en regroupant plusieurs preuves en une seule, amortissant les frais.
En résumé, le concept de zkAMM consiste à déporter des calculs de l’EVM vers des coprocesseurs ZK ou oracles ZK, puis à valider les preuves sur chaîne. Ces calculs peuvent être bien plus complexes que les swaps ou ajustements de liquidité — par exemple, calculer des frais dynamiques selon la volatilité récente, prouver le nombre historique d’utilisateurs dans un pool, ou appliquer des stratégies de rééquilibrage basées sur du machine learning. Les possibilités sont infinies, car toute computation aboutit à un coût de vérification O(1), libéré des limites de calcul de l’EVM.
Défis de v4
Uniswap v4 étend considérablement l’espace de conception des AMM, permettant des pools aux caractéristiques et fonctionnalités variées. C’est un progrès majeur, mais au prix d’une fragmentation accrue de la liquidité due à la prolifération des pools, rendant le routage plus complexe.
UniswapX
UniswapX vise à résoudre la fragmentation en externalisant la complexité du routage vers un réseau ouvert de remplisseurs (fillers). Ces derniers rivalisent pour exécuter les swaps en utilisant des liquidités chaîne (pools AMM ou stocks privés). Ce modèle centré sur l’objectif permet à l’utilisateur de simplement déclarer son but, laissant des professionnels s’occuper du reste.
Ces remplisseurs sont des agents avancés dotés d’algorithmes de routage sophistiqués, d’une puissance de calcul élevée et de capitaux importants. Ils s’affrontent dans un mécanisme d’enchères pour offrir la meilleure exécution. Les utilisateurs bénéficient d’une optimisation des prix, garantissant une exécution au moins aussi bonne que via un pool AMM direct.
L’architecture du protocole UniswapX est illustrée ci-dessous. Le trader soumet son intention via l’API Uniswap, sous forme de signature hors chaîne exécutable par Permit2. Permit2 est un modèle bien conçu assurant la sécurité des transferts. Les remplisseurs conçoivent des stratégies pour honorer ces ordres, utilisant toute source de liquidité disponible, chaîne ou hors chaîne. Enfin, l’Order Reactor traite les ordres UniswapX : il vérifie le type d’ordre, le décompose en entrées/sorties, exécute selon la stratégie du filler, et confirme la réussite.
Source : Uniswap
Actuellement, dans l’implémentation d’Uniswap Labs, le protocole se divise en deux phases. La première est la phase RFQ : des « quoteurs » sur liste blanche répondent avec des offres. Le gagnant bénéficie d’une période exclusive pour remplir l’ordre. En cas d’échec, on passe à la phase 2 — une enchère hollandaise ouverte à tous les remplisseurs. À l’avenir, le système d’offres deviendra totalement sans permission.
Source : Présentation de Hayden Adams à EthCC sur « Trading on-chain »
Ce design centré sur l’objectif offre plusieurs avantages :
-
Agrège les sources de liquidité pour des prix optimaux.
-
Ne nécessite aucun jeton gaz, même pour les swaps inter-chaînes.
-
Internalise la valeur maximale extractible via l’optimisation des prix.
-
Aucun frais en cas d’échec de transaction.
Défis
-
Rendre le système d’offres sans permission, par exemple via un système de réputation efficace.
-
Attirer davantage de remplisseurs pour assurer un environnement compétitif et ouvert.
Futur : Le jeu infini
L’évolution des DEX ne s’arrête pas là. Pour une adoption massive de la crypto, plusieurs défis restent à relever. Markus Schmitt (@_haikane_) de PropellerHeads (@PropellerSwap), en collaboration avec Frontier Research (@FrontierDotTech), a publié un excellent article détaillant les composantes d’un bon DEX et les problèmes persistants. Selon cet article, un excellent exchange devrait offrir :
-
Confiance : transparence avant, pendant et après l’échange, et minimisation du risque de garde.
-
Meilleur prix : proposer constamment le meilleur prix ou des prix compétitifs.
-
Équité : empêcher les abus d’ordres, garantir une tarification et des frais justes pour tous.
-
Vitesse et disponibilité : traitement rapide et haute disponibilité, évitant retards et désagréments.
-
Information : aider les utilisateurs à prendre des décisions éclairées via le suivi des ordres, l’estimation des prix de règlement, et des conseils utiles sur les ordres limites et le slippage.
-
Liquidité : présenter de forts pools de liquidité sur diverses paires, inspirant confiance dans les prix avantageux.
Si le contrat intelligent du DEX est jugé sécurisé, la confiance est établie. Le DEX ne détient pas les actifs des utilisateurs. Aujourd’hui, les informations disponibles pour les traders sont larges. La nature sans permission des AMM permet de créer et échanger n’importe quelle paire. Toutefois, en raison des propriétés de la blockchain, le meilleur prix, l’équité, la vitesse et la disponibilité ne sont pas toujours garantis. Les frais de gaz, les retards de prix et la fragmentation de la liquidité nuisent à l’expérience.
Pour y remédier, le nombre de DEX sur L2 ne cesse de croître. Les systèmes de routage, de batch d’ordres et de requêtes de cotation deviennent plus sophistiqués. Pour prévenir le front-running et assurer une répartition équitable de la valeur, de plus en plus de canaux MEV-aware sont déployés. Des efforts sont menés pour créer des marchés d’enchères de flux d’ordres, minimisant la fuite de valeur pour les utilisateurs DEX. L’introduction des hooks et des coprocesseurs ZK élargit considérablement les possibilités de conception AMM, permettant des
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@SevenXVentures
