0.7.40

README.md

@@ -4,7 +4,7 @@
 
 `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-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.
+Le README précédent décrivait surtout l’état `0.3.1`. Ce fichier reflète l’état de clôture `0.7.40` et la réorientation de travail `0.7.41 Raydium AMM v4` : 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 exploite les corpus on-chain obtenus via Demo3 et Demo Pipeline 2 pour consolider les DEX effectifs, en commençant par `raydium_amm_v4`, avant de revenir aux launch surfaces.
 
 ## 1. Objectif
 
@@ -114,7 +114,7 @@ La distinction de travail à partir de `0.7.39` est la suivante :
 
 ### 4.1. Matrice de travail
 
-Depuis `0.7.29`, la matrice de support DEX est portée par `kb_lib/src/dex_support_matrix.rs`. Elle centralise le code interne, la famille, la version, le type technique de surface, le rôle stratégique de surface (`dex_effective`, `aggregator_router`, `launch_surface`, `to_verify`), les program ids vérifiés localement, le statut de support, les capacités actuelles et les raisons de skip.
+Depuis `0.7.29`, la matrice de support DEX est portée par `kb_lib/src/dex_support_matrix.rs`. Elle centralise le code interne, la famille, la version, le type de surface, les program ids vérifiés localement, le statut de support, les capacités actuelles et les raisons de skip.
 
 Depuis `0.7.30`, les événements décodés reçoivent aussi une classification plus fine : `eventLifecycleKind`, `eventActionability` et `nonTradeUseful`. Cette classification sert aux diagnostics et prépare la matérialisation future des événements non-trade sans alimenter directement les trades/candles.
 
@@ -230,30 +230,27 @@ 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.
+Les phases `0.7.38`, `0.7.39` et `0.7.40` sont considérées comme closes lorsque les tests et validations locales passent.
 
-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.
+État acquis :
 
-Préconditions validées avant de reprendre le codage :
+- `0.7.38_token_metadata_gap_prioritization` : metadata manquantes priorisées et non bloquantes ;
+- `0.7.39_dex_first_effective_swap_surfaces` : matrice DEX-first, suppression de l’alias `raydium`, ajout de `metaDAO` et `Printr` en `to_verify`, invariants locaux maintenus ;
+- `0.7.40` : Demo3 découvre on-chain des signatures, mints, deltas et comptes candidats par DEX/program id, et Demo Pipeline 2 peut backfiller une signature précise.
 
-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 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é.
+La prochaine étape est maintenant `0.7.41_raydium_amm_v4_swap_decoder_v1`.
 
-Objectifs `0.7.39+` :
+Objectifs immédiats :
 
-- 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.
+- utiliser le corpus Raydium AMM v4 obtenu via Demo3 et backfill signature ;
+- décoder les inner instructions `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, y compris lorsqu’elles sont appelées par Jupiter ou un autre routeur top-level ;
+- extraire les comptes pool/state, authority, vaults et comptes utilisateur lorsque le layout observé est compatible ;
+- dériver les montants à partir des deltas SPL Token ou transferts instruction-scoped ;
+- produire `tradeCandidate=true` seulement si les mints et montants sont exploitables ;
+- conserver les routes ambiguës, failed transactions et swaps sans montants fiables comme non actionnables ;
+- ne créer aucun trade, metric ou candle sans payload exploitable.
+
+`Demo4` est volontairement reportée à une version ultérieure. Pour la suite immédiate, Demo3 et Demo Pipeline 2 suffisent à produire le corpus nécessaire à la consolidation Raydium AMM v4.
 
 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.