From 75c2b6983d5b79c42a2f7b2b5a242ef4ef77253e Mon Sep 17 00:00:00 2001 From: SinuS Von SifriduS Date: Tue, 12 May 2026 18:53:42 +0200 Subject: [PATCH] 0.7.29 --- CHANGELOG.md | 1 + Cargo.toml | 3 +- README.md | 87 +- ROADMAP.md | 122 +-- kb_demo_app/frontend/demo_pipeline2.html | 9 + .../DemoPipeline2DexSupportMatrixEntry.ts | 82 ++ ...oPipeline2LocalPipelineValidationReport.ts | 9 + .../DemoPipeline2LocalValidationRequest.ts | 10 + kb_demo_app/frontend/ts/demo_pipeline2.ts | 12 +- kb_demo_app/package.json | 2 +- kb_demo_app/src/demo_pipeline2.rs | 119 ++- kb_demo_app/tauri.conf.json | 2 +- .../db/dtos/program_instruction_diagnostic.rs | 2 +- .../queries/program_instruction_diagnostic.rs | 4 +- kb_lib/src/dex_catalog.rs | 210 +--- kb_lib/src/dex_support_matrix.rs | 910 ++++++++++++++++++ kb_lib/src/lib.rs | 14 + kb_lib/src/local_pipeline_validation.rs | 80 +- kb_lib/src/protocol_candidate_recording.rs | 69 +- kb_lib/src/trade_aggregation.rs | 2 +- kb_lib/src/trade_amount_resolution.rs | 14 +- kb_lib/src/transaction_classification.rs | 57 +- 22 files changed, 1452 insertions(+), 368 deletions(-) create mode 100644 kb_demo_app/frontend/ts/bindings/DemoPipeline2DexSupportMatrixEntry.ts create mode 100644 kb_demo_app/frontend/ts/bindings/DemoPipeline2LocalValidationRequest.ts create mode 100644 kb_lib/src/dex_support_matrix.rs diff --git a/CHANGELOG.md b/CHANGELOG.md index a053f80..710e00f 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -59,3 +59,4 @@ 0.7.26 - Diagnostics locaux du pipeline persisté, correction de l’agrégation instruction-scoped des swaps Raydium, clarification des compteurs de replay/upsert, et validation qu’aucun trade candidate issu d’une transaction OK n’est perdu 0.7.27 - Validation multi-DEX et non-régression du pipeline sur Pump.fun, PumpSwap, Raydium CPMM et Raydium CLMM, avec corpus de tests, diagnostics de référence et garanties sur les événements non pricés 0.7.28 - Refactor DEX commun et verrouillage des invariants de normalisation : séparation des événements décodés, actionnables, trade candidates et candle candidates ; conservation des transactions failed comme traçables mais non actionnables ; ajout de la règle bloquante empêchant tout trade/candle candidate sans payload de montants exploitable, notamment pour le cas partiel `meteora_damm_v1.swap` sans base/quote amount. +0.7.29 - Ajout d’une matrice DEX commune (`dex_support_matrix`) utilisée par le catalogue DEX, la classification transactionnelle et l’enregistrement des protocol candidates ; ajout du profil de validation `0.7.29_multi_dex_matrix_baseline` exposant la matrice dans le rapport de validation ; préparation explicite des surfaces planifiées sans inventer de program ids non vérifiés. diff --git a/Cargo.toml b/Cargo.toml index 28ebf8d..927c4af 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -8,7 +8,7 @@ members = [ ] [workspace.package] -version = "0.7.28" +version = "0.7.29" edition = "2024" license = "MIT" repository = "https://git.sasedev.com/Sasedev/khadhroony-bobobot" @@ -87,3 +87,4 @@ manual_map = "allow" match_like_matches_macro = "allow" single_match = "allow" manual_unwrap_or_default = "allow" +manual_find = "allow" diff --git a/README.md b/README.md index ed021f3..fd2ddbb 100644 --- a/README.md +++ b/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 reprise autour de `0.7.27` : le socle transport HTTP/WS, la résolution transactionnelle, le modèle SQLite, plusieurs connecteurs DEX, les candles, les signaux analytiques et l’application de démonstration existent déjà. +Le README précédent décrivait surtout l’état `0.3.1`. Ce fichier reflète l’état de reprise autour de `0.7.29` : le socle transport HTTP/WS, la résolution transactionnelle, le modèle SQLite, plusieurs connecteurs DEX, les candles, les signaux analytiques, la validation locale et une matrice DEX commune existent déjà. ## 1. Objectif @@ -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 autour de `0.7.27` +## 3. État actuel autour de `0.7.29` ### 3.1. Socle stabilisé à ne pas refactorer maintenant @@ -63,12 +63,14 @@ Le pipeline `0.7.x` couvre déjà les étapes suivantes : ### 3.3. Connecteurs validés manuellement via l’application de démo -Les connecteurs suivants ont déjà été testés via l’application de démonstration et doivent être verrouillés par corpus/replay avant d’ajouter de nouveaux DEX : +Les connecteurs suivants sont les surfaces prioritaires à verrouiller avant extension massive : -- `pump_fun` ; -- `pump_swap` ; +- `pump_fun` comme surface de launch / mint initial ; +- `pump_swap` pour les swaps post-migration Pump ; - `raydium_cpmm` ; -- `raydium_clmm`. +- `raydium_clmm` ; +- `meteora_dlmm` ; +- `meteora_damm_v1`, actuellement partiel pour les swaps sans payload montant/prix exploitable. ### 3.4. Connecteurs déjà présents mais à consolider par corpus @@ -93,28 +95,33 @@ La distinction importante est la suivante : ### 4.1. Matrice de travail -| Code cible | Type | Statut actuel | Prochaine action | +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. + +| Code cible | Type | Statut `0.7.29` | Prochaine action | |---|---:|---|---| -| `pump_fun` | Launch + bonding curve | testé via démo | verrouiller corpus, invariants et documentation | -| `pump_swap` | AMM / swap | testé via démo | verrouiller corpus, invariants et candles | -| `raydium_cpmm` | AMM | testé via démo | verrouiller corpus, swaps et candles | -| `raydium_clmm` | CLMM | testé via démo | verrouiller corpus, swaps et candles | -| `raydium_launchlab` / `raydium_launchpad` | Launch surface + migration | manquant | ajouter comme origine de mint/lancement et migration vers Raydium | -| `raydium_amm_v4` | AMM legacy | présent, à isoler | traiter après les autres Raydium avec corpus dédié | -| `meteora_dbc` | Launch / bonding curve | présent, à consolider | corpus, lifecycle, migration et swaps exploitables | -| `meteora_damm_v1` | AMM legacy | présent, à consolider | corpus et séparation swaps/liquidité/events | -| `meteora_damm_v2` | AMM | présent, à consolider | corpus et séparation swaps/liquidité/events | -| `meteora_dlmm` | DLMM | manquant | ajouter à la matrice, puis corpus avant décodage | -| `orca_whirlpools` | CLMM | présent, à consolider | corpus fiable et validation des instructions utiles | -| `fluxbeam` | DEX | présent, à consolider | corpus fiable avant validation | -| `dexlab` | DEX | présent, à consolider | corpus fiable avant validation | -| `bags` | Launch surface / attribution | amorcé | conserver comme origine de lancement, relier à Meteora si prouvé | -| `letsbonk` / `bonk_fun` | Launch surface | manquant | ajouter comme origine LaunchLab/Raydium, pas comme AMM autonome tant que non prouvé | -| `boop_fun` | Launch surface | manquant | ajouter comme origine de mint/lancement et migration | -| `moonshot` / `moonit` | Launch surface | amorcé partiellement | remplacer les heuristiques faibles par corpus et règles prouvées | -| `believe` | Launch surface | manquant | ajouter comme origine associée à Meteora DBC si les comptes l’attestent | -| `heaven` | Launch + AMM candidat | manquant | ajouter corpus et déterminer séparation launch/swap | -| `zora_solana` | À vérifier | écarté maintenant | ne pas intégrer avant preuve de programme Solana pertinent | +| `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 | conserver le skip explicite des swaps sans montants exploitables | +| `meteora_damm_v2` | AMM | partiel | corpus et séparation swaps/liquidité/events | +| `meteora_dbc` | Launch / bonding curve | partiel | lifecycle, migration et swaps exploitables | +| `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 | ## 5. Base de données @@ -147,9 +154,9 @@ Le modèle actuel contient déjà notamment : - metrics et analytic signals ; - diagnostics locaux. -### 5.2. Tables futures prioritaires +### 5.2. Tables existantes à stabiliser pour les cas non-trade et inconnus -Avant d’étendre trop agressivement les DEX, le modèle doit prévoir les cas non directement tradables : +Avant d’étendre trop agressivement les DEX, ces tables doivent être stabilisées et raccordées progressivement aux diagnostics et matérialisations : | Table cible | Rôle | |---|---| @@ -206,18 +213,16 @@ Les tests peuvent rester plus souples lorsque cela clarifie le test. La reprise doit suivre cet ordre : -1. finir/verrouiller `0.7.27` sur `pump_fun`, `pump_swap`, `raydium_cpmm`, `raydium_clmm` ; -2. démarrer `0.7.28` par un refactor commun DEX sans toucher au transport ; -3. ajouter la matrice DEX documentée et les corpus de validation ; -4. ajouter les tables de classification des transactions inconnues et protocol candidates ; -5. matérialiser les événements non-trade : lifecycle, liquidité, fees, rewards, admin ; -6. consolider Meteora, y compris `meteora_dlmm` dans la matrice ; -7. ajouter les launch surfaces manquantes comme origines de mint : LaunchLab/Launchpad, LetsBonk/Bonk.fun, Boop.fun, Moonshot/Moonit, Believe ; -8. traiter Heaven ; -9. consolider Orca/FluxBeam/DexLab ; -10. isoler Raydium AMM v4 legacy ; -11. effectuer une validation DEX v1 consolidée ; -12. reprendre ensuite l’UI analytique et les vues token/pair/pool. +1. conserver la non-régression `0.7.28` : transactions failed traçables mais non actionnables, aucun trade/candle candidate sans montant exploitable ; +2. utiliser la matrice `0.7.29` comme source commune pour le catalogue, la classification et les protocol candidates ; +3. relier progressivement les événements non-trade aux tables existantes : lifecycle, liquidité, fees, rewards, admin ; +4. consolider Meteora, surtout `meteora_dlmm` et le cas partiel `meteora_damm_v1` ; +5. ajouter les launch surfaces manquantes comme origines de mint : LaunchLab/Launchpad, LetsBonk/Bonk.fun, Boop.fun, Moonshot/Moonit, Believe, Bags ; +6. traiter Heaven ; +7. consolider Orca/FluxBeam/DexLab ; +8. isoler Raydium AMM v4 legacy ; +9. effectuer une validation DEX v1 consolidée ; +10. reprendre ensuite l’UI analytique et les vues token/pair/pool. ## 9. Fichiers utiles pour reprendre dans une nouvelle session diff --git a/ROADMAP.md b/ROADMAP.md index 18401db..1b8f378 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -766,9 +766,7 @@ Objectif : verrouiller la non-régression du pipeline actuel avant d’ajouter d - valider que les transactions échouées restent traçables dans les événements décodés sans produire de `k_sol_trade_events`. ### 6.060. Version `0.7.28` — Refactor DEX commun et préparation extension -Objectif : nettoyer la couche DEX avant d’ajouter de nouveaux protocoles, sans modifier le transport HTTP/WS déjà stabilisé. - -À faire : +Réalisé : - ne pas toucher à `ws_client.rs`, `ws_manager.rs`, `http_client.rs`, `http_pool.rs` ni aux couches JSON-RPC déjà stabilisées, - extraire depuis `dex_decode.rs` les catégories communes d’événements : trade, candle candidate, liquidity candidate, fee candidate, reward candidate, admin candidate, pool lifecycle candidate, @@ -787,52 +785,54 @@ Contraintes : - aucun changement de comportement métier volontaire dans cette version, - aucun événement non price-action ne doit devenir un trade ou une candle. -### 6.061. Version `0.7.29` — Matrice DEX, corpus et documentation de support -Objectif : rendre explicite ce qui est validé, présent, partiel, manquant ou volontairement ignoré. +### 6.061. Version `0.7.29` — Matrice DEX commune et validation baseline +Réalisé : -À faire : - -- ajouter et maintenir une matrice DEX dans `README.md` et `ROADMAP.md`, -- distinguer clairement `DEX effectif`, `launch surface`, `pool origin`, `launch origin` et `migration target`, -- documenter que les launch surfaces sont importantes comme première source de mint/lancement même lorsqu’un token migre ensuite vers un autre DEX, -- constituer une liste de corpus par DEX/surface : signatures, pools, token mints, résultat attendu, -- indiquer pour chaque protocole : statut, source de preuve, type d’événements couverts, tables alimentées, limites connues, -- retirer `zora_solana` du phasage actif tant qu’aucun programme Solana pertinent n’est prouvé, -- ajouter `meteora_dlmm` à la matrice comme variante Meteora manquante à couvrir plus tard, -- préparer les diagnostics SQL de référence par protocole et par table métier. +- ajouter `kb_lib/src/dex_support_matrix.rs` comme source commune de metadata DEX/surfaces ; +- exposer pour chaque entrée : code interne, famille, version, type de surface, program id connu ou à vérifier, support actuel, statut, confiance, raisons de skip et activation catalogue ; +- raccorder `dex_catalog`, `transaction_classification` et `protocol_candidate_recording` à cette matrice ; +- ajouter le profil `0.7.29_multi_dex_matrix_baseline` ; +- exposer la matrice dans le rapport de validation local ; +- conserver explicitement le comportement `0.7.28` : transactions failed traçables mais non actionnables, et `meteora_damm_v1.swap` sans payload montant/prix non candidat trade/candle. Matrice cible initiale : -| Code cible | Type | Statut | Objectif immédiat | +| Code cible | Type | Statut `0.7.29` | Objectif immédiat | |---|---:|---|---| -| `pump_fun` | launch + bonding curve | testé via démo | verrouiller corpus et invariants | -| `pump_swap` | AMM / swap | testé via démo | verrouiller trades/candles | -| `raydium_cpmm` | AMM | testé via démo | verrouiller trades/candles | -| `raydium_clmm` | CLMM | testé via démo | verrouiller trades/candles | -| `raydium_launchlab` / `raydium_launchpad` | launch surface | manquant | détecter mint, launch, migration | -| `raydium_amm_v4` | AMM legacy | présent, à isoler | corpus dédié après autres DEX | -| `meteora_dbc` | launch / bonding curve | présent, à consolider | lifecycle, migration, swaps utiles | -| `meteora_damm_v1` | AMM legacy | présent, à consolider | corpus et séparation events | -| `meteora_damm_v2` | AMM | présent, à consolider | corpus et séparation events | -| `meteora_dlmm` | DLMM | manquant | ajouter corpus avant décodeur | -| `orca_whirlpools` | CLMM | présent, à consolider | validation par corpus | -| `fluxbeam` | DEX | présent, à consolider | validation par corpus | -| `dexlab` | DEX | présent, à consolider | validation par corpus | -| `bags` | launch surface | amorcé | attribution fiable, migration si prouvée | -| `letsbonk` / `bonk_fun` | launch surface | manquant | origine LaunchLab/Raydium | -| `boop_fun` | launch surface | manquant | origine mint/lancement/migration | -| `moonshot` / `moonit` | launch surface | amorcé partiellement | corpus, éviter heuristique faible | -| `believe` | launch surface | manquant | origine Meteora DBC si comptes probants | -| `heaven` | launch + AMM candidat | manquant | corpus et séparation launch/swap | +| `pump_fun` | launch + bonding curve | partiel | rattacher mint initial, bonding curve et migration | +| `pump_swap` | AMM / swap | supporté | conserver trades/candles | +| `raydium_cpmm` | AMM | supporté | conserver trades/candles | +| `raydium_clmm` | CLMM | supporté | conserver trades/candles | +| `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 | corpus dédié après autres Raydium | +| `raydium_router` | router | partiel | ne pas matérialiser en trade direct avant preuve | +| `raydium_stable_swap` | AMM legacy | planifié | traiter seulement si corpus pertinent | +| `meteora_dlmm` | DLMM | supporté | verrouiller corpus et non-régression | +| `meteora_damm_v1` | AMM legacy | partiel | garder skip explicite sans payload montant/prix | +| `meteora_damm_v2` | AMM | partiel | corpus et séparation events | +| `meteora_dbc` | launch / bonding curve | partiel | lifecycle, migration, swaps utiles | +| `meteora_dlc` | à vérifier | à vérifier | confirmer surface/program id avant intégration | +| `orca_whirlpools` | CLMM | partiel | validation par corpus | +| `fluxbeam` | AMM | partiel | validation par corpus | +| `dexlab` | AMM | partiel | validation par corpus | +| `bags` | launch surface | planifié | attribution fiable, migration si prouvée | +| `letsbonk` / `bonk` | launch surface | planifié | origine mint/lancement, sans supposer un AMM autonome | +| `okx_dex` | aggregator/router | planifié | classifier sans trade direct avant preuve | +| `boop_fun` | launch surface | planifié | origine mint/lancement/migration | +| `moonshot` / `moonit` | launch surface | planifié | corpus, éviter heuristique faible | +| `believe` | launch surface | planifié | confirmer comptes et migrations | +| `heaven` | launch + AMM candidat | planifié | corpus et séparation launch/swap | +| `zora` | à vérifier | à vérifier | hors phasage actif avant preuve Solana | ### 6.062. Version `0.7.30` — Transactions inconnues et protocol candidates Objectif : ne plus perdre les transactions utiles qui ne correspondent pas encore à un DEX connu. À faire : -- ajouter `k_sol_transaction_classifications`, -- ajouter `k_sol_protocol_candidates`, -- classifier les transactions résolues en catégories : known dex, known launch surface, unknown program, non-dex, failed transaction, partial decode, ignored technical transaction, +- consolider `k_sol_transaction_classifications`, déjà présente, avec les catégories utiles au suivi DEX, +- consolider `k_sol_protocol_candidates`, déjà présente, pour prioriser les programmes inconnus ou partiellement reconnus, +- classifier les transactions résolues en catégories : known supported, known partial, known non-trade, unknown program, unknown protocol candidate, unknown event kind, failed transaction, non-actionable trade, - conserver les `program_id`, comptes, signatures, préfixes de `data`, logs et indices d’instructions utiles à l’analyse, - créer des requêtes de diagnostic pour repérer les programmes inconnus fréquents, - permettre de promouvoir plus tard un protocol candidate vers un vrai DEX/surface sans perdre l’historique, @@ -1161,6 +1161,19 @@ Plus tard, ce comportement pourra devenir configurable dans `config.json` et pil 6. laisser se terminer le flux de lecture, 7. journaliser clairement les cas dégradés. +## 10.5. Jalons `0.7.29` + +Réalisé / à maintenir : + +- matrice DEX commune dans `kb_lib/src/dex_support_matrix.rs` ; +- raccordement minimal du catalogue DEX à cette matrice ; +- raccordement des mappings program id -> protocole utilisés par la classification transactionnelle et les protocol candidates ; +- profil `0.7.29_multi_dex_matrix_baseline` ; +- exposition de la matrice dans le rapport de validation local ; +- aucune modification volontaire du comportement trade/candle validé en `0.7.28`. + +À poursuivre en `0.7.30` : matérialisation contrôlée des événements non-trade utiles et des transactions inconnues/partielles, sans alimenter les trades/candles actionnables. + ## 11. Documentation et livrables de référence Le projet doit maintenir au minimum : @@ -1175,21 +1188,18 @@ Le projet doit maintenir au minimum : La priorité immédiate est désormais la suivante : -1. terminer la validation `0.7.27` sur `pump_fun`, `pump_swap`, `raydium_cpmm` et `raydium_clmm`, sans ajouter de nouveau DEX dans cette étape, -2. vérifier sur bases neuves et après replay local les invariants bloquants du pipeline : `diagnosticsClean = true`, `blockingIssueCount = 0`, aucun trade candidate exploitable perdu, aucun trade event invalide, aucun doublon réel par `decoded_event_id`, aucune candle dupliquée par bucket, -3. démarrer `0.7.28` par le refactor DEX commun, sans toucher aux clients HTTP/WS ni aux managers réseau stabilisés, -4. ajouter la matrice DEX et launch surfaces, avec statut, corpus, limites et prochaine action pour chaque protocole, -5. ajouter les tables de classification des transactions inconnues et des protocol candidates afin de ne plus perdre les transactions utiles non encore décodables, -6. matérialiser ensuite les événements non-trade : liquidité, cycle de vie des pools, fees, rewards et administration, -7. garantir que ces événements non-trade restent séparés des `k_sol_trade_events` et des candles tout en restant rattachés aux transactions, decoded events, pools, pairs et wallets observés, -8. consolider Meteora, y compris `meteora_dlmm`, après corpus fiable, -9. ajouter les launch surfaces manquantes comme premières sources de mint/lancement : Raydium LaunchLab/Launchpad, LetsBonk/Bonk.fun, Boop.fun, Moonshot/Moonit, Believe et Bags, -10. traiter Heaven avec séparation launch/swap, -11. consolider Orca, FluxBeam et DexLab sur corpus, -12. traiter `raydium_amm_v4` legacy seulement après les autres Raydium, avec corpus dédié prouvant le programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, -13. effectuer une validation DEX v1 consolidée sur tous les connecteurs supportés avant de considérer la couche DEX `0.7.x` comme stable, -14. ajouter ensuite les overlays des signaux analytiques sur les candles, -15. consolider les vues métier `token / pair / pool` dans `kb_demo_app`, y compris les événements liquidité, lifecycle, fees, rewards et admin, -16. stabiliser l’ergonomie, les filtres, la pagination et la navigation de l’UI d’inspection, -17. préparer ensuite l’ouverture de `0.8.x` pour l’analyse, les filtres, les patterns et les projections graphiques, -18. préparer enfin Yellowstone gRPC comme extension de capacité, et non comme remplacement du socle HTTP / WS existant. +1. conserver la validation acquise `0.7.28` : transactions failed traçables mais non actionnables, aucun trade/candle candidate sans payload montant/prix exploitable, aucun diagnostic bloquant masqué, +2. utiliser la matrice `0.7.29` (`kb_lib/src/dex_support_matrix.rs`) comme source commune pour le catalogue DEX, les mappings program id -> protocole, la classification transactionnelle et les protocol candidates, +3. garder les clients HTTP/WS et managers réseau hors du refactor DEX tant qu’ils ne bloquent pas le pipeline, +4. consolider les événements non-trade sans les confondre avec les trades/candles : lifecycle de pool, liquidité, fees, rewards, admin/config, migration et launch/mint, +5. rattacher les launch surfaces aux tokens et aux pools migrés : Raydium LaunchLab/Launchpad, LetsBonk/Bonk.fun, Boop.fun, Moonshot/Moonit, Believe, Bags et Heaven, +6. consolider Meteora avec corpus fiable : `meteora_dlmm`, `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc` et `meteora_dlc` si le programme est confirmé, +7. consolider Orca, FluxBeam et DexLab sur corpus, +8. traiter `raydium_amm_v4` legacy seulement après les autres Raydium, avec corpus dédié prouvant le programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, +9. ajouter une matérialisation dédiée des transactions inconnues ou partiellement décodées pour analyser les DEX manquants sans polluer les trades/candles, +10. effectuer une validation DEX v1 consolidée sur tous les connecteurs supportés avant de considérer la couche DEX `0.7.x` comme stable, +11. ajouter ensuite les overlays des signaux analytiques sur les candles, +12. consolider les vues métier `token / pair / pool` dans `kb_demo_app`, y compris les événements liquidité, lifecycle, fees, rewards et admin, +13. stabiliser l’ergonomie, les filtres, la pagination et la navigation de l’UI d’inspection, +14. préparer ensuite l’ouverture de `0.8.x` pour l’analyse, les filtres, les patterns et les projections graphiques, +15. préparer enfin Yellowstone gRPC comme extension de capacité, et non comme remplacement du socle HTTP / WS existant. diff --git a/kb_demo_app/frontend/demo_pipeline2.html b/kb_demo_app/frontend/demo_pipeline2.html index adc1024..9aedb0c 100644 --- a/kb_demo_app/frontend/demo_pipeline2.html +++ b/kb_demo_app/frontend/demo_pipeline2.html @@ -163,6 +163,15 @@ Analyse les données déjà persistées : transactions, decoded events, trades, candles, tokens, pools et pairs.

+
+ + +
+