Aller au contenu

La vraie stratégie : le pool MEV à 50 %

Correction majeure. Le fil complet de @skolmbeagh décrit une stratégie différente de celle simulée aux chapitres 5 et 6.

Ce chapitre la reconstitue et la mesure correctement.


Ce que j'avais simulé, et ce que c'est vraiment

Ce que j'avais mesuré La vraie stratégie
Le pool Le pool officiel issu de la migration Un micro-pool en configuration « Memecoin », rejoint ou créé
Le frais 1 à 4 % 50 % au départ, décroissance exponentielle vers 6 %
La profondeur 30 000 $ 9 $ en médiane — mesuré
La part de liquidité 0,3 % 65 % en médiane avec un dépôt de 0,23 SOL
La fenêtre 24 à 72 heures 20 à 45 minutes
La source du revenu Volume organique MEV et ordres à fort slippage
La taille 75 $ 0,05 à 0,3 SOL (4 à 22 $)

L'erreur de fond

Je mesurais un fournisseur qui rejoint un pool profond et récolte une fraction de pourcent des frais sur du volume organique.

La stratégie réelle consiste à occuper une poche de liquidité minuscule à 50 % de frais, dont on détient la majorité, et à encaisser les transactions que les arbitrageurs et les vendeurs pressés y envoient dans la demi-heure suivant une migration.

Ce n'est pas du fee farming. C'est vendre de l'exécution d'urgence.

Le mécanisme

L'auteur l'explique sans détour :

« In DAMM V2, LPs earn when a buyer makes a trade at a much worse price than the market — typically due to a high-fee pool, similar to a MEV-style "wick." »

Le token pompe → votre pool, peu profond, garde un prix en retard. Un arbitrageur y achète pour capter l'écart, et vous verse 50 % de frais.

Le token dumpe → un vendeur pressé règle un slippage très élevé. Sa transaction est routée vers votre pool. Il vous vend sous le prix du marché, et vous paie 50 % de frais.

L'intuition

Vous n'êtes pas rémunéré pour fournir de la profondeur. Vous êtes rémunéré pour être le dernier recours de quelqu'un qui doit absolument passer tout de suite.

Rejoindre plutôt que créer

C'est le point que j'avais mal restitué dans une première version. Le fil est explicite : rejoindre est le chemin préféré, créer est le repli.

« We've selected and bought our coin, now we need to either create a pool or join an existing one if it's already open. »

« If the settings of an open pool match what we're looking for, it's better for everyone to join that existing pool, it increases the chance of that pool working well. Having multiple pools for the same token is usually not ideal. »

Le mode d'emploi de création qui suit vaut pour le cas où aucun pool convenable n'existe.

Pourquoi rejoindre ne dilue quasiment pas

Objection naturelle : rejoindre un pool existant, n'est-ce pas se diluer ?

Non — parce que ces pools sont minuscules. Profondeur estimée par l'impact de prix sur les 45 premières minutes, sur 139 pools :

Quantile Profondeur du pool En SOL Part obtenue en déposant 0,23 SOL
p10 2 $ 0,02 91 %
p25 3 $ 0,05 83 %
médiane 9 $ 0,13 65 %
p75 28 $ 0,37 38 %
p90 121 $ 1,62 13 %

Méthode d'estimation

Pour un pool à produit constant, un flux \(V\) qui déplace le prix de \(P_{\text{bas}}\) à \(P_{\text{haut}}\) implique une réserve en token de cotation :

\[ R_q \approx \frac{V}{\sqrt{P_{\text{haut}}/P_{\text{bas}}} - 1} \qquad \text{et} \qquad \text{TVL} \approx 2 R_q \]

Appliqué à chaque bougie de 5 minutes puis médianisé. Estimateur bruité — plusieurs échanges par bougie, dans les deux sens — mais l'ordre de grandeur est net : ces pools pèsent quelques dizaines de dollars.

