Tutoriel pas à pas : maîtrisez rapidement la méthode de consultation des intervalles de prix de liquidité sur Meteora
TechFlow SélectionTechFlow Sélection
Tutoriel pas à pas : maîtrisez rapidement la méthode de consultation des intervalles de prix de liquidité sur Meteora
Pour savoir à quel prix Dev vend ou accumule dans un pool unidirectionnel, il est essentiel de connaître la fourchette de prix correspondante.
Dédié à des analyses Web3 approfondiesAuteur : Zibù
Meteora est un projet DeFi sur la chaîne Solana, spécialisé dans la création d'une couche de liquidité efficace, durable et flexible pour l'écosystème Solana. Son objectif est de résoudre le problème du manque de liquidité sur Solana afin de rendre les transactions plus fluides, moins coûteuses, tout en offrant aux fournisseurs de liquidités des rendements améliorés.
Les pools de Meteora sont principalement des pools DLMM et des Dynamic Pools (pools dynamiques). Dans les pools DLMM, on peut ajouter des pools bilatéraux ou unilatéraux. Les développeurs peuvent utiliser les pools unilatéraux pour vendre leurs jetons (dump) ou accumuler des positions (accumulate), par exemple avec la paire Trump/Sol. Lorsque le prix augmente, un développeur peut ajouter uniquement du $Trump dans un pool unilatéral à un niveau de prix plus élevé ; lorsque le prix atteint cette fourchette, le $Trump est automatiquement échangé contre du $Sol, permettant ainsi la vente, tout en percevant des frais de transaction. Lorsque le prix baisse, le développeur peut ajouter uniquement du $Sol dans un pool unilatéral à un niveau de prix inférieur ; lorsque le prix atteint cette zone, il achète automatiquement du $Trump, réalisant ainsi une accumulation.
Si nous voulons savoir à quel prix les développeurs utilisent les pools unilatéraux pour vendre ou accumuler, il est essentiel de connaître leur plage de prix correspondante.
1. Concepts de base
Site web : https://app.meteora.ag/
1. Paires de trading
Deux jetons forment une paire de trading, par exemple $Trump et $Sol forment la paire Trump-Sol, $Trump et $USDC forment la paire Trump-USDC.
2. Pool (pool LP)
Chaque paire peut contenir plusieurs pools, chacun différencié par le Bin Step et les frais (fees).
Par exemple, la paire Trump-USDC contient 57 pools, chaque pool ayant une adresse unique.
Comme indiqué ci-dessous :
3. Bin
Dans DLMM, chaque bin représente un prix donné, correspondant à un ordre d'achat ou de vente placé à ce prix précis.
4. Bin Step
Le Bin Step désigne l'intervalle de prix entre deux bins adjacents, exprimé en points de base (Basis Points, 1 point de base = 0,01 %). Il détermine la densité des bins et la finesse de la répartition de la liquidité, et est défini par le créateur du pool.
Par exemple :
Supposons que le prix actuel de Sol/USDC soit de 20 dollars, avec un Bin Step fixé à 25 points de base (0,25 %).
Le prix du bin suivant sera 20 × 1,0025 = 20,05 dollars, puis 20,05 × 1,0025 ≈ 20,10 dollars, et ainsi de suite.
5. Position (position)
Une position décrit comment un fournisseur de liquidité alloue ses fonds dans un intervalle de prix spécifique. Chaque position possède une adresse unique. Une position est créée au sein d'un pool donné, et un même pool peut contenir plusieurs positions différentes.
Une position comprend généralement les éléments clés suivants :
(1) Intervalle de prix
Chaque position a un intervalle de prix bien défini, représentant la fourchette de prix où le fournisseur souhaite apporter de la liquidité. Cet intervalle est composé d'une série de bins consécutifs.
(2) Montant investi
Quantité des deux jetons déposés (par exemple Sol et USDC). Meteora calcule automatiquement la proportion exacte de chaque jeton selon le prix actuel et la plage définie, afin de répondre aux exigences du pool.
(3) Stratégie de répartition
Meteora propose plusieurs méthodes de distribution de liquidité, permettant aux utilisateurs de choisir comment allouer leurs fonds entre les différents bins :
Spot (répartition uniforme) : les fonds sont répartis équitablement entre chaque bin, adapté aux scénarios où les fluctuations de prix sont faibles.
Curve (répartition en cloche) : les fonds sont concentrés autour du prix actuel, diminuant progressivement à mesure qu'on s'en éloigne, comme une courbe en cloche, idéal pour les LP souhaitant se concentrer sur le prix courant.
Bid-Ask (répartition bidirectionnelle) : les fonds sont concentrés de part et d'autre du prix actuel, formant deux pics, adapté aux marchés très volatils.
(4) Bin Step
L'utilisateur ne peut pas modifier le Bin Step lors de la création d'une position ; celui-ci est fixé au moment de la création du pool.
2. Vérification via connexion de portefeuille
Après avoir connecté un portefeuille, Meteora permet de consulter les positions détenues, y compris en mode observation. Cette fonctionnalité peut être utilisée pour examiner les plages de prix des pools.
Prenons l'exemple du $Trump.
Tout d'abord, ouvrons Debot, saisissons l'adresse CA du $Trump, puis identifions l'adresse du Dev :
5e2qRc1DNEXmyxP8qwPwJhRWjef7usLyi7v5xjqLr5G7
Comme indiqué ci-dessous :
Ensuite, ouvrez le portefeuille Phantom, sélectionnez 【Ajouter/Connecter un portefeuille】 → 【Surveiller une adresse】, puis saisissez le « nom » et « l'adresse », ici celle du Dev :
5e2qRc1DNEXmyxP8qwPwJhRWjef7usLyi7v5xjqLr5G7
Enfin, ouvrez Meteora et connectez votre portefeuille Phantom. Cliquez sur 【Portfolio】 en haut pour afficher tous les pools ajoutés. En cliquant sur n’importe quel pool DLMM, vous verrez les détails du pool et toutes les positions associées.
Comme indiqué ci-dessous :
Dans l'image, les informations situées à gauche (Bin Step et Base Fee) correspondent au pool actuel. La partie centrale affiche les positions selon différentes plages de prix. En cliquant sur une position, on peut voir le solde actuel, les frais non perçus, la stratégie de répartition, etc.
L'avantage de cette méthode est sa simplicité et son aspect visuel, permettant de lister toutes les données des positions existantes. Son inconvénient est qu'elle ne permet pas de visualiser les positions dont la liquidité a été retirée.
3. Calcul à partir des données blockchain
Nous pouvons calculer la plage de prix de chaque position directement à partir des données blockchain, que la position existe encore ou non.
La documentation de Meteora fournit les formules suivantes :
Prix minimum de l’intervalle : min_price = (1 + Bin_Step/10000) ^ lower_Bin_id
Prix maximum de l’intervalle : max_price = (1 + Bin_Step/10000) ^ upper_Bin_id
Si la paire est notée A/B, où le jeton A a une précision decimals_A et le jeton B une précision decimals_B, alors les formules finales deviennent :
Prix minimum de l’intervalle : min_price = (1 + Bin_Step/10000) ^ lower_Bin_id / 10^(decimals_B - decimals_A)
Prix maximum de l’intervalle : max_price = (1 + Bin_Step/10000) ^ upper_Bin_id / 10^(decimals_B - decimals_A)
Notez que le prix calculé correspond au prix du jeton A par rapport au jeton B. Pour obtenir le prix du jeton A par rapport au USD, il faut également connaître le prix du jeton B en USD, puis effectuer une conversion.
D'après ces formules, pour effectuer les calculs, nous avons besoin du Bin_Step du pool, des valeurs lower_Bin_id et upper_Bin_id de la position, ainsi que des précisions des deux jetons de la paire.
Reprenons l'exemple du $Trump pour calculer la plage de prix d’un pool unilatéral de ce Dev.
Ouvrons Solscan et saisissons l'adresse du Dev du $Trump :
Allez dans l'onglet 【Defi Activities】, filtrez par action « ADD LIQUIDITY ». Dans la colonne Amount, toutes les transactions d'ajout de liquidité affichées concernent des pools unilatéraux : soit uniquement du $Trump, soit uniquement du $USDC.
Cet article prend comme exemple la dernière transaction visible sur l’image :
Ouvrons la dernière transaction figurant dans l’image ci-dessus :
Dans les détails de la transaction, on constate que seul du $Trump a été ajouté à ce pool, comme illustré ci-dessous :
En ouvrant les liens vers $Trump et $USDC, on trouve que la précision de $Trump est 6, celle de $USDC est également 6, comme indiqué ci-dessous :
En descendant dans la page des détails de la transaction, sous 【#4.1 - Meteora DLMM Program: initializePosition】, on voit que lowerBinId vaut 1062, la largeur du bin (nombre de bins) est 46, et l'adresse du pool est :
9d9mb8kooFfaD3SctgZtkxQypkshx6ezhbKio89ixyy2
Comme indiqué ci-dessous :
À partir de ces informations, on calcule upperBinId = lowerBinId + width - 1 = 1062 + 46 - 1 = 1107
Ouvrons maintenant l'adresse du pool sur Solscan :
9d9mb8kooFfaD3SctgZtkxQypkshx6ezhbKio89ixyy2
https://solscan.io/account/9d9mb8kooFfaD3SctgZtkxQypkshx6ezhbKio89ixyy2
Cliquer sur l'onglet 【data】 puis basculer « LbPair » en « Table » pour trouver que la valeur de BinStep est 50, comme indiqué ci-dessous :
Nous disposons désormais de toutes les données nécessaires pour appliquer les formules de calcul :
Bin_Step = 50
lower_Bin_id = 1062
upper_Bin_id = 1107
decimals_A = 6
decimals_B = 6
Nous pouvons donc calculer :
Prix minimum de l’intervalle : min_price = (1 + Bin_Step/10000) ^ lower_Bin_id / 10^(decimals_B - decimals_A) = (1 + 50/10000)^1062 / 10^(6 - 6) = 199,6905832
Prix maximum de l’intervalle : max_price = (1 + Bin_Step/10000) ^ upper_Bin_id / 10^(decimals_B - decimals_A) = (1 + 50/10000)^1107 / 10^(6 - 6) = 249,9368917
Les plages de prix calculées correspondent exactement à celles visibles dans l’image de la section 2.
4. Conclusion
En combinant des outils de surveillance, lorsque nous détectons qu’un développeur ou un gros acteur ajoute un pool unilatéral, nous pouvons utiliser la méthode décrite ci-dessus pour déterminer la plage de prix à laquelle il prévoit de vendre ou d’accumuler, puis prendre des décisions basées sur ces données et les graphiques K-line. Par exemple, le jeton $LIBRA lancé par le président argentin Milei a également utilisé une stratégie de pool unilatéral pour vendre ses jetons ; la méthode présentée ici permet d’analyser rétrospectivement la plage de prix utilisée lors de cet ajout.
Mes outils habituels sont Debot, GMGN et OKX, mais aucun n’est encore très pratique pour consulter la liquidité. Voici quelques fonctionnalités idéales qui pourraient être intégrées :
1. Lister toutes les opérations du Dev, y compris les transferts entrants, sortants, les ajouts et retraits de liquidité, en identifiant spécifiquement les transactions liées au blocage ou déblocage de jetons, ainsi qu’à l’ajout/retrait de pools.
Debot identifie tous les transferts entrants et sortants, mais ne détecte ni les ajouts ni les retraits de liquidité ;
GMGN détecte les ajouts et retraits de liquidité, mais ne repère pas les transferts du Dev, et n’a pas non plus identifié ces opérations pour le jeton Trump ;
OKX dispose d’une fonction « changement de pool de liquidité » qui liste séparément les ajouts et retraits, mais n’a pas non plus identifié ces transactions pour le jeton Trump.
2. Pour chaque ajout ou retrait de liquidité, afficher directement la plage de prix correspondante, évitant ainsi les calculs manuels.
3. Lors du calcul des profits du Dev, inclure les frais perçus ainsi que les variations de fonds dues aux retraits de liquidité, afin d’éviter de devoir faire manuellement le suivi des gains.
Cette fonctionnalité pourrait potentiellement être mise en œuvre par Debot ou GMGN, puisqu’ils calculent déjà les performances de profitabilité par adresse.
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
@0x_zibu
