diff --git a/CHANGELOG.md b/CHANGELOG.md index 05c2807..3d05580 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -69,3 +69,4 @@ 0.7.36 - Consolidation de la famille Meteora : corpus mixte `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc` et `meteora_dlmm`, correction des discriminants DAMM v2 / DBC, validation du profil `0.7.36_meteora_family_consolidation`, et reclassement explicite des swaps DAMM v2 / DBC sans payload montant/prix en `non_actionable_trade` afin d’éviter tout trade/candle artificiel. 0.7.37 - Première tranche metadata/catalog : ajout du profil `0.7.37_token_metadata_catalog_enrichment`, exposition des compteurs metadata dans diagnostics/validation et raccordement UI Demo Pipeline 2 sans rendre les metadata manquantes bloquantes. 0.7.38 - Priorisation des metadata manquantes : ajout du profil `0.7.38_token_metadata_gap_prioritization`, samples `tokenMetadataGapSamples`, priorités tradable/quote/catalog, raccordement UI Demo Pipeline 2 et maintien du caractère non bloquant des metadata incomplètes. +0.7.39 - Tranche sûre launch surfaces : ensemencement contrôlé des origins LaunchLab/Launchpad/LetsBonk/Bonk.fun/Bags/Moonshot/Moonit/Boop.fun/Believe, Heaven préparé mais désactivé, mappings génériques vérifiés, samples diagnostics `launchOriginSamples` / `poolOriginSamples`, profil `0.7.39_launch_surface_origin_baseline`, raccordement Demo Pipeline 2 et maintien de l’invariant sans faux trade/candle ni program id fictif. diff --git a/Cargo.toml b/Cargo.toml index 0b9061b..e59a304 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -8,7 +8,7 @@ members = [ ] [workspace.package] -version = "0.7.38" +version = "0.7.39" edition = "2024" license = "MIT" repository = "https://git.sasedev.com/Sasedev/khadhroony-bobobot" diff --git a/README.md b/README.md index cc506d4..123017c 100644 --- a/README.md +++ b/README.md @@ -4,15 +4,15 @@ `khadhroony-bobobot` est un workspace Rust destiné à la détection, au décodage, à l’analyse et, à terme, au trading semi-automatisé de tokens Solana. -Le README précédent décrivait surtout l’état `0.3.1`. Ce fichier reflète l’état de clôture `0.7.38` et la reprise prévue en `0.7.39` : le socle transport HTTP/WS, la résolution transactionnelle, le modèle SQLite, plusieurs connecteurs DEX, les candles, les signaux analytiques, la validation locale, la matrice DEX commune et les diagnostics de metadata prioritaires existent déjà. +Le README précédent décrivait surtout l’état `0.3.1`. Ce fichier reflète l’état de clôture `0.7.38-B` et la réorientation de travail `0.7.39 DEX-first` : le socle transport HTTP/WS, la résolution transactionnelle, le modèle SQLite, plusieurs connecteurs DEX, les candles, les signaux analytiques, la validation locale, la matrice DEX commune et les diagnostics de metadata prioritaires existent déjà. La prochaine phase donne la priorité aux DEX effectifs sur lesquels les swaps et événements de marché sont observables, avant de revenir aux launch surfaces. ## 1. Objectif L’objectif opérationnel est de construire progressivement une application capable de : - détecter l’apparition de nouveaux tokens, pools, paires et listings sur Solana ; -- identifier la première source de mint ou de lancement, même lorsque le token migre ensuite vers un autre DEX ; -- décoder les transactions pertinentes des DEX et launch surfaces ciblés ; +- identifier en priorité les DEX effectifs sur lesquels les swaps, liquidités et événements de marché sont réellement exécutés ; +- décoder les transactions pertinentes des DEX ciblés, puis seulement ensuite les launch surfaces et origines de mint/lancement ; - séparer les swaps/candles des événements utiles seulement à l’analyse : liquidité, cycle de vie de pool, fees, rewards, administration, wallets observés ; - produire des métriques exploitables : prix, volume, candles/OHLCV, activité, bursts, déséquilibres buy/sell, signaux analytiques ; - préparer ensuite des règles déterministes de filtrage, d’achat, de vente, de stop-loss et de trailing stop ; @@ -31,7 +31,7 @@ Le workspace contient deux crates principales. La logique métier doit rester dans `kb_lib`. `kb_demo_app` doit rester une façade UI/Tauri et ne doit pas récupérer de logique Solana ou DEX profonde. -## 3. État actuel après `0.7.38` +## 3. État actuel après `0.7.38-B` ### 3.1. Socle stabilisé à ne pas refactorer maintenant @@ -74,16 +74,20 @@ Les connecteurs suivants sont les surfaces actuellement les plus importantes pou - `meteora_damm_v2`, observé dans le corpus `0.7.36`, mais les swaps sans payload montant/prix exploitable sont maintenant `non_actionable_trade` ; - `meteora_dbc`, observé dans le corpus `0.7.36`, mais les swaps sans payload montant/prix exploitable sont maintenant `non_actionable_trade`. -### 3.4. Connecteurs déjà présents mais à consolider par corpus +### 3.4. Connecteurs à consolider par corpus en priorité DEX-first -Les modules suivants existent ou sont partiellement représentés dans le code, mais doivent encore être consolidés par corpus local, invariants et documentation : +Les modules ou surfaces suivantes existent, sont partiellement représentés dans le code ou doivent être recherchés, mais doivent être consolidés par corpus local, invariants et documentation avant de reprendre les launch surfaces : +- `raydium_amm_v4` legacy ; +- `raydium_stable_swap` ; - `orca_whirlpools` ; - `fluxbeam` ; - `dexlab` ; -- `raydium_amm_v4` legacy ; -- launch origins déjà amorcées : `meteora_fun_launch`, `bags`, `moonit` ; -- launch surfaces à venir : `raydium_launchlab`, `raydium_launchpad`, `letsbonk` / `bonk`, `boop_fun`, `moonshot`, `believe`, `heaven`. +- `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc` et `meteora_dlmm` pour la couverture non-trade complète ; +- `metaDAO` et `printr`, apparus comme DEX à vérifier côté sources externes de découverte ; +- tout DEX ou programme récurrent détecté dans `k_sol_protocol_candidates`, DEX Screener ou les transactions locales. + +Les launch origins déjà amorcées (`meteora_fun_launch`, `bags`, `moonit`) et les launch surfaces enregistrables (`raydium_launchlab`, `raydium_launchpad`, `letsbonk`, `bonk_fun`, `bags`, `moonshot`, `moonit`, `boop_fun`, `believe`, `heaven`) sont conservées dans la documentation, mais elles ne sont plus prioritaires tant que les DEX effectifs ne sont pas suffisamment couverts. ### 3.5. Validation acquise en `0.7.36` @@ -100,13 +104,13 @@ La validation `0.7.36_meteora_family_consolidation` est considérée comme réal Point important : `meteora_damm_v2` et `meteora_dbc` peuvent produire beaucoup d’événements `swap` décodés sans produire de `trade_events` lorsque les montants ou prix ne sont pas fiables. Ces événements doivent rester `non_actionable_trade` et ne doivent pas être comptés comme `tradeCandidate` ou `candleCandidate`. -## 4. Matrice DEX et launch surfaces +## 4. Matrice DEX : DEX effectifs d’abord, launch surfaces ensuite -La distinction importante est la suivante : +La distinction de travail à partir de `0.7.39` est la suivante : -- un **DEX effectif** permet de détecter et décoder des swaps, pools, liquidité et candles ; -- une **launch surface** peut être la première source de mint ou de lancement, même si le token migre ensuite vers Raydium, Meteora ou un autre AMM ; -- pour le trading, la première source de mint est une information de filtrage et de ciblage aussi importante que le DEX final. +- un **DEX effectif** est un programme ou une famille de programmes sur lesquels des swaps, pools, liquidités, fees, rewards, admin/config, burns ou mints utiles sont réellement observables ; +- une **launch surface** peut être la première source de mint ou de lancement, mais elle ne doit pas masquer la priorité donnée aux programmes où le swap final est exécuté ; +- pour le trading, le DEX effectif, la qualité de décodage du swap et les événements de pool sont prioritaires ; la launch origin reste une information de filtrage à réintroduire après stabilisation des DEX. ### 4.1. Matrice de travail @@ -118,31 +122,25 @@ Depuis `0.7.32`, les diagnostics distinguent explicitement les gaps littéraux d Depuis `0.7.33`, les diagnostics ajoutent une classification `pairTradingReadiness` au niveau des paires et des résumés agrégés `pairTradingReadinessSummaries`. Cette classification sépare les paires directement lisibles/tradables contre WSOL ou stable, les paires inversées avec WSOL/stable en base, les paires cross-quote nécessitant un routeur/aggregator, les paires non matérialisées en trade et les cas de quote inconnue. Elle reste purement diagnostique : elle ne modifie ni le replay, ni les `trade_events`, ni les candles. -| Code cible | Type | Statut `0.7.29` | Prochaine action | +| Code cible | Type | Priorité `0.7.39+` | Prochaine action | |---|---:|---|---| -| `pump_fun` | Launch + bonding curve | partiel | verrouiller le rattachement mint initial -> pools migrés | -| `pump_swap` | AMM / swap | supporté | conserver invariants trade/candle | -| `raydium_cpmm` | AMM | supporté | conserver invariants trade/candle | -| `raydium_clmm` | CLMM | supporté | conserver invariants trade/candle | -| `raydium_launchlab` | Launch surface | planifié, program id local connu | ajouter decoder/materialization dédiée | -| `raydium_launchpad` | Launch surface | à vérifier | ne pas inventer de program id | -| `raydium_amm_v4` | AMM legacy | partiel | traiter après les autres Raydium avec corpus dédié | -| `meteora_dlmm` | DLMM | supporté | verrouiller corpus et non-régression | -| `meteora_damm_v1` | AMM legacy | partiel validé | conserver le skip explicite des swaps sans montants exploitables | -| `meteora_damm_v2` | AMM | partiel validé `0.7.36` | conserver les swaps sans amounts en `non_actionable_trade`; ajouter extraction de montants seulement avec preuve | -| `meteora_dbc` | Launch / bonding curve | partiel validé `0.7.36` | conserver les swaps sans amounts en `non_actionable_trade`; étudier migration / launch origin | -| `meteora_dlc` | À vérifier | à vérifier | confirmer surface/program id avant intégration | -| `orca_whirlpools` | CLMM | partiel | corpus fiable et validation des instructions utiles | -| `fluxbeam` | AMM | partiel | corpus fiable avant validation | -| `dexlab` | AMM | partiel | corpus fiable avant validation | -| `bags` | Launch surface | planifié | conserver comme origine de lancement si corpus le prouve | -| `letsbonk` / `bonk` | Launch surface | planifié | ajouter comme origine de mint/lancement sans supposer un AMM autonome | -| `okx_dex` | Aggregator/router | planifié | classifier sans matérialiser en trade direct avant preuve | -| `boop_fun` | Launch surface | planifié | ajouter comme origine de mint/lancement et migration | -| `moonshot` / `moonit` | Launch surface | planifié | remplacer les heuristiques faibles par corpus et règles prouvées | -| `believe` | Launch surface | planifié | confirmer comptes, migration et rattachement | -| `heaven` | Launch + AMM candidat | planifié | ajouter corpus et déterminer séparation launch/swap | -| `zora` | À vérifier | à vérifier | ne pas intégrer avant preuve de programme Solana pertinent | +| `pump_swap` | AMM / swap | haute | conserver les invariants trade/candle et étendre les événements non-trade prouvés. | +| `raydium_cpmm` | AMM | haute | vérifier corpus swap/liquidité/admin et maintenir la matérialisation trade/candle. | +| `raydium_clmm` | CLMM | haute | vérifier corpus swap/liquidité/position et maintenir la matérialisation trade/candle. | +| `raydium_amm_v4` | AMM legacy | haute | rechercher des paires/pools réels pour `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, valider `initialize2` et identifier les swaps. | +| `raydium_stable_swap` | AMM legacy | moyenne | vérifier l’usage réel de `5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h` et ne l’activer qu’avec corpus. | +| `meteora_dlmm` | DLMM | haute | verrouiller swaps, positions, liquidité et lifecycle. | +| `meteora_damm_v1` | AMM legacy | haute | conserver le skip sans amounts exploitables et rechercher un corpus swap/liquidité exploitable. | +| `meteora_damm_v2` | AMM | haute | vérifier `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG`, les swaps, les configs dynamiques et les événements non-trade. | +| `meteora_dbc` | bonding curve / DEX effectif partiel | haute | séparer ce qui relève du swap, du bonding curve et de la migration sans faux trade/candle. | +| `orca_whirlpools` | CLMM | haute | consolider par corpus fiable : create_pool, swap, liquidité/positions. | +| `fluxbeam` | AMM | moyenne | vérifier program id, corpus réel et instructions utiles. | +| `dexlab` | AMM | moyenne | vérifier program id, corpus réel, swaps et liens OpenBook éventuels. | +| `metaDAO` | DEX à vérifier | haute | rechercher le ou les program ids, corpus, comptes et types d’événements avant toute promotion. | +| `printr` | DEX à vérifier | haute | rechercher le ou les program ids, corpus, comptes et types d’événements avant toute promotion. | +| `okx_dex` | Aggregator/router | basse DEX direct | classifier sans matérialiser en trade direct avant preuve. | +| Launch surfaces (`pump_fun`, `raydium_launchlab`, `raydium_launchpad`, `bags`, `letsbonk`, `bonk_fun`, `boop_fun`, `moonshot`, `moonit`, `believe`, `heaven`) | Launch / origine | reportée | reprendre après consolidation des DEX effectifs ; aucun `program_id` fictif. | +| `zora` | À vérifier | hors priorité | ne pas intégrer avant preuve de programme Solana pertinent. | ## 5. Base de données @@ -232,18 +230,32 @@ Les tests peuvent rester plus souples lorsque cela clarifie le test. ## 8. Priorité immédiate -La phase `0.7.38_token_metadata_gap_prioritization` est considérée comme close. La clôture `0.7.38-B` ajoute un registre local minimal de tokens connus : `WSOL`, `USDC`, `USDT`, `JUP`, `RAY`, `BONK`. `USDC` et `USDT` restent les seuls ajouts stable-quote ; `JUP`, `RAY` et `BONK` enrichissent seulement l’affichage metadata sans changer la classification de quote. La prochaine étape est `0.7.39_launch_surfaces`. +La phase `0.7.38_token_metadata_gap_prioritization` est considérée comme close. La clôture `0.7.38-B` ajoute un registre local minimal de tokens connus : `WSOL`, `USDC`, `USDT`, `JUP`, `RAY`, `BONK`. `USDC` et `USDT` restent les seuls ajouts stable-quote ; `JUP`, `RAY` et `BONK` enrichissent seulement l’affichage metadata sans changer la classification de quote. + +La prochaine étape est maintenant `0.7.39_dex_first_effective_swap_surfaces`. Elle remplace la priorité précédemment donnée aux launch surfaces. L’objectif est de vérifier et consolider d’abord les vrais DEX de swap et leurs événements observables. Préconditions validées avant de reprendre le codage : 1. les invariants locaux restent sains : `blockingIssueCount = 0`, `actionableMissingTradeEventCount = 0`, `missingTradeEventCount = 0` ; 2. les profils `0.7.36_meteora_family_consolidation`, `0.7.37_token_metadata_catalog_enrichment` et `0.7.38_token_metadata_gap_prioritization` existent et passent sur le corpus local fourni ; 3. les metadata manquantes restent non bloquantes ; -4. les `tokenMetadataGapSamples` exposent maintenant une liste de travail priorisée ; -5. le registre local minimal contient `SOL`, `WSOL`, `USDC` et `USDT` ; +4. les `tokenMetadataGapSamples` exposent une liste de travail priorisée ; +5. le registre local minimal contient `SOL`, `WSOL`, `USDC`, `USDT`, `JUP`, `RAY` et `BONK` ; 6. le backfill metadata peut traiter les tokens déjà présents en base et rafraîchir les `pair_symbol` sans recréer les objets de marché. -Objectif de `0.7.39` : détecter et rattacher les surfaces de lancement sans inventer de program ids, sans produire de faux trades/candles et sans confondre `launch_origin`, `pool_origin`, `dex_effective` et `migration_target`. +Objectifs `0.7.39+` : + +- inventorier et vérifier les DEX principaux sur lesquels des swaps peuvent réellement se produire ; +- rechercher ou confirmer les `program_id` inconnus sans en inventer ; +- ajouter `metaDAO` et `Printr` comme DEX à vérifier, notamment via DEX Screener et corpus local ; +- couvrir, par DEX, les swaps, liquidités, lifecycle, fees, rewards, admin/config, burns/mints utiles et autres événements non-trade prouvés ; +- ajouter `Demo3` pour rechercher les pools/paires/signatures par DEX ou `program_id` ; +- ajouter `Demo4` pour interroger DEX Screener et comparer les résultats avec la base locale ; +- préparer des démos spécialisées pour les launch surfaces seulement après stabilisation des DEX effectifs ; +- ajouter une démo temps réel type `Demo10` avec start/stop du client WebSocket, souscriptions aux programmes DEX et écriture en base via le pipeline existant ; +- passer ensuite à la création de wallets, aux fonctions wallet et aux transferts de fonds avant toute logique de swap/trading. + +Les launch surfaces restent importantes, mais elles sont reportées après la consolidation des DEX effectifs. Elles ne doivent pas générer de faux trades/candles ni de `program_id` fictif. ## 9. Fichiers utiles pour reprendre dans une nouvelle session @@ -271,4 +283,4 @@ Pour reprendre rapidement le codage dans une nouvelle session, fournir au minimu - `kb_lib/src/db/dtos.rs` et `kb_lib/src/db/dtos/*` ; - `kb_lib/src/db/queries.rs` et `kb_lib/src/db/queries/*`. -Ajouter `kb_demo_app/src/demo_pipeline*.rs` seulement si la tâche concerne l’UI ou les diagnostics affichés. +Ajouter `kb_demo_app/src/demo_pipeline*.rs`, les fichiers frontend associés et les nouvelles démos (`Demo3`, `Demo4`, `Demo10`) seulement si la tâche concerne l’UI, la recherche de corpus, les diagnostics affichés ou le watcher temps réel. diff --git a/ROADMAP.md b/ROADMAP.md index 1ae4b4a..017d7f2 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -942,195 +942,182 @@ Réalisé : - validation locale confirmée avec `validationPassed = true`, `blockingIssueCount = 0`, `missingTradeEventCount = 0`, `decodedTradeCandidateWithoutTradeEventCount = 0` ; - les samples permettent de sélectionner les prochains mints à enrichir via registre local, payloads DEX, Token-2022, Metaplex ou backfill HTTP. -Décision : `0.7.38` est clos. La clôture `0.7.38-B` conserve la logique de stable quotes limitée à `USDC`/`USDT` et ajoute un registre metadata local pour `JUP`, `RAY` et `BONK` sans les classer automatiquement comme quotes. La suite de développement commence à `0.7.39` avec les launch surfaces. +Décision : `0.7.38` est clos. La clôture `0.7.38-B` conserve la logique de stable quotes limitée à `USDC`/`USDT` et ajoute un registre metadata local pour `JUP`, `RAY` et `BONK` sans les classer automatiquement comme quotes. La suite de développement commence à `0.7.39` avec une priorité DEX-first : consolider les DEX effectifs de swap avant de revenir aux launch surfaces. -### 6.071. Version `0.7.39` — Launch surfaces : LaunchLab, LetsBonk, Bags, Moonshot/Moonit, Boop.fun, Believe -Objectif : détecter la première source de mint/lancement des tokens même lorsque le swap final se fait ailleurs. +### 6.071. Version `0.7.39` — Réorientation DEX-first et inventaire des DEX effectifs +Objectif : remplacer la priorité précédemment donnée aux launch surfaces par une consolidation des vrais DEX sur lesquels les swaps et événements de marché sont exécutés. À faire : -- ajouter ou stabiliser `raydium_launchlab` / `raydium_launchpad`, -- ajouter `letsbonk` / `bonk_fun` comme surface d’origine rattachée à LaunchLab/Raydium si le corpus le prouve, -- ajouter `boop_fun` comme surface d’origine et suivre ses migrations, -- consolider `moonshot` / `moonit` avec corpus au lieu de simples heuristiques faibles, -- consolider `bags` comme surface d’origine, notamment lorsque le token passe par Meteora DBC/DAMM, -- ajouter `believe` comme surface d’origine associée à Meteora DBC si les comptes/authorities le prouvent, -- distinguer `launch_origin`, `pool_origin`, `dex_effective` et `migration_target`, -- rattacher les launch origins aux pools et paires lorsque les comptes permettent un matching fiable, -- exposer les origins dans les diagnostics et l’UI d’inspection. +- modifier la matrice DEX pour distinguer explicitement : `dex_effective`, `aggregator/router`, `launch_surface`, `to_verify` ; +- vérifier les DEX de swap principaux déjà connus : `pump_swap`, `raydium_cpmm`, `raydium_clmm`, `raydium_amm_v4`, `raydium_stable_swap`, `meteora_dlmm`, `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc`, `orca_whirlpools`, `fluxbeam`, `dexlab` ; +- ajouter `metaDAO` et `Printr` comme entrées `to_verify` dans la matrice, sans `program_id` tant qu’ils ne sont pas prouvés ; +- rechercher ou confirmer les `program_id` inconnus depuis les corpus locaux, les protocol candidates, DEX Screener, les explorateurs et les transactions résolues ; +- ne promouvoir aucune entrée vers `partial` ou `supported` sans corpus transactionnel vérifiable ; +- conserver les invariants `0.7.36` à `0.7.38` : aucun faux trade, aucune fausse candle, aucun événement non price-action transformé en trade/candle. -### 6.072. Version `0.7.39` — Heaven : corpus, launch et AMM -Objectif : ajouter Heaven sans le classer trop tôt comme simple DEX ou simple launchpad. +Résultat attendu : une matrice DEX réorientée vers les surfaces de swap effectives, avec les launch surfaces explicitement reportées. + +### 6.072. Version `0.7.40` — Raydium effectif : AMM v4, Stable Swap, CPMM, CLMM +Objectif : consolider la famille Raydium côté DEX effectifs avant les launch surfaces Raydium. À faire : -- vérifier le ou les programmes Heaven réellement observés sur mainnet, -- constituer un corpus local de mints, pools et swaps Heaven, -- séparer les événements de lancement des événements de swap, -- ajouter les decoded events, launch origins, pool/pair/listing et trade events seulement lorsque les instructions sont prouvées, -- documenter les limites si le corpus ne permet pas encore de matérialiser tous les événements, -- vérifier que Heaven ne crée pas de candles invalides en cas d’événement de launch non pricé. +- vérifier `raydium_cpmm` et `raydium_clmm` comme références déjà supportées ; +- rechercher des pools réellement rattachés au programme AMM v4 `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8` ; +- vérifier l’usage réel de `raydium_stable_swap` et du programme `5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h` ; +- distinguer clairement `raydium_amm_v4`, `raydium_cpmm`, `raydium_clmm`, `raydium_router`, `raydium_stable_swap`, `raydium_launchlab` et `raydium_launchpad` ; +- identifier les instructions swap, initialize/create pool, liquidité, fees/admin réellement observées ; +- ajouter des requêtes diagnostics par `program_id`, `accounts_json`, `data_json`, signature et pool address ; +- documenter les limites si le corpus Raydium legacy reste faible. -### 6.073. Version `0.7.40` — Orca / FluxBeam / DexLab : corpus et validation ciblée -Objectif : consolider les connecteurs déjà présents à partir de corpus locaux vérifiables. +### 6.073. Version `0.7.41` — Meteora effectif : DLMM, DAMM v1/v2, DBC +Objectif : compléter la famille Meteora en couvrant les événements réellement utiles au DEX effectif. À faire : -- constituer des corpus locaux pour `Orca Whirlpools`, `FluxBeam` et `DexLab`, -- vérifier les `program_id`, comptes, préfixes `data_json` et familles d’instructions utiles, -- stabiliser les événements `create_pool`, `swap` et liquidité réellement observés, -- alimenter les mêmes tables métier et diagnostics que les connecteurs déjà validés, -- marquer explicitement les variantes partiellement supportées ou heuristiques, -- rejouer les corpus plusieurs fois pour vérifier l’idempotence et l’absence de trades/candles invalides. +- conserver la validation `0.7.36` : les swaps DAMM v2 / DBC sans amounts fiables restent `non_actionable_trade` ; +- vérifier `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG` et les autres programmes Meteora dans le corpus local ; +- consolider `meteora_dlmm` pour swaps, positions, add/remove liquidity, lifecycle et non-trade events ; +- consolider `meteora_damm_v1` et `meteora_damm_v2` pour pools, swaps exploitables, configs dynamiques, fees/admin ; +- clarifier la part `launch/bonding_curve` et la part `dex_effective` de `meteora_dbc` ; +- éviter tout trade/candle artificiel lorsque les montants ou prix ne sont pas prouvés. -### 6.074. Version `0.7.41` — Raydium AMM v4 legacy : corpus et validation ciblée -Objectif : traiter le vrai Raydium AMM v4 historique après les autres Raydium, afin de l’isoler de `raydium_cpmm`, `raydium_clmm` et des labels Raydium génériques. +### 6.074. Version `0.7.42` — Autres DEX effectifs : Orca, FluxBeam, DexLab, metaDAO, Printr +Objectif : consolider les DEX non-Ray­dium/Meteora et intégrer les DEX récemment observés comme candidats vérifiables. À faire : -- rechercher des pools réellement rattachés au programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, -- constituer un petit corpus local de signatures/pools AMM v4 fiables, -- vérifier que les adresses issues d’explorateurs ne sont pas seulement catégorisées globalement comme `Raydium`, -- ajouter des requêtes de diagnostic par `program_id`, `accounts_json` et préfixe `data_json`, -- valider `initialize2` et identifier les instructions de swap AMM v4 à supporter si elles apparaissent dans le corpus, -- renommer/stabiliser les fonctions internes autour de `raydium_amm_v4` pour éviter l’ambiguïté avec `raydium_cpmm` et `raydium_clmm`, -- documenter les limites connues si le corpus AMM v4 reste faible. +- constituer des corpus locaux pour `orca_whirlpools`, `fluxbeam` et `dexlab` ; +- vérifier les `program_id`, comptes, préfixes `data_json` et familles d’instructions utiles ; +- stabiliser les événements `create_pool`, `swap`, liquidité, positions et admin lorsque prouvés ; +- ajouter `metaDAO` et `Printr` en `to_verify` avec recherche explicite de program ids, signatures, comptes et pools ; +- ne pas confondre source externe de découverte et preuve on-chain ; +- marquer explicitement les variantes partiellement supportées ou heuristiques. -### 6.075. Version `0.7.42` — Validation DEX v1 consolidée -Objectif : rejouer tous les DEX et launch surfaces supportés et valider les invariants du pipeline complet. +### 6.075. Version `0.7.43` — Couverture événementielle DEX : swap, liquidité, fees, rewards, admin, burns +Objectif : s’assurer que chaque DEX effectif expose les événements utiles au scoring et au risque sans polluer les trades/candles. À faire : -- rejouer des bases neuves couvrant tous les connecteurs DEX supportés, -- vérifier les compteurs globaux et par DEX : decoded events, trade events, liquidity events, lifecycle events, fee events, reward events, admin events, candles et analytic signals, -- contrôler que chaque famille d’événements alimente uniquement les tables métier prévues, -- vérifier les diagnostics bloquants et les samples d’anomalie, -- documenter les corpus utilisés pour chaque DEX/surface, -- conserver une matrice de support par DEX, variante, instruction et type d’événement, +- vérifier par DEX la couverture `swap` / `tradeCandidate` / `candleCandidate` ; +- vérifier par DEX la couverture liquidité : add/remove/increase/decrease/open/close position ; +- vérifier par DEX les événements lifecycle : create/init/migrate/pause/resume/close ; +- vérifier par DEX les fees, rewards, creator fees, protocol fees et admin/config ; +- vérifier les burns/mints utiles au suivi token/pool sans les transformer en price-action ; +- matérialiser uniquement les événements prouvés dans les tables dédiées ; +- ajouter des compteurs et samples diagnostics par DEX et par type d’événement ; +- conserver l’invariant : aucun fee/reward/admin/liquidity/lifecycle/burn non price-action ne produit de trade, metric ou candle. + +### 6.076. Version `0.7.44` — `kb_demo_app` Demo3 : recherche de paires/pools par DEX ou program id +Objectif : ajouter une fenêtre ou vue de démonstration dédiée à la constitution de corpus par DEX. + +À faire : + +- ajouter une `Demo3` dans `kb_demo_app` ; +- permettre la saisie d’un `program_id`, d’un `dex_code`, d’un `pool_address`, d’un `pair_id` ou d’un token mint ; +- rechercher dans la base locale les transactions, instructions, decoded events, pools, paires, listings et candidates associés ; +- fournir des presets pour les programmes à vérifier, par exemple `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, `5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h`, `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG` ; +- afficher les signatures candidates à backfill/replay ; +- garder `kb_demo_app` comme façade UI : toute requête métier doit rester dans `kb_lib`. + +### 6.077. Version `0.7.45` — `kb_demo_app` Demo4 : DEX Screener et sources externes de découverte +Objectif : utiliser des sources externes comme aides à la découverte de corpus sans les traiter comme vérité métier. + +À faire : + +- ajouter une `Demo4` pour interroger DEX Screener ou une source équivalente ; +- rechercher des paires par token mint, chain, DEX name, pool address ou program id lorsque disponible ; +- comparer les résultats externes avec les objets locaux : tokens, pools, pairs, listings, decoded events ; +- afficher les écarts : paire externe absente localement, pool local sans source externe, DEX label ambigu, program id manquant ; +- permettre de copier les signatures/adresses candidates pour backfill ; +- ne jamais promouvoir automatiquement un DEX, un `program_id` ou une paire sur la seule base d’une réponse externe. + +### 6.078. Version `0.7.46` — Démos spécialisées launch surfaces après DEX effectifs +Objectif : préparer des vues spécialisées pour les launch surfaces, mais seulement après stabilisation des DEX effectifs. + +À faire plus tard : + +- ajouter des démos dédiées à `pump_fun`, `raydium_launchpad` / `raydium_launchlab`, `believe`, `bags`, `moonshot` / `moonit`, `boop_fun`, `letsbonk` / `bonk_fun`, `heaven` ; +- distinguer `launch_origin`, `pool_origin`, `dex_effective` et `migration_target` ; +- rattacher les launch origins aux pools et paires uniquement lorsque les comptes permettent un matching fiable ; +- exposer les origins dans les diagnostics et l’UI d’inspection ; +- maintenir l’interdiction de faux program ids, faux trades et fausses candles. + +### 6.079. Version `0.7.47` — `kb_demo_app` Demo10 : watcher WebSocket live DEX +Objectif : valider le passage du replay/backfill vers l’observation temps réel contrôlée. + +À faire : + +- ajouter une démo temps réel type `Demo10` avec bouton `start` / `stop` ; +- permettre de sélectionner les endpoints WS/HTTP et les DEX/program ids à souscrire ; +- lancer le client WebSocket existant sans refactorer inutilement `ws_client.rs` / `ws_manager.rs` ; +- effectuer les `logsSubscribe`, `programSubscribe` ou `accountSubscribe` nécessaires selon le DEX ; +- détecter en temps réel mints, swaps, liquidités et autres événements utiles ; +- écrire en base via le pipeline existant : observations, transactions résolues, decoded events, pools/pairs/listings, trade events, candles et non-trade events ; +- afficher les compteurs live, erreurs, subscriptions actives et derniers objets persistés ; +- prévoir un arrêt propre avec unsubscribe avant close. + +### 6.080. Version `0.7.48` — Validation DEX v1 consolidée +Objectif : rejouer tous les DEX effectifs supportés et valider les invariants du pipeline complet avant de revenir aux launch surfaces ou à l’analyse `0.8.x`. + +À faire : + +- rejouer des bases neuves couvrant tous les connecteurs DEX supportés ; +- vérifier les compteurs globaux et par DEX : decoded events, trade events, liquidity events, lifecycle events, fee events, reward events, admin events, burns/mints utiles, candles et analytic signals ; +- contrôler que chaque famille d’événements alimente uniquement les tables métier prévues ; +- vérifier les diagnostics bloquants et les samples d’anomalie ; +- documenter les corpus utilisés pour chaque DEX/surface ; +- conserver une matrice de support par DEX, variante, instruction et type d’événement ; - verrouiller les invariants avant d’ouvrir l’analyse `0.8.x`. -### 6.076. Version `0.7.43` — `kb_demo_app` : overlays analytiques -Objectif : rendre visibles les signaux analytiques directement sur les graphes et vues de marché. - -À faire : - -- afficher les signaux analytiques par bucket au-dessus ou autour des candles, -- ajouter des marqueurs pour `first_trade_seen`, `trade_burst_60s`, `buy_sell_imbalance_60s`, `price_jump_up_60s`, `price_jump_down_60s` et `volume_spike_60s`, -- permettre le filtrage par type de signal et par sévérité, -- afficher un panneau latéral listant les signaux liés à une paire et à un timeframe, -- préparer l’extension future vers Ichimoku, Kumo, projections ABCD et égalités temps/prix sans les mélanger au pipeline de décodage DEX. - -### 6.077. Version `0.7.44` — `kb_demo_app` : vues consolidées token / pair / pool -Objectif : fournir une lecture métier plus confortable du modèle `0.7.x`. - -À faire : - -- ajouter une fiche token avec mint, programme token, metadata, pools, paires et historique de découverte, -- ajouter une fiche paire avec base/quote, DEX, pool, métriques, candles, signaux et derniers trades, -- ajouter une fiche pool avec composition, vaults, origine, première signature vue, programme DEX et statut de décodage, -- relier dans l’UI les launch origins, pool origins, wallets observés, holdings observés, événements de liquidité, lifecycle, fees, rewards, admin, candles et analytic signals, -- préparer une navigation transversale entre objets techniques et objets métier, -- rendre explicites les cas `tradeCount = null`, `lastPriceQuotePerBase = null`, tokens non enrichis et événements conservés uniquement pour analyse. - -### 6.078. Version `0.7.45` — Finition UI `0.7.x` -Objectif : stabiliser la couche desktop de validation avant l’ouverture de `0.8.x`. - -À faire : - -- consolider les vues ajoutées dans `kb_demo_app`, -- améliorer la navigation, les filtres et la pagination, -- ajouter les derniers raffinements de confort et de lisibilité, -- préparer une base UI suffisamment stable pour la future phase d’analyse et filtrage `0.8.x`, -- vérifier que les commandes Tauri restent de simples façades vers `kb_lib`. - -### 6.079. Version `0.7.x` — Couverture DEX v1 -Objectif : structurer les connecteurs DEX autour d’un pipeline complet de résolution, décodage, normalisation métier et classification des événements non-trade. - -Protocoles et surfaces cibles : - -- Pump.fun, -- PumpSwap, -- Raydium CPMM, -- Raydium CLMM, -- Raydium LaunchLab / Launchpad, -- Raydium AMM v4 legacy, -- Meteora DBC, -- Meteora DAMM v1, -- Meteora DAMM v2, -- Meteora DLMM, -- Orca Whirlpools, -- FluxBeam, -- DexLab, -- Bags, -- LetsBonk / Bonk.fun, -- Boop.fun, -- Moonshot / Moonit, -- Believe, -- Heaven. - -Hors périmètre immédiat : - -- `zora_solana`, tant qu’aucun programme Solana pertinent et exploitable n’est prouvé. - -Résultat attendu : - -- identification fiable des programmes et versions, -- résolution des signatures pertinentes, -- décodage des transactions utiles, -- conservation des transactions inconnues ou candidates sans perte d’information, -- création d’objets métier riches pour tokens, pools, paires, listings, participants, origins et holdings observés, -- distinction claire entre première source de mint, launch origin, pool origin, DEX effectif et migration target, -- enrichissement metadata des tokens découverts, -- séparation stricte entre événements candle/trade et événements utiles seulement à l’analyse, -- matérialisation progressive des événements non-trade dans des tables métier dédiées, -- préparation d’une détection temps réel hybride et d’un backfill ciblé compatible avec les mêmes objets métier, -- préparation d’agrégats DEX plus riches, de candles/OHLCV et d’une UI d’inspection du pipeline `0.7.x`. - -### 6.080. Version `0.8.x` — Analyse et filtrage +### 6.081. Version `0.8.x` — Analyse et filtrage Objectif : transformer les événements bruts en signaux exploitables. À faire : -- agrégation des métriques, -- règles de filtrage, -- exclusions des tokens non tradables, -- statistiques de comportement, -- premiers patterns, -- enrichissement des signaux analytiques préparés en fin de `0.7.x`, -- indicateurs graphiques optionnels comme Ichimoku / Kumo, -- outils de sélection manuelle de points ABC et projection d’un point D selon des règles temps/prix explicites, +- agrégation des métriques ; +- règles de filtrage ; +- exclusions des tokens non tradables ; +- statistiques de comportement ; +- premiers patterns ; +- enrichissement des signaux analytiques préparés en fin de `0.7.x` ; +- indicateurs graphiques optionnels comme Ichimoku / Kumo ; +- outils de sélection manuelle de points ABC et projection d’un point D selon des règles temps/prix explicites ; - séparation stricte entre signaux analytiques observés, projections hypothétiques et décisions de trading. -### 6.081. Version `1.x.y` — Wallets et swap préparatoire -Objectif : préparer la couche d’action. +### 6.082. Version `1.x.y` — Wallets, comptes et transferts +Objectif : préparer la couche d’action sans encore brancher l’achat/vente automatique. À faire : -- gestion du répertoire wallets, -- chargement sécurisé des keypairs, -- abstraction wallet, -- préparation d’ordres et de swaps, -- simulation et garde-fous. +- gestion du répertoire wallets ; +- création de wallet/keypair ; +- chargement sécurisé des keypairs ; +- inspection des informations wallet ; +- transfert de fonds depuis cette wallet vers un autre account ; +- garde-fous d’affichage, confirmation et simulation ; +- préparation d’ordres et de swaps seulement après stabilisation des transferts de base. -### 6.082. Version `2.x.y` — Trading semi-automatisé +### 6.083. Version `2.x.y` — Trading semi-automatisé Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites. À faire : -- scénarios d’achat/vente, -- règles d’entrée/sortie, -- limites de risque, -- confirmations explicites ou semi-automatiques, +- scénarios d’achat/vente ; +- règles d’entrée/sortie ; +- limites de risque ; +- confirmations explicites ou semi-automatiques ; - journaux d’exécution. -### 6.083. Version `3.x.y` — Yellowstone gRPC +### 6.084. Version `3.x.y` — Yellowstone gRPC Objectif : ajouter le connecteur gRPC dédié. À faire : -- `GrpcClient` basé sur `yellowstone-grpc-client`, -- adaptation du pipeline d’événements, -- coexistence HTTP / WS / gRPC, +- `GrpcClient` basé sur `yellowstone-grpc-client` ; +- adaptation du pipeline d’événements ; +- coexistence HTTP / WS / gRPC ; - politique de répartition par source. ## 7. Organisation des modules ciblés @@ -1186,6 +1173,9 @@ Responsabilités cibles : - réception des événements venant de `kb_lib`, - fenêtres de démonstration / diagnostic isolées, - inspection du pipeline persisté, +- `Demo3` pour la recherche de paires/pools par DEX ou `program_id`, +- `Demo4` pour les requêtes DEX Screener et la comparaison avec la base locale, +- `Demo10` pour le watcher WebSocket live DEX avec start/stop, - affichage candles et futurs overlays analytiques. `kb_demo_app` ne doit pas contenir de logique métier DEX profonde. @@ -1253,7 +1243,7 @@ Le projet doit maintenir au minimum : ## 12. Priorité immédiate -La priorité immédiate est `0.7.39_launch_surfaces` : détecter et rattacher les origines de lancement sans casser les invariants `0.7.36` à `0.7.38`. +La priorité immédiate après `0.7.38-B` est `0.7.39_dex_first_effective_swap_surfaces`. La phase launch surfaces est volontairement reportée : elle sera reprise après consolidation des DEX effectifs et des outils de constitution de corpus. Préconditions validées avant `0.7.39` : @@ -1261,13 +1251,28 @@ Préconditions validées avant `0.7.39` : 2. validation `0.7.37` acquise : compteurs metadata/catalog exposés, backfill metadata idempotent, `pair_symbol` rafraîchissables, metadata manquantes non bloquantes ; 3. validation `0.7.38` acquise : `tokenMetadataGapSamples` priorisés, Demo Pipeline 2 raccordé, `validationPassed = true`, `blockingIssueCount = 0`, registre local `WSOL`/`USDC`/`USDT`/`JUP`/`RAY`/`BONK` disponible ; 4. registre local minimal disponible : `SOL`, `WSOL`, `USDC`, `USDT` ; -5. les diagnostics locaux restent l’outil de vérité pour décider si une surface peut passer de `planned` à `partial` ou `supported`. +5. les diagnostics locaux restent l’outil de vérité pour décider si un DEX peut passer de `planned` ou `to_verify` à `partial` ou `supported`. -Ordre de travail recommandé pour `0.7.39` : +Ordre de travail recommandé pour `0.7.39+` : -1. scanner `launch_origin.rs`, `pool_origin.rs`, `protocol_candidate_recording.rs`, `dex_support_matrix.rs`, `transaction_classification.rs`, `dex_decode.rs` et `dex_detect.rs` ; -2. identifier les surfaces candidates déjà présentes dans la matrice : Raydium LaunchLab/Launchpad, LetsBonk/Bonk.fun, Bags, Moonshot/Moonit, Boop.fun et Believe ; -3. ne promouvoir une surface que si le corpus prouve le program id, les comptes/authorities et la migration vers le DEX effectif ; -4. distinguer explicitement `launch_origin`, `pool_origin`, `dex_effective` et `migration_target` ; -5. exposer les origins dans les diagnostics et l’UI d’inspection ; -6. conserver les garde-fous : pas de faux trade, pas de fausse candle, pas de program id inventé, pas de metadata manquante bloquante. +1. scanner `dex_support_matrix.rs`, `dex.rs`, `dex/*.rs`, `dex_decode.rs`, `dex_detect.rs`, `trade_aggregation.rs`, `local_pipeline_validation.rs`, `local_pipeline_diagnostics.rs`, `transaction_classification.rs` et `protocol_candidate_recording.rs` ; +2. produire un état des DEX effectifs déjà couverts, partiels, à vérifier ou absents ; +3. ajouter `metaDAO` et `Printr` comme DEX `to_verify` sans `program_id` inventé ; +4. vérifier les DEX principaux de swap : PumpSwap, Raydium CPMM/CLMM/AMM v4/Stable Swap, Meteora DLMM/DAMM/DBC, Orca Whirlpools, FluxBeam, DexLab ; +5. rechercher des corpus par `program_id`, pair/pool address, signature et token mint ; +6. ajouter `Demo3` pour rechercher localement les paires/pools/signatures par DEX ou `program_id` ; +7. ajouter `Demo4` pour interroger DEX Screener ou sources externes et comparer avec la base locale sans promotion automatique ; +8. compléter la couverture par DEX des swaps, liquidités, lifecycle, fees, rewards, admin/config, burns/mints utiles ; +9. ajouter ensuite `Demo10` pour le watcher WebSocket live DEX avec start/stop, subscribe/unsubscribe et écriture en base via le pipeline existant ; +10. reprendre seulement après cela les launch surfaces : Raydium LaunchLab/Launchpad, LetsBonk/Bonk.fun, Bags, Moonshot/Moonit, Boop.fun, Believe, Heaven ; +11. passer ensuite à la couche wallet : création de wallet/keypair, inspection et transfert de fonds vers un autre account. + +Garde-fous constants : + +- pas de faux trade ; +- pas de fausse candle ; +- pas de `program_id` fictif ; +- pas de promotion d’un DEX sans corpus transactionnel ; +- pas de logique métier DEX profonde dans `kb_demo_app` ; +- pas de metadata manquante bloquante ; +- pas de refactor réseau inutile tant que les clients HTTP/WS existants suffisent. diff --git a/kb_demo_app/frontend/demo_pipeline2.html b/kb_demo_app/frontend/demo_pipeline2.html index 3b342c0..ba99b6a 100644 --- a/kb_demo_app/frontend/demo_pipeline2.html +++ b/kb_demo_app/frontend/demo_pipeline2.html @@ -166,7 +166,8 @@