Détection et économie réelle¶
C'est le chapitre qui répond à la question « est-ce que ça vaut le coup ? » avec des mesures plutôt qu'avec des captures de PnL.
L'API de détection¶
Meteora expose une API publique, sans authentification ni clé.
| Mainnet | https://damm-v2.datapi.meteora.ag |
| Endpoint | GET /pools |
| Pagination | page (1-indexé), page_size (max 1000) |
| Tri | sort_by=<métrique>_<fenêtre>:<sens> |
| Filtre | filter_by=<champ><op><valeur>, && pour combiner |
Fenêtres temporelles disponibles : 5m, 30m, 1h, 2h, 4h, 12h, 24h.
Métriques triables : volume, fees, fee_tvl_ratio, apr, tvl,
fee_pct, pool_created_at, farm_apy.
Les champs qui comptent¶
| Champ | Ce qu'il vous dit |
|---|---|
created_at |
Horodatage de création — votre signal principal |
launchpad |
Origine du lancement (met-dbc, bags.fun, pump.fun, jup-studio…). Non vide = migration |
tvl |
Profondeur du pool |
volume.{1h,24h} |
L'activité réelle |
fees.{1h,24h} |
Les frais générés par le pool |
fee_tvl_ratio.{1h,24h} |
Le rendement, en % de la TVL |
permanent_lock_liquidity |
La part verrouillée à jamais |
pool_config.base_fee_pct |
Votre tarif |
pool_config.is_fee_scheduler_active |
Le frais est-il encore en décroissance |
pool_config.dynamic_fee_initialized |
Couche de volatilité active |
pool_config.collect_fee_mode |
Dans quel token vous êtes payé |
pool_config.concentrated_liquidity |
Le pool est-il borné |
token_y.holders, freeze_authority_disabled |
Premier niveau de vérification du token |
is_blacklisted |
Signalement du protocole |
Limite du filtrage côté serveur
filter_by fonctionne sur les champs scalaires de premier niveau (tvl,
par exemple), mais pas sur les champs imbriqués de pool_config — un
filtre has_fee_scheduler=true ou base_fee_pct>1 renvoie zéro résultat.
Il faut donc filtrer grossièrement côté serveur, puis affiner côté client. (Constaté empiriquement le 30 juillet 2026 ; le comportement peut évoluer.)
La requête de screening¶
curl -s -G "https://damm-v2.datapi.meteora.ag/pools" \
--data-urlencode "filter_by=tvl>3000" \
--data-urlencode "sort_by=pool_created_at:desc" \
--data-urlencode "page_size=200"
Puis, côté client, on ne garde que les pools qui satisfont toutes les conditions du tableau de seuils ci-dessous.
La taille réelle du gisement¶
Mesures du 30 juillet 2026.
| Indicateur | Valeur |
|---|---|
| Pools DAMM v2 existants | 124 185 |
| Dont TVL > 3 000 $ | 2 521 (2,0 %) |
| Dont âgés de moins de 7 jours | ~23 |
Le premier chiffre à intégrer
98 % des pools DAMM v2 sont vides.
Le flux exploitable, ce sont quelques unités par jour, pas des centaines. Une automatisation qui traite « tous les nouveaux pools » traitera essentiellement du bruit : sur les 20 pools les plus récemment créés, la quasi-totalité affiche une TVL de zéro et un frais de base de 0,01 % — ce sont des coquilles vides créées automatiquement.
Le filtre launchpad != "" combiné à tvl > 3000 élimine l'essentiel de
ce bruit.
La décroissance du rendement¶
Mesure centrale de ce rapport. Échantillon : 819 pools uniques de plus de 3 000 $ de TVL, relevés le 30 juillet 2026, classés par âge.
La métrique est fee_tvl_ratio.24h : les frais générés sur 24 heures rapportés
à la TVL. C'est le rendement journalier brut, avant perte divergente.
| Âge du pool | n | Médiane | 90ᵉ centile | > 1 %/j | > 2 %/j | > 5 %/j | Volume 24 h nul |
|---|---|---|---|---|---|---|---|
| < 24 h | 6 | 0,933 % | 13,18 % | 33 % | 33 % | 17 % | 0 % |
| 1–7 jours | 17 | 1,092 % | 17,66 % | 53 % | 29 % | 18 % | 6 % |
| 7–30 jours | 71 | 0,038 % | 1,11 % | 11 % | 7 % | 4 % | 17 % |
| > 30 jours | 725 | 0,000 % | 0,09 % | 1 % | 1 % | 0 % | 51 % |
Lecture¶
Ce que ça dit
La fenêtre est réelle et elle est étroite. Le rendement médian passe d'environ 1 %/jour la première semaine à 0,038 %/jour entre 7 et 30 jours — un facteur ~30 — puis à zéro.
La distribution est extrêmement asymétrique. Même dans la fenêtre chaude, la médiane est à ~1 %/jour mais le 90ᵉ centile est à 13–18 %/jour. L'essentiel du rendement se concentre dans une minorité de pools.
Passé 30 jours, il n'y a plus rien. Un pool sur deux ne fait aucun volume. C'est le cimetière.
Ce que ça ne dit pas
Ce sont des rendements bruts, avant perte divergente. Sur un token qui perd 40 % en trois jours — le cas modal après une migration — une position 50/50 encaisse une perte divergente qui dépasse largement 3 % de frais.
Un rendement de 1 %/jour ne compense pas un token qui s'effondre. Le rendement n'est qu'une moitié de l'équation ; l'autre est la sélection du token, et elle n'est pas automatisable.
Limites de la mesure
Instantané unique, un seul point dans le temps. Les seaux « < 24 h » (n=6) et « 1–7 j » (n=17) ont des effectifs faibles : leurs médianes sont indicatives, pas robustes. Les seaux 7–30 j (n=71) et > 30 j (n=725) sont solides.
La tendance est monotone, d'amplitude très large, et cohérente avec la mécanique documentée du chapitre précédent.
Les seuils de screening¶
Construits à partir des mesures ci-dessus.
| # | Critère | Seuil | Pourquoi |
|---|---|---|---|
| 1 | launchpad non vide |
— | C'est une vraie migration, pas une coquille |
| 2 | Âge du pool | < 72 h | Au-delà, le rendement médian s'effondre |
| 3 | tvl |
> 5 000 $ | En dessous, le pool est illiquide et le slippage de sortie dévore le gain |
| 4 | volume.24h |
> 50 000 $ | Seuls 6 % des pools y parviennent — c'est le filtre discriminant |
| 5 | fee_tvl_ratio.1h |
> 0,05 % | Vérifie que le pool travaille maintenant, pas hier |
| 6 | base_fee_pct |
≥ 1 % | En dessous, il faut un volume énorme pour couvrir la perte divergente |
| 7 | token.freeze_authority_disabled |
true | Vérification de sécurité minimale |
| 8 | is_blacklisted |
false | Signalement du protocole |
| 9 | Votre dépôt / tvl |
< 5 % | Au-delà, vous diluez le rendement qui vous a attiré |
Le critère qui fait le tri
Le n° 4. Sur l'échantillon complet, 6,2 % des pools dépassent 50 000 $ de volume sur 24 h, et 71,6 % font moins de 1 000 $.
Si vous ne deviez retenir qu'un filtre, ce serait celui-là — c'est aussi la traduction directe du « Volume is king » de l'academy.
Ce que les seuils laissent passer¶
Appliqués à l'échantillon du 30 juillet 2026, ces neuf critères laissent quelques pools par jour. C'est peu, et c'est normal : la stratégie est un jeu d'événements rares, pas un flux continu.
Le piège du screening trop permissif
Assouplir les seuils pour « avoir plus d'opportunités » est le réflexe naturel et c'est exactement l'erreur. La distribution est telle que la quasi-totalité du rendement se trouve dans le haut de la queue : élargir ne fait qu'ajouter des positions à espérance négative.
Vérifier avant d'entrer¶
L'API donne un premier niveau de sécurité (freeze_authority_disabled,
holders, is_blacklisted), mais il reste insuffisant.
La checklist de screening du rapport principal s'applique intégralement — rugcheck.xyz, Bubblemaps, détection du wash trading.
Un point spécifique à cette stratégie :
Le volume post-migration peut être fabriqué
C'est le pire scénario pour cette stratégie précise, parce qu'elle entre sur le signal de volume.
Un lancement peut générer artificiellement du volume pendant quelques heures pour attirer de la liquidité tierce. Vous déposez les deux tokens, le volume s'arrête, le prix s'effondre, et vous détenez la moitié de votre dépôt en token mort.
Contre-mesure : vérifier que le nombre de détenteurs (token_y.holders)
est cohérent avec le volume affiché, et regarder Bubblemaps avant tout
dépôt supérieur au montant que vous acceptez de perdre.
À retenir¶
Les cinq faits de ce chapitre
- Une API publique, sans clé, expose l'intégralité du signal :
damm-v2.datapi.meteora.ag/pools. - 98 % des pools DAMM v2 sont vides. Le gisement, c'est ~23 pools de moins de 7 jours à un instant donné.
- Le rendement médian passe de ~1 %/jour la première semaine à 0 % après 30 jours.
- La distribution est très asymétrique : la médiane est à 1 %/jour, le 90ᵉ centile à 13–18 %/jour.
- Le filtre discriminant est le volume 24 h > 50 000 $ : seuls 6 % des pools y parviennent.