From cfa1ff228913560ffff38fa759c34e4e5edc71a1 Mon Sep 17 00:00:00 2001 From: SinuS Von SifriduS Date: Wed, 13 May 2026 20:11:29 +0200 Subject: [PATCH] 0.7.34 --- CHANGELOG.md | 5 +- Cargo.toml | 2 +- README.md | 50 +- ROADMAP.md | 73 ++- kb_demo_app/frontend/demo_pipeline2.html | 3 +- ...Pipeline2LocalPipelineDiagnosticSummary.ts | 8 + ...oPipeline2LocalPipelineValidationReport.ts | 8 + kb_demo_app/frontend/ts/demo_pipeline2.ts | 21 +- kb_demo_app/package.json | 2 +- kb_demo_app/src/demo_pipeline2.rs | 21 +- kb_demo_app/tauri.conf.json | 2 +- kb_lib/src/db.rs | 5 + kb_lib/src/db/dtos.rs | 18 +- kb_lib/src/db/dtos/liquidity_event.rs | 68 ++- .../src/db/dtos/local_pipeline_diagnostics.rs | 10 + kb_lib/src/db/dtos/pool_lifecycle_event.rs | 145 +++++ kb_lib/src/db/entities.rs | 2 + kb_lib/src/db/entities/liquidity_event.rs | 14 + .../src/db/entities/pool_lifecycle_event.rs | 42 ++ kb_lib/src/db/queries.rs | 4 + kb_lib/src/db/queries/liquidity_event.rs | 33 +- .../db/queries/local_pipeline_diagnostics.rs | 4 + kb_lib/src/db/queries/pool_lifecycle_event.rs | 294 ++++++++++ kb_lib/src/db/schema.rs | 9 + kb_lib/src/db/types/liquidity_event_kind.rs | 8 + kb_lib/src/dex.rs | 2 + kb_lib/src/dex/meteora_dlmm.rs | 526 +++++++++++++++++- kb_lib/src/dex_decode.rs | 36 ++ kb_lib/src/dex_event_classification.rs | 61 ++ kb_lib/src/lib.rs | 21 + kb_lib/src/local_pipeline_diagnostics.rs | 2 + kb_lib/src/local_pipeline_replay.rs | 27 + kb_lib/src/local_pipeline_validation.rs | 68 ++- kb_lib/src/non_trade_event_materialization.rs | 490 ++++++++++++++++ kb_lib/src/token_backfill.rs | 38 ++ kb_lib/src/tx_resolution.rs | 16 + 36 files changed, 2035 insertions(+), 103 deletions(-) create mode 100644 kb_lib/src/db/dtos/pool_lifecycle_event.rs create mode 100644 kb_lib/src/db/entities/pool_lifecycle_event.rs create mode 100644 kb_lib/src/db/queries/pool_lifecycle_event.rs create mode 100644 kb_lib/src/non_trade_event_materialization.rs diff --git a/CHANGELOG.md b/CHANGELOG.md index e8f6639..ed2fc6e 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -62,5 +62,6 @@ 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. 0.7.30 - Ajout d’une taxonomie DEX plus fine pour les événements décodés : `eventLifecycleKind`, `eventActionability`, `nonTradeUseful`, compteurs diagnostics des événements non-trade utiles, trades non actionnables et classifications inconnues ; ajout du profil `0.7.30_non_trade_event_classification` sans modification volontaire de la matérialisation trade/candle. 0.7.31 - Application de la politique Option B : les transactions failed restent traçables dans les événements décodés mais ne peuvent plus alimenter `trade_events`, metrics ou candles ; le replay local réinitialise les tables de matérialisation marché avant reconstruction pour supprimer les anciennes lignes dérivées non actionnables. -0.7.32 - Clarification de la sémantique des diagnostics locaux : séparation des gaps littéraux de paires et des gaps bloquants/actionnables, ajout des compteurs de matérialisation par paire, résumé `pairActionabilitySummaries`, profil `0.7.32_validation_report_semantics` et garde-fous sur la matrice DEX sans modification de la matérialisation trade/candle. -0.7.33 - Ajout de la classification diagnostique `pairTradingReadiness` pour les paires, avec `quoteAssetClass`, `tradingRouteRequired`, résumé `pairTradingReadinessSummaries`, profil de validation `0.7.33_pair_trading_readiness` et mise à jour de la sélection UI Demo Pipeline 2 sans modifier la matérialisation trade/candle. +0.7.32 - Clarification des sémantiques de validation locale : distinction entre gaps littéraux, gaps bloquants et paires actionnables, afin d’éviter de bloquer sur des paires détectées mais non matérialisées par trade. +0.7.33 - Ajout du profil `0.7.33_pair_trading_readiness`, avec classification des paires directes WSOL, directes stable, inverses stable/WSOL et cross-quotes nécessitant un router. +0.7.34 - Ajout du profil `0.7.34_non_trade_liquidity_lifecycle`, matérialisation des tables non-trade liquidité/lifecycle, warning non bloquant pour DEX attendus absents du corpus local, première tranche DLMM : `add_liquidity`, `remove_liquidity`, `initialize_position`, `initialize_bin_array`, intégration de la matérialisation non-trade dans les backfills token/pool ciblés, et distinction `PositionOpen`/`PositionClose` dans `LiquidityEventKind`. diff --git a/Cargo.toml b/Cargo.toml index b923d7a..8b1828d 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -8,7 +8,7 @@ members = [ ] [workspace.package] -version = "0.7.33" +version = "0.7.34" edition = "2024" license = "MIT" repository = "https://git.sasedev.com/Sasedev/khadhroony-bobobot" diff --git a/README.md b/README.md index f9240e3..48c23cd 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.33` : 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à. +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.34` : 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.33` +## 3. État actuel autour de `0.7.34` ### 3.1. Socle stabilisé à ne pas refactorer maintenant @@ -97,11 +97,7 @@ La distinction importante est la suivante : 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. - -Depuis `0.7.32`, les diagnostics distinguent explicitement les gaps littéraux de catalogue (`literalPairWithoutTradeCount`, `literalPairWithoutCandleCount`) des gaps bloquants/actionnables (`blockingPairWithoutTradeCount`, `blockingPairWithoutCandleCount`). Les anciens champs `pairWithoutTradeCount` et `pairWithoutCandleCount` restent exposés comme alias de compatibilité pour les gaps bloquants/actionnables. - -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. +Depuis `0.7.30`, les événements décodés reçoivent aussi une classification plus fine : `eventLifecycleKind`, `eventActionability` et `nonTradeUseful`. Depuis `0.7.34`, cette classification commence à alimenter les tables non-trade utiles, sans alimenter directement les trades/candles. Le backfill ciblé token/pool appelle aussi cette matérialisation afin que les compteurs `liquidityEventCount` et `poolLifecycleEventCount` soient cohérents sans devoir lancer un replay local séparé. | Code cible | Type | Statut `0.7.29` | Prochaine action | |---|---:|---|---| @@ -175,6 +171,24 @@ Avant d’étendre trop agressivement les DEX, ces tables doivent être stabilis `k_sol_liquidity_events` existe déjà et doit être stabilisée/étendue plutôt que recréée sans nécessité. +### 5.3. État `0.7.34` des événements non-trade + +Le profil `0.7.34_non_trade_liquidity_lifecycle` valide deux choses distinctes : + +- les tables et diagnostics non-trade existent pour compter `liquidityEventCount` et `poolLifecycleEventCount` ; +- les décodeurs doivent maintenant émettre les événements utiles, au lieu de les classer comme inconnus ou de les ignorer. + +Première tranche couverte : Meteora DLMM. Les discriminants et hints suivants sont pris en charge comme événements non-trade utiles : + +| Event kind | Catégorie | Effet attendu | +|---|---|---| +| `meteora_dlmm.add_liquidity` | liquidity | persistance dans `k_sol_liquidity_events` quand le replay matérialise les decoded events | +| `meteora_dlmm.remove_liquidity` | liquidity | persistance dans `k_sol_liquidity_events` | +| `meteora_dlmm.initialize_position` | liquidity / position open | persistance dans `k_sol_liquidity_events` avec `LiquidityEventKind::PositionOpen`, sans génération de trade/candle | +| `meteora_dlmm.initialize_bin_array` | pool lifecycle | persistance dans `k_sol_pool_lifecycle_events` | + +Invariant maintenu : ces événements peuvent améliorer le scoring, le contexte de pool et le diagnostic, mais ne doivent jamais créer directement de `trade_events`, pair metrics ou candles. + ## 6. Politique de refactor actuelle Le code et la documentation sont vivants. Les refactors agressifs sont acceptables lorsque cela rend le pipeline plus propre et plus durable, à condition de respecter ces limites : @@ -219,18 +233,16 @@ Les tests peuvent rester plus souples lorsque cela clarifie le test. La reprise doit suivre cet ordre : -1. conserver la classification `0.7.33` : les paires matérialisées doivent être classées par readiness trading sans transformer les paires cross-quote ou inversées en erreurs bloquantes ; -2. conserver la sémantique `0.7.32` : les gaps littéraux de catalogue ne doivent pas être confondus avec les gaps bloquants/actionnables utilisés par la validation ; -3. conserver la non-régression `0.7.31` : transactions failed traçables mais exclues des `trade_events`, metrics et candles ; -4. utiliser la matrice `0.7.29` comme source commune pour le catalogue, la classification et les protocol candidates ; -5. relier progressivement les événements non-trade aux tables existantes : lifecycle, liquidité, fees, rewards, admin ; -6. consolider Meteora, surtout `meteora_dlmm` et le cas partiel `meteora_damm_v1` ; -7. ajouter les launch surfaces manquantes comme origines de mint : LaunchLab/Launchpad, LetsBonk/Bonk.fun, Boop.fun, Moonshot/Moonit, Believe, Bags ; -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.31` : transactions failed traçables mais exclues des `trade_events`, metrics et candles ; +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 9d94b38..8ef818c 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -846,38 +846,27 @@ Réalisé : - exposer `resetMarketMaterializationDeletedCount` dans le résultat de replay UI ; - conserver la validation multi-DEX et la matrice DEX comme garde-fous avant d’ajouter les surfaces restantes. -### 6.064. Version `0.7.32` — Sémantique des diagnostics et compteurs de validation +### 6.064. Version `0.7.32` — Transactions inconnues et protocol candidates Réalisé : -- conserver la politique `0.7.31` : transactions failed traçables mais exclues des `trade_events`, metrics et candles ; -- clarifier que `pairWithoutTradeCount` et `pairWithoutCandleCount` sont des compteurs de gaps bloquants/actionnables, pas des compteurs littéraux sur tout le catalogue ; -- ajouter `literalPairWithoutTradeCount` et `literalPairWithoutCandleCount` pour les paires de catalogue sans trade/candle matérialisé ; -- ajouter `blockingPairWithoutTradeCount` et `blockingPairWithoutCandleCount` comme noms explicites des anciens compteurs bloquants ; -- ajouter les compteurs de matérialisation par paire : `tradeMaterializedPairCount`, `candleMaterializedPairCount`, `actionablePairCount`, `candleBucketTimeframeCount` et `candlesAreBucketed` ; -- ajouter `pairActionabilitySummaries` pour distinguer les paires matérialisées, actionnables sans matérialisation, candidates failed, non-actionables, décodées sans trade candidate et catalog-only ; -- ajouter le profil `0.7.32_validation_report_semantics` ; -- ajouter des garde-fous de validation sur la matrice DEX : entrées `supported` entièrement matérialisées, entrées `partial` avec `skipReason`, entrées `planned/to_verify` non activées au catalogue ; -- ne pas modifier la logique de replay, trade aggregation ou candle aggregation validée en `0.7.31`. +- 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, +- garantir que ces tables n’alimentent jamais directement les trades/candles. -Repoussé après cette clarification : consolider les transactions inconnues et protocol candidates sans polluer les trades/candles. - -### 6.065. Version `0.7.33` — Readiness trading des paires +### 6.065. Version `0.7.33` — Pair trading readiness et routes de cotation Réalisé : -- ajouter une classification diagnostique `pairTradingReadiness` pour chaque paire inspectée localement ; -- distinguer `direct_wsol_quote`, `direct_stable_quote`, `inverse_wsol_base`, `inverse_stable_base`, `cross_quote_requires_router`, `unknown_quote` et `non_trade_materialized` ; -- exposer `quoteAssetClass` et `tradingRouteRequired` dans les diagnostics par paire ; -- ajouter `pairTradingReadinessSummaries` dans le résumé local du pipeline ; -- ajouter le profil `0.7.33_pair_trading_readiness` ; -- valider que les résumés de readiness couvrent toutes les paires et restent cohérents avec les compteurs `tradeMaterializedPairCount`, `tradeEventCount` et `pairCandleCount` ; -- ne pas modifier la logique de replay, `trade_events`, metrics ou candles. - -Objectif : préparer la future couche d’achat/vente en distinguant les paires immédiatement exploitables contre WSOL/stable des paires qui nécessitent inversion de lecture ou routeur/aggregator. +- classifier les paires `direct_wsol_quote`, `direct_stable_quote`, `inverse_wsol_base`, `inverse_stable_base`, `cross_quote_requires_router` et `non_trade_materialized` ; +- exposer `quoteAssetClass` et `tradingRouteRequired` dans les diagnostics ; +- éviter de bloquer la validation sur des paires seulement listées ou détectées sans trade matérialisé ; +- préparer la future sélection des paires directement tradables versus paires nécessitant un router. ### 6.066. Version `0.7.34` — Événements non-trade v1 : liquidité et cycle de vie pool -Objectif : exploiter les événements utiles à l’analyse et au trading semi-automatique sans les mélanger avec les swaps/candles. - -À faire : +Réalisé : - stabiliser et étendre `k_sol_liquidity_events` au lieu de la recréer inutilement, - ajouter `k_sol_pool_lifecycle_events`, @@ -886,6 +875,10 @@ Objectif : exploiter les événements utiles à l’analyse et au trading semi-a - conserver le `payload_json` source pour audit, - alimenter les diagnostics locaux avec les compteurs liquidité/lifecycle, - garantir qu’un événement de liquidité ou de cycle de vie ne produit jamais de candle directement. +- première tranche DLMM : reconnaître et persister `meteora_dlmm.add_liquidity`, `meteora_dlmm.remove_liquidity`, `meteora_dlmm.initialize_position` et `meteora_dlmm.initialize_bin_array` comme événements non-trade utiles ; +- intégrer la matérialisation non-trade dans les backfills ciblés token/pool, pas uniquement dans le replay local, afin que les diagnostics reflètent immédiatement les événements DLMM non-trade décodés ; +- distinguer `PositionOpen` et `PositionClose` dans `LiquidityEventKind` au lieu de rabattre les positions CLMM/DLMM sur `Add`/`Remove` ; +- conserver `meteora_damm_v1` manquant comme warning non bloquant lorsque le corpus de backfill local ne contient pas ce DEX. ### 6.067. Version `0.7.35` — Événements non-trade v2 : fees, rewards et administration Objectif : conserver les événements utiles au risque, au scoring, à l’économie du pool et à la traçabilité opérationnelle. @@ -1227,19 +1220,17 @@ Le projet doit maintenir au minimum : La priorité immédiate est désormais la suivante : 1. conserver la validation acquise `0.7.31` : transactions failed traçables mais exclues des `trade_events`, metrics et candles, aucun trade/candle candidate sans payload montant/prix exploitable, aucun diagnostic bloquant masqué, -2. conserver la clarification `0.7.32` entre gaps littéraux de catalogue et gaps bloquants/actionnables, -3. conserver la classification `0.7.33` des paires par readiness trading : direct WSOL/stable, inverse WSOL/stable, cross-quote avec routeur requis, inconnue ou non matérialisée, -4. 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, -5. garder les clients HTTP/WS et managers réseau hors du refactor DEX tant qu’ils ne bloquent pas le pipeline, -6. 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, -6. 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, -7. consolider Meteora avec corpus fiable : `meteora_dlmm`, `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc` et `meteora_dlc` si le programme est confirmé, -8. consolider Orca, FluxBeam et DexLab sur corpus, -9. traiter `raydium_amm_v4` legacy seulement après les autres Raydium, avec corpus dédié prouvant le programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, -10. 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, -11. 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, -12. ajouter ensuite les overlays des signaux analytiques sur les candles, -13. consolider les vues métier `token / pair / pool` dans `kb_demo_app`, y compris les événements liquidité, lifecycle, fees, rewards et admin, -14. stabiliser l’ergonomie, les filtres, la pagination et la navigation de l’UI d’inspection, -15. préparer ensuite l’ouverture de `0.8.x` pour l’analyse, les filtres, les patterns et les projections graphiques, -16. préparer enfin Yellowstone gRPC comme extension de capacité, et non comme remplacement du socle HTTP / WS existant. +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 7fa04fa..86a3e9c 100644 --- a/kb_demo_app/frontend/demo_pipeline2.html +++ b/kb_demo_app/frontend/demo_pipeline2.html @@ -166,7 +166,8 @@