Sasedev/khadhroony-bobobot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.7.28

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-05-11 11:02:47 +02:00
parent d66afede28
commit 7f130dba6b
49 changed files with 10301 additions and 8481 deletions
Download Patch File Download Diff File Expand all files Collapse all files

344
ROADMAP.md
View File

@@ -749,9 +749,7 @@ Réalisé :
- seuls les trade candidates issus de transactions échouées restent ignorés.
### 6.059. Version `0.7.27` — Validation multi-DEX des connecteurs déjà branchés
Objectif : verrouiller la non-régression du pipeline actuel avant d’ajouter de nouveaux DEX ou d’ouvrir la phase d’analyse `0.8.x`.
À faire :
Réalisé :
- rejouer des bases neuves de test pour `pump_fun`, `pump_swap`, `raydium_cpmm` et `raydium_clmm`,
- ne pas ajouter de nouveau DEX dans cette version ; cette version sert uniquement à valider les connecteurs déjà branchés,
@@ -765,60 +763,147 @@ Objectif : verrouiller la non-régression du pipeline actuel avant d’ajouter d
- conserver la tolérance aux événements DEX partiels tout en refusant les trades sans montant ou prix exploitable,
- 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` — Matérialisation des événements liquidité et cycle de vie pool
Objectif : exploiter les événements non buy/sell utiles à l’analyse et au trading semi-automatique sans les mélanger avec les trades/candles.
### 6.060. Version `0.7.28` — Refactor DEX commun et préparation extension
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,
- créer une représentation interne documentée pour les familles d’événements DEX afin d’éviter les chaînes dispersées dans plusieurs fichiers,
- clarifier la différence entre événement décodé, événement actionnable, trade candidate, candle candidate et événement conservé seulement pour analyse,
- simplifier `dex_decode.rs` en gardant son rôle de service de persistance-orchestration,
- simplifier `dex_detect.rs` en extrayant les helpers communs pool/pair/listing/origin/wallet quand cela réduit la duplication,
- homogénéiser les contrats des modules `kb_lib/src/dex/*.rs` sans imposer trop tôt un trait générique lourd,
- vérifier la rustdoc publique : utile, courte, orientée responsabilité ; supprimer la documentation redondante ou trop chargée,
- conserver les tests verts et ajouter des tests de non-régression sur les catégories d’événements existantes.
Contraintes :
- refactor agressif autorisé si le résultat est plus propre,
- chaque changement doit rester rejouable et testable,
- 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é.
À faire :
- stabiliser ou ajouter la table `k_sol_liquidity_events`,
- stabiliser ou ajouter la table `k_sol_pool_lifecycle_events`,
- matérialiser les événements de type `increase_liquidity`, `decrease_liquidity`, `add_liquidity`, `remove_liquidity`, `open_position`, `close_position`, `initialize`, `create_pool`, `migrate` et assimilés,
- rattacher chaque événement métier à `dex_id`, `pool_id`, `pair_id`, `transaction_id`, `decoded_event_id`, `signature` et `slot`,
- conserver le `payload_json` source pour audit et extension future,
- alimenter les diagnostics locaux avec les compteurs liquidité et cycle de vie,
- garantir qu’un événement de liquidité ou de cycle de vie ne produit jamais de candle directement,
- préparer les signaux futurs liés à la liquidité initiale, à l’ajout/retrait brutal de liquidité, aux migrations et aux changements de statut de pool.
- 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.
### 6.061. Version `0.7.29` — Matérialisation des événements fees, rewards et administration
Objectif : conserver les événements non price-action utiles au risque, à l’analyse économique et à la traçabilité opérationnelle des pools.
Matrice cible initiale :
| Code cible | Type | Statut | 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 |
### 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 ou stabiliser `k_sol_fee_events`,
- ajouter ou stabiliser `k_sol_reward_events`,
- ajouter ou stabiliser `k_sol_pool_admin_events`,
- 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,
- 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.
### 6.063. Version `0.7.31` — É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 :
- stabiliser et étendre `k_sol_liquidity_events` au lieu de la recréer inutilement,
- ajouter `k_sol_pool_lifecycle_events`,
- matérialiser les événements `initialize`, `create_pool`, `migrate`, `open_position`, `close_position`, `increase_liquidity`, `decrease_liquidity`, `add_liquidity`, `remove_liquidity` et assimilés,
- rattacher chaque événement à `dex_id`, `pool_id`, `pair_id`, `transaction_id`, `decoded_event_id`, `signature` et `slot` lorsque les informations existent,
- 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.
### 6.064. Version `0.7.32` — É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.
À faire :
- ajouter `k_sol_fee_events`,
- ajouter `k_sol_reward_events`,
- ajouter `k_sol_pool_admin_events`,
- matérialiser les événements `collect_protocol_fee`, `collect_fund_fee`, `collect_creator_fee`, `collect_fee` et assimilés,
- matérialiser les événements `set_reward_params`, `initialize_reward`, `collect_reward`, `update_reward_infos` et assimilés,
- matérialiser les événements `set_config`, `update_config`, `set_authority`, `set_fee_rate`, `pause`, `resume` et assimilés,
- rattacher chaque événement à la transaction, au decoded event, au pool, à la paire et aux wallets observés lorsque les comptes sont disponibles,
- documenter clairement que ces événements sont utiles à l’analyse et au scoring mais ne sont ni des trades ni des candles.
- rattacher ces événements aux transactions, decoded events, pools, paires et wallets observés lorsque les comptes le permettent,
- documenter clairement que ces événements ne sont ni des trades ni des candles.
### 6.062. Version `0.7.30` — Meteora : DBC / DAMM v1 / DAMM v2
Objectif : ajouter ou stabiliser les connecteurs Meteora avec une séparation claire entre swaps, liquidité, fees, rewards et événements pool.
### 6.065. Version `0.7.33` — Meteora : DBC / DAMM v1 / DAMM v2 / DLMM
Objectif : consolider Meteora comme famille multi-programmes au lieu de traiter chaque variante comme un cas isolé incomplet.
À faire :
- vérifier les programmes et discriminants réellement utilisés pour `Meteora DBC`, `Meteora DAMM v1` et `Meteora DAMM v2`,
- constituer un petit corpus local de pools et signatures fiables pour chaque variante,
- décoder les créations de pool, swaps et événements de liquidité exploitables,
- alimenter `k_sol_dex_decoded_events`, les tables métier pool/pair/listing et les nouvelles tables d’événements non-trade,
- vérifier l’idempotence du replay local sur un corpus mixte Meteora,
- documenter les limites connues des variantes insuffisamment couvertes par le corpus.
- vérifier les programmes et discriminants réellement utilisés pour `Meteora DBC`, `Meteora DAMM v1`, `Meteora DAMM v2` et `Meteora DLMM`,
- ajouter `meteora_dlmm` à la couverture cible seulement après corpus fiable,
- constituer un corpus local par variante,
- décoder les créations de pool, swaps, liquidités et événements lifecycle exploitables,
- identifier les cas où `DBC` sert de launch origin avant migration vers un AMM,
- alimenter `k_sol_dex_decoded_events`, les tables pool/pair/listing, les origins et les tables non-trade,
- vérifier l’idempotence du replay local sur un corpus Meteora mixte,
- documenter les limites connues des variantes insuffisamment couvertes.
### 6.063. Version `0.7.31` — Launch DEX : LaunchLab / Fun Launch / Bags / Moonit
Objectif : couvrir les surfaces de lancement et de migration de tokens sans confondre origine de lancement et protocole DEX final.
### 6.066. Version `0.7.34` — 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.
À faire :
- ajouter ou stabiliser les mappings `LaunchLab`, `Fun Launch`, `Bags` et `Moonit`,
- distinguer clairement launch origin, pool origin et DEX effectif,
- détecter les créations de token, pools initiaux, migrations et listings dérivés,
- 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,
- enrichir les diagnostics pour exposer les objets détectés par surface de lancement,
- éviter les heuristiques trop larges lorsqu’un suffixe de mint ou un label externe ne suffit pas à prouver l’origine.
- exposer les origins dans les diagnostics et l’UI d’inspection.
### 6.064. Version `0.7.32` — Orca / FluxBeam / DexLab : corpus et validation ciblée
Objectif : ajouter les connecteurs restants à partir de corpus locaux vérifiables et garder les décodeurs heuristiques isolés tant qu’ils ne sont pas prouvés.
### 6.067. Version `0.7.35` — Heaven : corpus, launch et AMM
Objectif : ajouter Heaven sans le classer trop tôt comme simple DEX ou simple launchpad.
À 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é.
### 6.068. Version `0.7.36` — Orca / FluxBeam / DexLab : corpus et validation ciblée
Objectif : consolider les connecteurs déjà présents à partir de corpus locaux vérifiables.
À faire :
@@ -829,32 +914,33 @@ Objectif : ajouter les connecteurs restants à partir de corpus locaux vérifiab
- 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.
### 6.065. Version `0.7.33` — Validation DEX v1 consolidée
Objectif : rejouer tous les DEX supportés et valider les invariants du pipeline complet avant de traiter Raydium AMM v4 legacy séparément.
À faire :
- rejouer des bases neuves couvrant tous les connecteurs DEX supportés hors `raydium_amm_v4` legacy,
- 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,
- conserver une matrice de support par DEX, variante, instruction et type d’événement.
### 6.066. Version `0.7.34` — Raydium AMM v4 legacy : corpus et validation ciblée
Objectif : traiter le vrai Raydium AMM v4 historique après les autres DEX, afin de l’isoler correctement de `raydium_cpmm`, `raydium_clmm` et des labels Raydium génériques.
### 6.069. Version `0.7.37` — 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.
À faire :
- rechercher des pools réellement rattachés au programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`,
- constituer un petit corpus local de signatures/pools AMM v4 fiables pour les tests,
- vérifier que les adresses issues de Dexscreener ou d’autres explorateurs ne sont pas seulement catégorisées globalement comme `Raydium`,
- 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 la prise en charge `initialize2` et identifier les instructions de swap AMM v4 à supporter si elles apparaissent dans les transactions testées,
- renommer et stabiliser les fonctions internes autour de `raydium_amm_v4` afin d’éviter l’ambiguïté avec `raydium_cpmm` et `raydium_clmm`,
- documenter les limites connues si le corpus AMM v4 reste trop faible.
- 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.
### 6.067. Version `0.7.35` — `kb_demo_app` : overlays analytiques
### 6.070. Version `0.7.38` — Validation DEX v1 consolidée
Objectif : rejouer tous les DEX et launch surfaces supportés et valider les invariants du pipeline complet.
À 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,
- verrouiller les invariants avant d’ouvrir l’analyse `0.8.x`.
### 6.071. Version `0.7.39` — `kb_demo_app` : overlays analytiques
Objectif : rendre visibles les signaux analytiques directement sur les graphes et vues de marché.
À faire :
@@ -863,9 +949,9 @@ Objectif : rendre visibles les signaux analytiques directement sur les graphes e
- 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 des indicateurs Ichimoku, Kumo, projections ABCD et égalités temps/prix sans les mélanger au pipeline de décodage DEX.
- 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.068. Version `0.7.36` — `kb_demo_app` : vues consolidées token / pair / pool
### 6.072. Version `0.7.40` — `kb_demo_app` : vues consolidées token / pair / pool
Objectif : fournir une lecture métier plus confortable du modèle `0.7.x`.
À faire :
@@ -873,11 +959,11 @@ Objectif : fournir une lecture métier plus confortable du modèle `0.7.x`.
- 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é, événements lifecycle, fees, rewards, admin, candles et analytic signals,
- 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.069. Version `0.7.37` — Finition UI `0.7.x`
### 6.073. Version `0.7.41` — Finition UI `0.7.x`
Objectif : stabiliser la couche desktop de validation avant l’ouverture de `0.8.x`.
À faire :
@@ -886,41 +972,52 @@ Objectif : stabiliser la couche desktop de validation avant l’ouverture de `0.
- 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` et ne récupèrent pas de logique métier.
- vérifier que les commandes Tauri restent de simples façades vers `kb_lib`.
### 6.070. Version `0.7.x` — Couverture DEX v1
Objectif : structurer les connecteurs DEX autour d’un pipeline complet de résolution, décodage et normalisation métier.
### 6.074. 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 cibles :
Protocoles et surfaces cibles :
- Pump.fun
- PumpSwap
- Raydium CPMM
- Raydium CLMM
- Meteora DBC
- Meteora DAMM v2
- Meteora DAMM v1
- LaunchLab / Fun Launch
- Bags
- Moonit
- Orca
- FluxBeam
- DexLab
- Raydium AMM v4 legacy
- 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,
- création d’objets métier riches pour tokens, pools, paires, listings, participants et holdings observés,
- 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 claire entre événements candle/trade et événements utiles seulement à l’analyse, aux frais, à la liquidité, aux rewards, à l’administration ou au cycle de vie des pools,
- 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`.
- préparation d’agrégats DEX plus riches, de candles/OHLCV et d’une UI d’inspection du pipeline `0.7.x`.
### 6.071. Version `0.8.x` — Analyse et filtrage
### 6.075. Version `0.8.x` — Analyse et filtrage
Objectif : transformer les événements bruts en signaux exploitables.
À faire :
@@ -935,7 +1032,7 @@ Objectif : transformer les événements bruts en signaux exploitables.
- 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.072. Version `1.x.y` — Wallets et swap préparatoire
### 6.076. Version `1.x.y` — Wallets et swap préparatoire
Objectif : préparer la couche d’action.
À faire :
@@ -946,7 +1043,7 @@ Objectif : préparer la couche d’action.
- préparation d’ordres et de swaps,
- simulation et garde-fous.
### 6.073. Version `2.x.y` — Trading semi-automatisé
### 6.077. Version `2.x.y` — Trading semi-automatisé
Objectif : brancher l’analyse à l’action tout en gardant des garde-fous explicites.
À faire :
@@ -957,7 +1054,7 @@ Objectif : brancher l’analyse à l’action tout en gardant des garde-fous exp
- confirmations explicites ou semi-automatiques,
- journaux d’exécution.
### 6.074. Version `3.x.y` — Yellowstone gRPC
### 6.078. Version `3.x.y` — Yellowstone gRPC
Objectif : ajouter le connecteur gRPC dédié.
À faire :
@@ -970,41 +1067,59 @@ Objectif : ajouter le connecteur gRPC dédié.
## 7. Organisation des modules ciblés
### 7.1. `kb_lib`
Modules cibles à court terme :
Modules stables à ne pas remanier dans la phase immédiate :
- `error.rs`
- `config.rs`
- `tracing.rs`
- `constants.rs`
- `types.rs`
- `ws_client.rs`
- `ws_manager.rs`
- `http_client.rs`
- `http_pool.rs`
- `json_rpc_ws.rs`
- `solana_pubsub_ws.rs`
- `detect.rs`
Modules ciblés par le refactor et la consolidation DEX :
- `dex.rs`
- `dex/*.rs`
- `dex_decode.rs`
- `dex_detect.rs`
- `trade_aggregation.rs`
- `pair_candle_aggregation.rs`
- `pair_analytic_signal.rs`
- `launch_origin.rs`
- `pool_origin.rs`
- `wallet_observation.rs`
- `wallet_holding_observation.rs`
- `token_metadata.rs`
- `local_pipeline_replay.rs`
- `local_pipeline_validation.rs`
- `local_pipeline_diagnostics.rs`
- `db/entities/*`
- `db/dtos/*`
- `db/queries/*`
### 7.2. `kb_demo_app`
`local_pipeline_diagnostics.rs` est volontairement conservé comme outil temporaire de validation. Il pourra devenir obsolète ou être remplacé lorsque les tests DEX seront stabilisés. Il n’est pas prioritaire de le refactorer maintenant.
### 7.2. Base de données
Organisation de la couche DB à conserver :
- `db/schema.rs` : création des tables et index uniquement ; chaque table ou index reste dans une fonction dédiée,
- `db/entities/*` : entités proches des lignes persistées,
- `db/dtos/*` : DTOs applicatifs,
- `db/queries/*` : requêtes SQL regroupées par table ou usage,
- `db/queries/local_pipeline_diagnostics.rs` : requêtes de diagnostic local, utiles pendant la validation DEX.
`schema.rs` peut rester long tant qu’il reste strictement un fichier de schéma. Le split prioritaire concerne plutôt les responsabilités métier dans `dex_decode.rs`, `dex_detect.rs` et `trade_aggregation.rs`.
### 7.3. `kb_demo_app`
Responsabilités cibles :
- lancement Tauri,
- commandes UI,
- affichage des états et messages,
- réception des événements venant de `kb_lib`,
- persistance future des préférences UI,
- fenêtres de démonstration / diagnostic isolées.
- fenêtres de démonstration / diagnostic isolées,
- inspection du pipeline persisté,
- affichage candles et futurs overlays analytiques.
`kb_demo_app` ne doit pas contenir de logique métier DEX profonde.
## 8. Ligne de conduite sur le `WsClient`
Le `WsClient` doit être conçu en plusieurs couches :
@@ -1048,7 +1163,7 @@ Le projet doit maintenir au minimum :
- un `README.md` global,
- un `ROADMAP.md` global,
- un `CHANGELOG.md` global,
- des `README.md` et `TODO.md` par crate à mesure de l’évolution,
- des `README.md` et `TODO.md` par crate à mesure de l’évolution (surtout en version 1.0),
- des tests unitaires robustes,
- les bindings TS générés via `cargo test export_bindings` lorsque les types partagés évoluent.
@@ -1056,16 +1171,21 @@ Le projet doit maintenir au minimum :
La priorité immédiate est désormais la suivante :
1. terminer la validation `0.7.27` sur les connecteurs déjà branchés : `pump_fun`, `pump_swap`, `raydium_cpmm` et `raydium_clmm`, sans ajouter de nouveau DEX dans cette étape,
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. documenter les requêtes SQL de diagnostic de référence et les résultats attendus pour les tables clés du pipeline,
4. matérialiser ensuite les événements non buy/sell utiles au trading et à l’analyse : liquidité, cycle de vie des pools, fees, rewards et administration,
5. 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,
6. ajouter ou stabiliser les autres DEX par lots vérifiables : Meteora, surfaces de lancement, Orca, FluxBeam et DexLab,
7. traiter `raydium_amm_v4` legacy seulement après les autres DEX, avec un corpus dédié prouvant le programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`,
8. 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,
9. ajouter ensuite les overlays des signaux analytiques sur les candles,
10. consolider les vues métier `token / pair / pool` dans `kb_demo_app`, y compris les événements liquidité, lifecycle, fees, rewards et admin,
11. stabiliser l’ergonomie, les filtres, la pagination et la navigation de l’UI d’inspection,
12. préparer ensuite l’ouverture de `0.8.x` pour l’analyse, les filtres, les patterns et les projections graphiques,
13. préparer enfin Yellowstone gRPC comme extension de capacité, et non comme remplacement du socle HTTP / WS existant.
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.