Le champ liquidity d'un pool Uniswap V3 n'est ni de l'argent ni de la profondeur de swap. Laissez Claude vous guider dans chaque champ facile à mal lire.
Quiconque touche à la DeFi finit tôt ou tard par scruter les données d'un pool Uniswap V3. Et dans cette grille de chiffres affichée sur la page du pool, il y a au moins un champ que presque tout le monde lit de travers la première fois —— une erreur de lecture assez grosse pour vous faire croire qu'un pool de 100 millions de dollars contient 3,2 trillions de dollars de « liquidité ».
Cet article lit un pool de bout en bout en cinq minutes, avec smarts MCP et Claude. Des vraies données, le pool USDC/WETH 0.05% sur mainnet.
Une fois smarts MCP branché, Claude appelle get_uniswap_v3_pool avec le slug univ3-usdc-weth-eth et reçoit ceci :
protocol: Uniswap V3
pair: USDC/WETH
fee: 0.05%
price:
1 WETH in USDC: 2310.3381
1 USDC in WETH: 0.00043283
tick: 198868
liquidity: 3243712254364037809
liquidity_note: Uniswap V3 sqrt-formula virtual liquidity
at the current tick. Not a USD amount and
not the depth available to swap.
tvl_usd: 100,645,897.62
tokens:
token0: USDC (decimals 6)
token1: WETH (decimals 18)
block_number: 24959248
Les données en elles-mêmes sont simples. Ce qui compte, c'est que chaque champ a son piège. Décortiquons un par un.
On suppose souvent que dans un pool USDC/WETH, l'USDC est la « monnaie principale » et le WETH « l'actif côté ». Faux. Uniswap V3 ordonne token0 et token1 strictement par la valeur numérique de leurs adresses. L'adresse USDC 0xa0b8... est inférieure à celle de WETH 0xc02a..., donc token0 = USDC, token1 = WETH.
Cet ordre commande tous les calculs internes : la direction du prix, le sens des ticks, l'unité de la liquidité. Changez de pool, par exemple WETH/DAI, et les rôles de token0/token1 peuvent s'inverser —— toute intuition sur « ETH monte ou baisse ? » est à refaire.
L'un des avantages de laisser Claude lire le pool : il vous étiquette le prix dans les deux sens, vous évitant de calculer mentalement « quel côté du tick correspond à quel token ».
Les quatre fee tiers courants d'Uniswap V3 sont 0.01% / 0.05% / 0.30% / 1.00%.
Que USDC/WETH utilise 0.05% plutôt que 0.30% nous dit : les market makers parient sur le volume, pas sur des fees épais par trade, parce que la volatilité est bornée et le flux énorme.
Sachant ça, dès que vous voyez un nouveau pool à 1% de fee, vous pouvez deviner : soit un token tout neuf, soit personne ne s'intéresse à la paire.
L'état d'un pool V3 n'a pas de champ « dernier prix échangé » séparé. Le prix actuel, c'est ce que dit slot0.sqrtPriceX96, et le tick en est l'expression logarithmique. Autrement dit : tant que personne ne trade, le prix reste là, modèle totalement différent du « dernier fill » sur un CEX.
(Pour les prix historiques, on utilise l'oracle intégré de V3 —— l'état du pool contient un tableau d'accumulateurs d'observations permettant de dériver un TWAP. C'est un mécanisme séparé.)
Le 1 WETH = 2310.34 USDC que nous venons de lire est le « cours actuel » du pool ; le prochain swap part de là et pousse le prix le long de la courbe jusqu'à un nouveau tick.
tick: 198868 est le nombre qui désarçonne tout le monde la première fois. On dirait un prix, mais ce ne sont pas des dollars.
V3 discrétise le prix de manière logarithmique : raw_price = 1.0001^tick, où raw_price vaut les wei de token1 divisés par les wei de token0 —— pas le prix d'affichage. Pour le convertir en « 1 ETH en USDC », il faut encore multiplier par 10^(decimals_token0 - decimals_token1). Après cet ajustement, le tick 198868 correspond bien à 1 ETH ≈ 2310 USDC.
Pourquoi cette gymnastique ? Parce qu'une fois le prix logarithmique, les market makers peuvent placer la liquidité uniquement sur une plage de prix précise —— par exemple « seulement entre 2200 et 2400 ». Les ticks discrets sont les étiquettes de ces plages. C'est l'innovation distinctive de V3 face à V2 : la liquidité concentrée.
En pratique, vous n'avez pas besoin de calculer des ticks. Il faut juste retenir : un tick plus grand ne veut pas dire prix plus élevé (ça dépend du token0), et un pas de tick = un changement de prix de 0.01%.
Voici le gros piège : liquidity: 3243712254364037809.
Dix-neuf chiffres, ça ressemble à du wei. Mais ce n'est pas de l'argent.
C'est la « liquidité virtuelle » L des maths d'Uniswap V3 —— un paramètre interne qui exprime la pente de la courbe de market making sur une plage sqrt-price. Son unité n'est pas l'USD et il n'est pas comparable aux avoirs réels du pool.
La réponse de l'outil avertit explicitement avec un liquidity_note :
Uniswap V3 sqrt-formula virtual liquidity at the current tick. Not a USD amount and not the depth available to swap.
Pourquoi cette deuxième partie ? Parce qu'une autre erreur courante est de lire liquidity comme « combien je peux swapper maintenant sans slippage ». Faux aussi. La profondeur de swap V3 se calcule par morceaux : dans la plage de tick actuelle, on utilise ce L avec la formule sqrt-price ; dès qu'un swap pousse le prix à travers une borne de tick, on passe à la plage suivante et on bascule sur son L. Chaque borne franchie remplace le L, jusqu'à ce que le trade soit terminé. Donc « combien on peut swapper sans slippage » dépend de combien de L est posé sur chaque plage le long du chemin —— un seul nombre du slot0 ne dit rien.
À retenir : ne comparez pas le champ liquidity à des USD, ne vous en servez pas pour comparer la « profondeur » entre pools —— c'est trompeur.
tvl_usd: 100,645,897.62. Voilà l'argent réel du pool.
D'où sort ce nombre ? C'est le solde réel de USDC du contrat plus son solde réel de WETH, chacun multiplié par le prix actuel en USD remonté depuis DefiLlama, le tout additionné.
Comparé au champ liquidity :
| Champ | Valeur | Sens |
|---|---|---|
| liquidity | 3.24 × 10¹⁸ | paramètre interne maths V3, sans unité |
| tvl_usd | $100,645,897 | argent réellement détenu par le pool |
Les deux sont traduits par « liquidité » dans le langage courant, mais ce sont des choses différentes. Pour raconter, regardez le TVL ; pour calculer, regardez liquidity. Ne mélangez jamais.
Dernier détail : block_number: 24959248.
Les données on-chain viennent toujours avec un numéro de bloc. Tous les champs ramenés par Claude sont lus dans le même bloc. Ça implique deux choses :
Pour de la logique de monitoring ou d'arbitrage, c'est la propriété décisive —— une lecture donne une vue cohérente du monde, sans avoir à craindre des décalages temporels entre champs.
Une fois tout ça compris, la boîte à outils s'ouvre :
Tout cela demandait avant d'installer web3.py, d'écrire un script, de maintenir un ABI et de louer du RPC. Maintenant tout passe au niveau conversationnel avec Claude + MCP —— vous demandez, il lit.
Le modèle mathématique de V3 a un mur d'entrée. sqrtPriceX96, ticks, L, liquidité concentrée —— ces concepts ont fait reculer beaucoup de monde. Mais en pratique, 90% de ce dont vous avez besoin tient en : « ce pool va bien, a-t-il de l'argent, quel est le prix ? » —— pas de formule.
Faites de Claude votre traducteur V3, transformant la liquidité virtuelle et le codage des ticks en un simple « 1 ETH = 2310 USDC, le pool contient 100 M$ ». Les décisions, à partir de là, sont à vous.