Déposer 0,23 SOL dans un pool médian de 9 $, c'est en devenir propriétaire à 65 %. La dilution n'est pas le problème.


Sa configuration exacte

Réglage Valeur
Fee Tier 6 %
Dynamic Fee Oui
Fee Collection Token Quote (vous encaissez en SOL/USDC)
Fee Scheduler Oui
Fee Scheduler Mode Exponentiel
Temps écoulé Frais de swap
t = 0 50 %
+1 h ≈ 20 %
+2 h 6 % (plancher définitif)

Coûts fixes : 0,012 SOL pour créer un pool (non remboursable, nul si vous rejoignez) et 0,01 SOL de rent de position (remboursé à la fermeture).

Ses critères de sélection

Filtrage sur l'onglet Pulse d'axiom.trade, en 20 à 30 secondes :

Critère Seuil
Âge depuis la migration < 30 minutes
Capitalisation **< 200 000 \(** (idéalement ~100 k\))
Top 10 détenteurs entre 10 % et 35 %
Tokens détenus par le dev zéro — sinon il s'abstient
Snipers < 15 %
Insiders < 15 %
Bundle < 15 %
Twitter / communauté actif de préférence
Allure du prix mouvement organique

Vérification n° 1 : la fenêtre de 20-25 minutes

Répartition des frais LP réellement perçus, sur 151 pools à fee scheduler créés du 23 au 30 juillet 2026 :

Tranche Part des frais Cumulé
0 – 15 min 18,0 % 18,0 %
15 – 30 min 42,1 % 60,0 %
30 – 45 min 15,7 % 75,8 %
45 – 60 min 13,8 % 89,6 %
60 – 75 min 4,0 % 93,6 %
75 – 120 min 6,4 % 100 %

Son affirmation est exacte

« The most profitable window is usually within the first 20–25 minutes. »

60 % des frais tombent dans les 30 premières minutes, 76 % dans les 45 premières, 90 % dans la première heure. Sa règle — chercher la sortie vers 45 minutes — tombe exactement au bon endroit.

Vérification n° 2 : le résultat, en mode « rejoindre »

Simulation sur les 139 pools dont la profondeur est estimable. Dépôt de 0,23 SOL, part = \(D/(\text{profondeur} + D)\), aucun coût de création.

Durée 20 min 25 min 45 min 60 min 120 min
PnL +2,1 % +3,8 % +2,9 % −0,3 % −5,8 %

Sans filtre de qualité, le résultat est proche de zéro — mais avec un taux de réussite de 42 % (58/139) et une médiane à seulement −0,39 $.

Deux bornes pour un même résultat

Le modèle ci-dessus garde les frais du pool à leur niveau mesuré. C'est la borne basse : en ajoutant votre liquidité, le pool devient plus profond et absorbe davantage de flux MEV, donc génère plus de frais.

Borne haute, en supposant les frais proportionnels à la profondeur (votre revenu devient \(F \cdot D / T\) au lieu de \(F \cdot D/(T+D)\)) : +22,3 % sans filtre, avec 73 gagnantes sur 139.

La vérité est entre les deux : entre 0 et +22 % sans filtre.

Vérification n° 3 : le filtre qui change tout

C'est le résultat le plus utile de ce chapitre, et il est contre-intuitif.

La profondeur du pool existant est un signal de qualité

Profondeur du pool rejoint n PnL Médiane Gagnantes Sans top 3
toutes 139 +2,9 % −0,39 $ 58/139 (42 %) −3,8 %
≥ 5 $ 91 +19,3 % +0,00 $ 49/91 (54 %) +9,5 %
≥ 10 $ 67 +27,5 % +0,19 $ 42/67 (63 %) +14,3 %
≥ 25 $ 37 +36,7 % +0,40 $ 28/37 (76 %) +12,8 %
≥ 50 $ 20 +16,0 % +0,02 $ 13/20 −0,1 %

