Exécution, automatisation et risques¶
Le cycle complet, manuellement¶
1. Détecter¶
Requête API du chapitre précédent, ou à la main via l'interface Meteora en triant les pools DAMM v2 par date de création.
@L0cc a publié un fil dédié à cette question : « how to spot or access the newly created DLMM or DAMM pools so you can enter and set-up a play quickly ».
2. Vérifier¶
Les neuf seuils, plus la checklist de screening complète. Le parcours de filtrage de @magickaisded, modérateur LP Army et spécialiste DAMM v2, commence d'ailleurs sur Jupiter — relayé par @olawande0x.
3. Entrer¶
Sur l'interface Meteora : sélectionner le pool, cliquer Add Liquidity.
Ce qui se passe réellement à cet instant
Le dépôt étant bilatéral, l'interface va acheter le token pour vous si vous n'en détenez pas, ou vous demander de fournir les deux côtés.
Vous passez donc d'une position 100 % SOL à une position ~50 % token en une transaction, au prix du marché, sur un actif qui vient de migrer.
C'est l'instant le plus risqué de toute la stratégie, et il est irréversible sans coût.
Points de vigilance à l'entrée :
| Point | Détail |
|---|---|
| Slippage | Sur un pool jeune et peu profond, le slippage d'entrée est réel |
| Taille | Restez sous 5 % de la TVL du pool, sinon vous diluez le rendement visé |
| Frais de priorité | Configurez-les avant : la fenêtre se joue en minutes |
4. Encaisser¶
Rien à faire. Les frais s'accumulent dans la position. Si le pool est en mode de collecte token de cotation seul — cas majoritaire — ils s'accumulent directement en SOL ou USDC.
En mode compounding, ils sont réinjectés automatiquement dans la position.
Réclamer régulièrement
Les frais accumulés dans une position ne sont pas à l'abri : en mode BothToken, une partie s'accumule dans le memecoin et se déprécie avec lui.
Réclamez au moins une fois par jour tant que la position est ouverte.
5. Sortir¶
C'est là que tout se joue, comme toujours.
Les règles applicables, adaptées du chapitre gestion et sortie :
| Règle | Seuil concret pour cette stratégie |
|---|---|
| Sur effondrement du volume | volume.1h passe sous 20 % de son pic → sortir |
| Sur âge | 72 h après la migration, quel que soit l'état → sortir |
| Sur objectif | Frais cumulés ≥ 5 % du dépôt → sortir |
| Sur perte | Le token perd X % → sortir, X décidé avant l'entrée |
La règle la plus adaptée ici
La sortie sur âge.
Sur les autres stratégies du rapport, la sortie sur temps est un pis-aller. Ici, elle est la meilleure : la mesure du chapitre précédent montre que le rendement médian s'effondre d'un facteur 30 après la première semaine.
Il n'y a strictement aucune raison de rester. La question n'est pas « est-ce que ça peut encore monter ? » mais « est-ce que le pool génère encore des frais ? », et la réponse statistique après 72 h est non.
Ce qui est automatisable — et ce qui ne l'est pas¶
Votre intuition était que c'est « limite automatisable ». C'est vrai pour deux étapes sur quatre.
| Étape | Automatisable ? | Pourquoi |
|---|---|---|
| Détection | Totalement | Événement on-chain daté, exposé par API publique, aucun jugement requis |
| Filtrage quantitatif | Totalement | Les neuf seuils sont des comparaisons numériques |
| Filtrage qualitatif | Non | Bubblemaps, cohérence détenteurs/volume, sérieux du lancement : jugement |
| Entrée | Techniquement oui | SDK disponible, mais c'est là que se joue tout le risque |
| Suivi | Totalement | Polling de volume.1h et fees.1h |
| Sortie | Techniquement oui | Une règle d'âge et une règle de volume sont codables |
Les briques techniques¶
| Brique | Outil |
|---|---|
| Données | https://damm-v2.datapi.meteora.ag/pools — REST, sans clé |
| Programme on-chain | cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG |
| SDK | @meteora-ag/cp-amm-sdk |
| Installation | npm install @meteora-ag/cp-amm-sdk @solana/web3.js @coral-xyz/anchor bn.js |
| Lecture d'état | await cpAmm.fetchPoolState(pool) |
Le SDK couvre « full transaction flows, including pool initialization, swaps, liquidity, and more ». Des bindings Rust et Go existent également, ainsi qu'une interface CPI pour l'intégration programme-à-programme.
L'architecture minimale raisonnable
Un script qui interroge l'API toutes les 60 secondes, applique les neuf seuils, et vous envoie une notification avec le lien du pool.
Pas d'exécution automatique. Vous gardez la décision d'entrée — c'est-à-dire la seule étape où votre jugement a de la valeur et où une erreur coûte 100 %.
C'est le même principe que DLMM Alert dans le répertoire d'outils : lecture seule, aucune transaction, aucun droit de signature.
Pourquoi ne pas automatiser l'entrée
Trois raisons, dans l'ordre d'importance :
-
Le filtre qualitatif n'est pas codable. Un pool peut satisfaire les neuf seuils numériques et être un piège construit exactement pour satisfaire ces seuils. Un bot qui entre sur signal quantitatif est un bot que l'on peut nourrir.
-
Un bot d'exécution a besoin de votre clé. Une clé privée sur une machine qui exécute du code réseau est un risque d'un autre ordre que tout ce qui précède.
-
L'espérance n'est pas établie. Automatiser une stratégie dont vous n'avez pas mesuré vous-même l'espérance, c'est industrialiser une perte potentielle. Faites vingt cycles à la main d'abord.
L'inventaire des risques propres à DAMM v2¶
En complément de l'inventaire général.
Risques structurels¶
| Risque | Ampleur |
|---|---|
| Dépôt bilatéral obligatoire | Perte maximale = 100 %. Pas de mono-actif possible |
| Perte divergente non bornée | 90 % des pools sont en full range : aucune borne basse |
| Frais protocole de 20 % | Le double du DLMM standard |
| Dilution par la liquidité verrouillée | ~93 % de la TVL médiane appartient déjà au créateur |
| Frais de migration 0,2 % | Prélevé sur la liquidité entrant dans le pool |
Risques spécifiques à la fenêtre¶
Le scénario d'échec type
- Un pool migre, le volume est spectaculaire pendant deux heures.
- Vous entrez : vous achetez la moitié de votre dépôt en token.
- Le volume s'effondre en fin de journée.
- Le token perd 60 % dans la semaine.
- Vous avez encaissé 3 % de frais et perdu 30 % du dépôt.
Ce scénario est le cas modal, pas le cas défavorable. C'est exactement ce que dit la mesure : 51 % des pools de plus de 30 jours ne font plus aucun volume, ce qui signifie que la grande majorité des tokens migrés meurent.
Risques de manipulation¶
| Vecteur | Description |
|---|---|
| Volume fabriqué | Vous entrez sur un signal de volume ; c'est le signal le plus facile à falsifier |
| Bundling | Un groupe coordonné détient l'offre et vend sur votre liquidité |
| Pool piégé | Voir les 5 étapes anti-rug de LP Army |
Le seul montage qui rend la stratégie jouable¶
C'est celui de @skolmbeagh, et le paramètre qui compte n'est pas celui qu'on remarque en premier.
« +118 SOL PnL in 45 days with an average deposit of just 0,4 SOL per position. »
Pourquoi 0,4 SOL est le vrai enseignement
Face à une distribution de rendements où la médiane est à 1 %/jour mais où le 90ᵉ centile est à 13–18 %/jour, et où la perte peut être totale, la stratégie correcte est le nombre de paris, pas leur taille.
Beaucoup de petites positions : la plupart perdent un peu, quelques-unes rapportent beaucoup, et aucune ne peut vous sortir du jeu.
Une grosse position sur la mauvaise migration efface le mois. C'est mathématiquement le même raisonnement que la règle de dimensionnement du Rabbit Strat — indexer l'exposition sur la qualité du signal — appliquée à une distribution à queue épaisse.
Traduction en règles¶
| Règle | Valeur |
|---|---|
| Taille par position | Un montant dont la perte totale est indifférente |
| Nombre de positions simultanées | 5 à 15 |
| Part du capital total engagée | ≤ 10 % |
| Durée maximale d'une position | 72 h |
| Part maximale de la TVL du pool | 5 % |
Verdict final¶
Ce que la stratégie a vraiment pour elle
- Un signal objectif et gratuit, exposé par API publique.
- Aucune gestion de plage : la simplicité opérationnelle est réelle.
- Des frais de base structurellement élevés (1 à 4 %).
- Un revenu majoritairement encaissé en token de cotation.
- Une décroissance du rendement mesurable, donc une règle de sortie objective : 72 heures.
Ce qui la disqualifie comme stratégie principale
- La perte maximale n'est pas calculable avant l'entrée.
- Le rendement médian ne couvre pas la perte divergente typique.
- Le filtre qui compte — la qualité du lancement — n'est pas automatisable.
Recommandation
Traitez-la comme la poche spéculative du parcours C, pas comme le socle : 5 à 10 % du capital, en petites positions nombreuses, avec une sortie à 72 heures écrite avant la première entrée.
Construisez d'abord le détecteur en lecture seule et observez-le pendant deux semaines sans entrer. Vous aurez alors votre propre mesure de l'espérance, sur vos propres critères — ce qu'aucun fil X ne vous donnera.
C'est le même exercice que le screening à blanc du parcours B, et c'est le seul moment où l'apprentissage est gratuit.