Un pool où quelqu'un a déjà mis de l'argent est un pool validé

À l'inverse, filtrer sur « ma part ≥ 50 % » — c'est-à-dire sur les pools les plus vides — donne −14,1 %.

Sélectionner les pools peu profonds revient à sélectionner les pools dont personne n'a voulu. La profondeur existante est une validation par un tiers qui a fait le même travail de filtrage que vous, quelques minutes plus tôt.

C'est l'argument économique derrière son conseil : « it's better for everyone to join that existing pool, it increases the chance of that pool working well ». Il a raison, et pour une raison plus forte que la politesse — le pool déjà peuplé est statistiquement le meilleur.

Au-delà de 50 $ en revanche, l'effet s'inverse : votre part devient trop faible.

Les combinaisons

Filtre n PnL Médiane Gagnantes Sans top 3
Aucun 139 +2,9 % −0,39 $ 42 % −3,8 %
Détenteurs ≥ 400 38 +25,5 % −0,02 $ 50 % +7,1 %
Profondeur ≥ 25 $ 37 +36,7 % +0,40 $ 76 % +12,8 %
Détenteurs ≥ 400 + profondeur ≥ 25 $ 17 +40,2 % +0,04 $ 71 % +5,2 %
Détenteurs ≥ 400 + fee tier 6 % 21 +41,9 % +0,02 $ 52 % +8,9 %
Les trois 9 +68,1 % +1,18 $ 78 % +5,2 %

Le nombre de détenteurs (token.holders dans l'API) est le seul substitut disponible à ses critères Axiom de distribution : un token à large base est mécaniquement moins concentré.

Correction : le filtre « profondeur » était biaisé

Les chiffres de la section précédente (+36,7 % pour « profondeur ≥ 25 $ ») souffrent d'un biais de look-ahead : la profondeur y est estimée sur les 45 minutes de détention, donc en partie après l'entrée. Un pool devenu profond est souvent un pool qui a bien marché — le filtre sélectionnait partiellement sur le résultat.

Protocole honnête : n'observer que les 10 premières minutes, entrer à t + 10 min, sortir à t + 55 min.

Protocole n PnL Médiane Gagnantes
Observation 45 min, entrée t+0 (biaisé) 37 +33,8 % +0,64 $ 28/37
Observation 20 min, entrée t+0 (biaisé) 38 +31,3 % +0,54 $ 28/38
Observation 10 min, entrée t+10 (honnête) 33 +7,6 % +0,00 $ 12/33
Observation 5 min, entrée t+5 (honnête) 30 +4,9 % +0,00 $ 14/30
Témoin sans filtre de profondeur, honnête 126 +1,5 % +0,00 $ 39/126

L'effet réel est cinq fois plus faible

Le filtre apporte quelque chose — +7,6 % contre +1,5 % pour le témoin — mais pas +36,7 %. Et entrer à t+10 coûte la première tranche de frais (18 % du total).

Et il ne survit pas au retrait de deux positions

Seuil de profondeur n PnL Sans top 1 Sans top 2 Sans top 3
≥ 10 $ 60 +8,7 % +3,1 % −1,5 % −3,3 %
≥ 25 $ 33 +7,6 % −0,5 % −3,9 % −7,3 %
≥ 40 $ 22 −0,2 % −5,1 % −8,2 % −10,1 %

Conclusion honnête sur ce chapitre

Une fois le biais retiré, le résultat mesuré n'est pas distinguable de zéro. L'intégralité de l'écart tient à une à trois positions sur 33 à 60.

Le seuil optimal apparent (25 $) est instable : à 40 $ le résultat devient négatif. C'est la signature d'un paramètre ajusté au bruit d'un échantillon d'une semaine, pas d'un signal.

Ce qui reste solide dans ce chapitre :

  • la fenêtre temporelle (76 % des frais en 45 min), mesurée sur 151 pools et cohérente avec la mécanique du fee scheduler ;
  • la profondeur réelle des pools (9 $ en médiane), qui invalide l'objection de dilution ;
  • le dimensionnement du wallet, qui découle de la concurrence des positions et non des rendements ;
  • la structure de perte plafonnée : la position médiane ne perd rien ou presque.

Ce qui ne l'est pas : toute affirmation de rendement. Il faut plusieurs semaines de mesure en lecture seule avant d'avancer un chiffre.


Le mode « créer », pour comparaison

Quand aucun pool convenable n'existe. Part de 100 %, coût de 0,012 SOL.

Filtre n PnL Médiane Gagnantes Sans top 3
Aucun 151 +19,5 % −0,90 $ 29 % +2,1 %
Détenteurs ≥ 400 49 +51,3 % −0,90 $ 27 % +9,4 %

Deux profils de risque très différents

Créer : 29 % de réussite, médiane −0,90 $ (le loyer du pool), gain moyen +21,73 $ contre perte moyenne −3,95 $ — une loterie à queue épaisse, rapport 5,5 : 1.

Rejoindre un pool déjà profond : 76 % de réussite, médiane positive, gains plus petits — un flux régulier.

Le second est bien plus confortable à exécuter, et c'est celui que le fil recommande.

Attention toutefois : le mode « créer » bénéficie ici d'un avantage de modèle. Les frais mesurés sont ceux du pool réel avec sa profondeur réelle ; en mode « créer », on les attribue à 100 % au créateur, ce qui est correct, alors qu'en mode « rejoindre » on garde ces mêmes frais fixes alors qu'ils augmenteraient. La comparaison penche donc artificiellement vers la création.


Sur l'automatisation : je me suis trompé

Une version précédente de ce chapitre affirmait que la stratégie « ne se délègue pas à un bot ». C'est faux, et il faut le corriger.

Tout ce qu'il fait est automatisable

Étape Automatisable ?
Détecter les migrations Oui — API Meteora
Top 10 détenteurs, dev, snipers, insiders, bundle Oui — Axiom les expose, et ces métriques sont toutes dérivables on-chain
Capitalisation, âge Oui
Profondeur du pool existant Oui — c'est le filtre le plus fort de ce chapitre, et il est purement calculatoire
Fee tier, scheduler, collect mode Oui — champs pool_config
Acheter le token, ouvrir la position Oui — SDK @meteora-ag/cp-amm-sdk
Sortir à 45 min Oui — règle temporelle

Les seuls éléments flous — « prix d'allure organique », « Twitter actif » — sont approximables, et ce ne sont pas ceux qui portent le résultat dans les mesures ci-dessus.

Un bot fait ce filtrage en quelques centaines de millisecondes, là où le fil parle de 20 à 30 secondes.

Ce que l'automatisation change vraiment

Elle ne supprime pas la difficulté, elle la déplace.

De la décision vers l'infrastructure. Si le filtrage est calculatoire, alors quiconque le code correctement obtient le même signal. La question devient : qui arrive en premier ? Cela se joue sur le RPC, la construction de transaction, les frais de priorité, éventuellement les bundles Jito.

Et l'edge s'érode. Ce fil a été vu par des dizaines de milliers de personnes. L'auteur note lui-même que « the pools' profitability tends to fluctuate over time » et qu'ils ont été « quite quiet for about a week ».

Un bot supprime en revanche la vraie contrainte humaine. 108 pools par jour à trier en 30 secondes chacun est infaisable manuellement de façon soutenue. C'est précisément le genre de tâche où l'automatisation apporte le plus — non pas en décidant mieux, mais en ne ratant rien.


Volume opérationnel

7 jours Par jour
Pools à fee scheduler créés 758 108
Dont ≥ 400 détenteurs 286 41
Dont profondeur ≥ 25 $ (estimé sur l'échantillon) ~200 ~29

Avec ses trois tailles (0,05 / 0,10 / 0,20 SOL) et une vingtaine de positions par jour, le capital immobilisé à un instant donné reste de l'ordre de 2 à 5 SOL.

Ses autres règles, non testées ici

Règle Ce qu'il dit
Trois tailles selon la conviction 0,05 SOL (distribution correcte seulement), 0,1–0,15 SOL (méta + Twitter actif), 0,2–0,3 SOL (équipe connue)
Renforcement « If I see that the pool is generating good fees and the price hasn't pumped too much yet, I increase the position size up to 2x »
Sortie sur capitalisation Fermer si la capitalisation passe sous 50 k$
Sortie temporelle Chercher la sortie vers 45 min, quand le frais est retombé à ~20 %

Le renforcement conditionnel est la seule de ces règles qui pourrait significativement améliorer le résultat mesuré, et elle est testable — mais elle demande une reconstruction pas-à-pas que l'échantillon actuel ne permet pas.


Les limites de cette mesure

Sept réserves

1. Une semaine, 139 à 151 pools sur 758. Court.

2. La profondeur est estimée, pas mesurée. L'estimateur par impact de prix est bruité ; il donne un ordre de grandeur, pas une valeur.

3. Les frais du pool sont supposés inchangés quand on le rejoint. Borne basse. La borne haute (frais proportionnels à la profondeur) donne +22,3 % au lieu de +2,9 % sans filtre.

4. Aucun filtre de qualité de token hors le proxy holders. Ses critères Axiom devraient améliorer le résultat.

5. L'entrée est modélisée à la première bougie de 5 minutes. Lui agit en 20-30 secondes ; un bot en moins d'une seconde. La granularité disponible ne permet pas de mesurer ce que coûte le retard.

6. Les effectifs des meilleures combinaisons sont faibles (n = 9 à 21). Les pourcentages à trois chiffres ne doivent pas être pris au pied de la lettre.

7. La concurrence n'est pas modélisée. Une stratégie publiée s'érode.


Verdict révisé

Le rendement n'est pas établi

Après retrait du biais de look-ahead, la meilleure configuration honnête donne +7,6 % par position sur 33 positions — et −0,5 % si l'on retire la meilleure. Sur une semaine, avec ces effectifs, aucun chiffre de rendement n'est défendable.

Ce qui tient malgré tout

  • Fenêtre confirmée : 76 % des frais dans les 45 premières minutes.
  • La dilution n'est pas un problème : ces pools pèsent 9 $ en médiane, un dépôt de 0,23 SOL en prend 65 %.
  • Rejoindre un pool déjà profond bat créer en confort d'exécution : 76 % de réussite et une médiane positive, contre 29 % et −0,90 $.
  • La profondeur existante est le meilleur filtre de tout ce rapport, et il est purement calculatoire.

Ce qui reste vrai

Le dépôt bilatéral impose de détenir le token : la perte maximale par position reste de 100 %. C'est supportable uniquement parce que les positions font 4 à 22 $.

Le dimensionnement n'est pas un détail de la stratégie — c'est la stratégie. Le fil le dit en conclusion : « Remember that DAMMv2 is significantly riskier compared to DLMM, so adjust the amount you're willing to risk accordingly. »


Méthode

Univers : les 758 pools DAMM v2 dotés d'un fee scheduler créés entre le 23 et le 30 juillet 2026. Échantillon systématique de 160, dont 151 avec séries 5 minutes complètes et 139 avec profondeur estimable.

Modèle : entrée à la première bougie 5 min, dépôt 0,23 SOL, frais LP = fees − protocol_fees, part = \(D/(T+D)\) avec \(T\) estimée par impact de prix, valeur de position \(D\sqrt{P_t/P_0}\).

Toutes les mesures proviennent de l'API publique Meteora. Les outils cités par l'auteur — damm.dlmm.me, rocketscan.fun, hanyon.app, metlex.io, axiom.trade — n'ont pas été utilisés.