khadhroony-bobobot/ROADMAP.md

khadhroony-bobobot — Roadmap

1. Objet du projet

khadhroony-bobobot est un workspace Rust destiné à la détection, l’observation, l’analyse de patterns et, à terme, à l’exécution semi-automatisée d’achats/ventes de tokens sur la blockchain Solana.

Le projet vise en priorité :

• la détection de création de tokens et de paires sur différents DEX,
• la réception et le tri des événements on-chain et RPC,
• la collecte de métriques utiles au filtrage,
• l’analyse statistique et comportementale des patterns,
• la préparation d’une couche wallet puis swap/trading.

2. Principes d’architecture

2.1. Structure générale

Le workspace est organisé autour de deux sous-crates principales :

• kb_lib : bibliothèque métier, réseau, config, tracing, stockage, analyse et logique applicative.
• kb_app : application Tauri V2 avec frontend TypeScript, chargée de l’interface et de la délégation vers kb_lib.

2.2. Contraintes de code

Le socle du projet doit respecter les contraintes suivantes :

• Rust 2024.
• Aucun fichier mod.rs.
• Exposition centralisée à la racine des crates via lib.rs ou main.rs.
• Pas d’usage de anyhow ni thiserror.
• Pas d’usage de ?, unwrap, expect dans le code applicatif.
• Utilisation de match, if let Err, let Err = ... else.
• Documentation Rust obligatoire sur les éléments publics.
• #![deny(unreachable_pub)] et #![warn(missing_docs)] activés et respectés.
• Pas de use pour les types/fonctions externes, sauf pour les traits.
• Tests unitaires importants et maintenus à chaque étape.

2.3. Règles de responsabilité

• kb_app ne doit pas embarquer la logique métier réseau ou Solana.
• kb_app doit seulement orchestrer l’UI, les commandes Tauri et les appels vers kb_lib.
• kb_lib doit porter les clients réseau, la config, le tracing, les types partagés, les registres et la logique métier.

3. Vision fonctionnelle

Le projet doit pouvoir évoluer progressivement vers les capacités suivantes :

1. Connexion à plusieurs endpoints HTTP / WS RPC Solana.
2. Répartition des rôles par endpoint.
3. Réception des notifications de slots, comptes, programmes, logs, signatures, blocs.
4. Détection de créations de tokens, pools et paires sur plusieurs DEX.
5. Collecte de métriques : liquidité, market cap, volume, prix, activité.
6. Persistance locale dans SQLite, puis évolution possible vers PostgreSQL.
7. Analyse de patterns et filtrage des tokens non tradables.
8. Gestion de wallets Solana.
9. Préparation puis exécution semi-automatisée de swaps/trading.
10. Intégration future de gRPC Yellowstone.

4. Configuration cible

La configuration applicative est stockée dans un fichier config.json.

4.1. Points à couvrir dans la configuration

Le fichier doit permettre de configurer :

• les endpoints HTTP,
• les endpoints WebSocket,
• un nom logique par endpoint,
• le rôle ou les tâches affectées à chaque endpoint,
• les limites de débit par endpoint,
• les options spécifiques aux providers publics ou privés,
• les chemins de stockage local,
• le répertoire des wallets Solana,
• le tracing et ses formats,
• la stratégie de reconnexion,
• les paramètres de base de données,
• les options d’UI persistées plus tard.

4.2. Exemple de catégories attendues

• app
• logging
• database
• wallets
• network
• solana
• http_endpoints
• ws_endpoints

4.3. Exigences particulières

Chaque endpoint doit pouvoir porter sa propre configuration, par exemple :

• nom logique,
• URL,
• provider,
• présence ou non d’une clé API,
• variable d’environnement pour clé API,
• plafond de requêtes,
• burst,
• timeout,
• usages autorisés,
• rôle principal.

Exemples de rôles futurs :

• slot_notifications
• program_subscriptions
• account_subscriptions
• logs_subscriptions
• http_queries
• fallback

5. Tracing cible

Le tracing est centralisé dans kb_lib.

5.1. Exigences initiales

• sortie console paramétrable,
• sortie fichier paramétrable,
• niveau de log configurable,
• format du message configurable,
• format du temps configurable,
• ANSI console activable/désactivable,
• fonctionnement compatible tests,
• séparation claire entre initialisation et usage.

5.2. Objectifs complémentaires

• pouvoir distinguer les logs du transport WS,
• distinguer les logs HTTP,
• distinguer les logs Tauri/UI,
• distinguer les logs DB,
• préparer une traçabilité par endpoint et par client.

6. Phasage par versions

6.001. Version 0.0.2 — Socle conforme

Objectif : corriger le squelette et poser la base de travail.

Réalisé :

• correction de kb_lib/src/lib.rs,
• création de KbError,
• création de KbConfig,
• création de init_tracing,
• création des constantes Solana officielles,
• préparation des modules ws_client et http_client,
• remise de kb_app/src/lib.rs en conformité,
• documentation de kb_app/src/splash.rs,
• UI Tauri minimale.

6.002. Version 0.1.x — Transport WebSocket générique

Objectif : construire un vrai WsClient asynchrone clonable.

Réalisé :

• connect, disconnect, connection_state,
• flux de lecture séparé du flux d’écriture,
• identifiant incrémental interne par client,
• canal sortant borné,
• émission d’événements internes,
• support de l’arrêt propre,
• fermeture avec timeout,
• tests offline avec serveur mock.

6.003. Version 0.1.1 — Intégration Tauri minimale du WsClient

Objectif : valider le transport via l’application desktop.

Réalisé :

• intégration minimale de WsClient dans kb_app,
• boutons start/stop,
• zone de logs,
• validation du flux frontend -> tauri -> kb_lib -> frontend.

6.004. Version 0.2.0 — Couche JSON-RPC WS Solana

Objectif : séparer clairement transport, réponses RPC et notifications.

Réalisé :

• enveloppes JSON-RPC 2.0,
• gestion des request_id,
• parsing des réponses et erreurs,
• parsing des notifications,
• premiers helpers JSON-RPC sur WsClient.

6.005. Version 0.3.0 — Registre subscriptions / notifications

Objectif : fiabiliser la gestion des subscriptions.

Réalisé :

• stockage des subscriptions actives,
• mapping entre requête de subscribe et subscription_id serveur,
• unsubscribe propre avant fermeture,
• timeout d’attente sur unsubscribe,
• purge locale si nécessaire,
• routage séparé des notifications.

6.006. Version 0.3.1 — Helpers subscribe/unsubscribe WebSocket

Objectif : ajouter les helpers haut niveau correspondant aux principales méthodes PubSub Solana.

Réalisé :

• helpers pour account, block, logs, program, root, signature, slot, slotsUpdates, vote,
• helpers d’unsubscribe correspondants,
• premiers tests de validation des noms de méthodes.

6.007. Version 0.3.2 — Helpers typed et notifications typed

Objectif : s’appuyer principalement sur solana-rpc-client-api pour typer les subscribe et les notifications.

Réalisé :

• helpers typed pour account, block, logs, program, signature,
• parsing typed des notifications,
• base de travail pour réduire l’usage direct de serde_json::Value.

6.008. Version 0.3.3 — Distinction API typed / raw

Objectif : clarifier l’API publique de WsClient.

Réalisé :

• suffixe _raw sur les helpers raw,
• conservation des helpers typed comme interface plus propre,
• préparation d’une hiérarchie API plus explicite.

6.009. Version 0.3.4 — Fenêtre Demo Ws dans kb_app

Objectif : tester manuellement les souscriptions live dans une fenêtre dédiée.

Réalisé :

• fenêtre séparée demo_ws,
• ouverture depuis la fenêtre principale,
• connexion/déconnexion d’un client de démo,
• test de souscriptions live,
• affichage des événements raw et typed,
• premiers tests réels sur wss://api.mainnet.solana.com.

6.010. Version 0.3.5 — Stabilisation de Demo Ws

Objectif : rendre la fenêtre de démonstration robuste sous flux élevé et cohérente avec la configuration.

Réalisé :

• lire correctement les endpoints activés depuis la config et refléter les URLs résolues avec api_key_env_var,
• améliorer la sélection réelle des endpoints affichés et utilisables,
• ajouter du throttling / rate limiting de l’affichage UI sous fort débit,
• limiter ou résumer les événements affichés côté fenêtre,
• conserver l’intégralité des traces côté tracing,
• éviter le gel de la fenêtre sur logsSubscribe et programSubscribe,
• conserver des compteurs et états UI exploitables,
• mieux gérer les fermetures/ralentissements d’endpoints publics.

6.011. Version 0.4.x — Transport HTTP générique et helpers RPC

Objectif : construire un HttpClient clonable, limité et extensible, puis ajouter les premiers helpers HTTP Solana.

6.012. Version 0.4.0 — Socle HttpClient

Réalisé :

• client reqwest asynchrone clonable,
• résolution d’URL avec support de api_key_env_var,
• limiteur local req/sec,
• burst configurable,
• délais configurables,
• profils par endpoint,
• abstraction JSON-RPC HTTP générique,
• premiers appels de validation Solana.

Livrables :

• HttpClient,
• enveloppes JSON-RPC HTTP,
• premiers appels :
  • getHealth
  • getVersion
  • getSlot

6.013. Version 0.4.1 — Helpers HTTP Solana

Réalisé :

• ajouter des helpers HTTP haut niveau comme pour le client WS,
• distinguer helpers raw et helpers typed quand cela est pertinent,
• couvrir les premières méthodes utiles du RPC HTTP Solana,
• conserver HttpClient comme couche générique réutilisable.

6.014. Version 0.4.2 — Politique HTTP avancée

Réalisé :

• préparer un état de pause avant envoi pour un endpoint HTTP,
• préparer plusieurs quotas par famille de méthodes,
• distinguer quota RPC général et quota sendTransaction,
• préparer un futur pool d’endpoints HTTP et l’arbitrage entre eux.

6.015. Version 0.4.3 — Pool d’endpoints HTTP

Réalisé :

• ajouter un pool d’HttpClient,
• sélectionner un endpoint selon le rôle demandé,
• ignorer les endpoints Paused ou Disabled,
• préparer une rotation simple entre endpoints actifs,
• prendre en compte la classe de méthode HTTP,
• préparer le routage multi-RPC et la limitation de concurrence par endpoint.

6.016. Version 0.4.4 — Démo HTTP dans kb_app

Réalisé :

• ajout d’une fenêtre Demo Http,
• ouverture depuis la fenêtre principale,
• exécution manuelle de méthodes HTTP via le pool d’endpoints,
• affichage des réponses JSON-RPC HTTP et des erreurs associées,
• affichage de l’état du pool HTTP et des statuts des endpoints,
• alignement visuel de la fenêtre sur le gabarit Demo Ws,
• amélioration des presets UI, copie de réponse et bascule pretty/raw.

6.017. Version 0.5.x — Base de données SQLite

Objectif : poser la persistance locale avec une organisation préparée dès le départ à une future évolution vers PostgreSQL ou un autre backend.

6.018. Version 0.5.0 — Socle SQLite

Réalisé :

• configuration DB dans config.json,
• ouverture/validation SQLite,
• façade KbDatabase,
• premier schéma technique,
• table kb_db_metadata,
• séparation db/entities, db/dtos, db/queries, db/types.

6.019. Version 0.5.1 — Premières tables métier de stockage local

Réalisé :

• ajout des tables de référence pour les endpoints connus HTTP/WS,
• ajout des tables techniques pour les événements runtime locaux,
• mise en place des entities, dtos, queries et types associés,
• préparation du stockage local des endpoints HTTP/WS connus et de leur état utile.

6.020. Version 0.5.2 — Stockage des tokens observés

Réalisé :

• ajout de la table kb_observed_tokens,
• stockage minimal des mints, symboles, noms, statuts et dates d’observation,
• ajout du token_program,
• préparation des relations futures avec pools, paires et événements on-chain,
• conservation d’unicité locale par mint sans duplication par endpoint.

6.021. Version 0.5.3 — Événements et signaux locaux

Réalisé :

• conservation des événements runtime techniques via kb_db_runtime_events,
• ajout des observations on-chain brutes via kb_onchain_observations,
• ajout des signaux d’analyse via kb_analysis_signals,
• distinction explicite entre événements runtime, observations on-chain et événements métier,
• préparation de la traçabilité de provenance par type de source et endpoint, sans remettre en cause l’unicité locale d’un token par mint.

6.022. Version 0.5.4 — Modèle métier normalisé initial

Réalisé :

• ajouter les tables de référence métier pour les DEX, tokens, pools et paires,
• distinguer clairement objets de référence et événements d’activité,
• préparer les relations entre tokens, pools, paires et listings,
• éviter que la détection technique 0.6.x écrive directement dans des tables trop brutes ou ambiguës.

6.023. Version 0.5.5 — Activité métier normalisée

Réalisé :

• ajout des tables de swaps,
• ajout des événements de liquidité,
• ajout des événements de mint et burn utiles au suivi des tokens,
• préparation de l’historique métier nécessaire avant l’arrivée des connecteurs DEX complets.

6.024. Version 0.5.6 — Consolidation de la couche stockage

Objectif : stabiliser le schéma avant la détection technique réelle.

À faire :

• conserver l’abstraction du backend dès le départ,
• limiter la dépendance directe au SQL concret aux modules queries,
• garder les conversions explicites entre entités DB et DTOs applicatifs,
• durcir les relations, contraintes et index utiles,
• préparer une future compatibilité PostgreSQL sans casser l’organisation générale.

6.025. Version 0.6.0 — Pipeline de détection technique

Objectif : relier les connecteurs RPC à la couche de stockage technique et métier.

À faire :

• ajouter une façade de persistance pour les observations et signaux issus des connecteurs,
• préparer l’enregistrement des candidats tokens détectés depuis les sources RPC,
• éviter que les futurs watchers RPC écrivent directement dans la DB sans couche intermédiaire,
• préparer les prochaines étapes de détection technique on-chain / RPC.

6.026. Version 0.6.1 — Détection technique RPC

Réalisé :

• ajout d’un bridge Solana WS notification -> pipeline de détection,
• persistance des notifications WS utiles comme observations on-chain normalisées,
• génération d’un candidat token quand une programNotification expose un mint SPL / Token-2022 en JSON parsé,
• préparation du branchement futur des watchers et règles RPC réelles sur une façade de détection unique.

6.027. Version 0.6.2 — Branchement WsClient vers la détection

Réalisé :

• ajouter un relais interne de notifications WS vers la couche de détection,
• permettre à WsClient de forwarder les JsonRpcWsNotification vers un worker dédié,
• conserver le découplage entre transport WS et logique de détection,
• éviter de bloquer la boucle de lecture WS si la détection est lente.

6.028. Version 0.6.3 — Enrichissement des notifications WS utiles

Réalisé :

• enrichir accountNotification, logsNotification et signatureNotification,
• mieux extraire slot, pubkey, signature, owner, parsed account type et clés pertinentes,
• produire des observations plus précises et plus homogènes,
• préparer les règles de détection techniques réelles.

6.029. Version 0.6.4 — Premières règles de détection technique

Réalisé :

• détection des premiers candidats pools/listings techniques depuis programNotification,
• appui sur les DEX connus en base via program_id / router_program_id,
• enregistrement des pools candidats et de leur listing initial sans parsing DEX complet,
• alimentation conjointe des observations techniques, signaux d’analyse et tables métier normalisées,
• maintien d’une logique encore indépendante des connecteurs DEX 0.7.x.

6.030. Version 0.6.5 — Orchestration multi-clients WebSocket

Réalisé :

• introduction d’une abstraction ws_manager.rs pour piloter plusieurs WsClient,
• construction des clients WS activés depuis la configuration d’endpoints,
• démarrage et arrêt centralisés par endpoint ou globalement,
• republication d’un flux unifié de WsEvent pour l’ensemble des clients gérés,
• branchement optionnel du relais de détection WS sur tous les clients orchestrés,
• préparation des futures politiques de répartition, supervision et reconnexion.

6.031. Version 0.6.6 — Démo légère WsManager dans kb_app

Réalisé :

• ajout d’une fenêtre Demo Ws Manager dans kb_app,
• ouverture depuis la fenêtre principale,
• affichage du snapshot consolidé du WsManager,
• pilotage des endpoints WS gérés via start/stop all et start/stop role,
• visualisation du flux unifié de WsEvent,
• validation UI du branchement centralisé du relais de détection,
• amélioration des messages de log UI pour les actions idempotentes déjà démarrées ou déjà arrêtées.

6.032. Version 0.7.0 — Résolution transactionnelle orientée DEX

Réalisé :

• introduction d’une file de résolution transactionnelle alimentée par les signatures issues des flux WS utiles,
• corrélation initiale des logsNotification et signatureNotification avec des appels getTransaction,
• utilisation du pool HTTP existant pour enrichir les signaux détectés côté WS,
• persistance des résolutions transactionnelles dans kb_onchain_observations et kb_analysis_signals,
• préparation du futur modèle transactionnel enrichi sans bloquer les flux temps réel.

6.033. Version 0.7.1 — Modèle transactionnel Solana enrichi

Réalisé :

• ajout des tables techniques kb_chain_slots, kb_chain_transactions et kb_chain_instructions,
• distinction claire entre slot, transaction résolue et instructions normalisées,
• support des instructions principales et inner instructions,
• ajout des entités, DTOs et requêtes associées,
• ajout d’un service de projection pour transformer une transaction JSON-RPC résolue en modèle transactionnel interne,
• ajout des tests de roundtrip et de projection.

6.034. Version 0.7.2 — Décodeurs DEX spécifiques par programme et version

Réalisé :

• ajout d’un premier décodeur transactionnel spécifique Raydium AmmV4 / initialize2,
• lecture combinée du transaction_json et des instructions projetées,
• extraction des comptes utiles à l’initialisation du pool,
• persistance des événements DEX décodés dans une table dédiée,
• émission d’observations et de signaux dérivés du décodage DEX,
• branchement automatique du décodage DEX depuis le pipeline de résolution transactionnelle,
• préparation de la future détection métier pool / pair / listing.

6.035. Version 0.7.3 — Détection des nouveaux pools et paires via logs + transaction

Réalisé :

• transformation des événements DEX décodés en objets métier pool / pair / listing,
• alimentation de kb_pools, kb_pairs, kb_pool_tokens et kb_pool_listings,
• première détection métier pour Raydium AmmV4 / initialize2,
• branchement automatique de la détection métier après résolution, projection et décodage DEX,
• émission de signaux dédiés pour new_pool, new_pair et first_listing_seen,
• garantie d’idempotence sur une même transaction déjà traitée.

6.036. Version 0.7.4 — Connecteurs DEX v1, vague 1

Réalisé :

• ajout du décodeur Pump.fun pour les créations create_v2,
• ajout du décodeur PumpSwap pour les trades buy / sell,
• intégration des nouveaux décodeurs dans le pipeline générique dex_decode,
• ajout de la détection métier Pump.fun vers token / pool / pair / listing,
• maintien de PumpSwap au niveau décodage en attendant un mapping transactionnel plus riche,
• préparation de l’extension vers Meteora, Meteora DBC et LaunchLab.

6.037. Version 0.7.5 — Connecteurs DEX v1, vague 2

Réalisé :

• enrichissement du décodeur PumpSwap avec extraction des mints et du pool_v2,
• persistance des événements PumpSwap enrichis dans kb_dex_decoded_events,
• ajout de la détection métier PumpSwap vers pool / pair / listing,
• émission des signaux dédiés new_pool, new_pair et first_listing_seen,
• garantie d’idempotence sur une même transaction déjà traitée,
• préparation du lot suivant pour Meteora, Meteora DBC et LaunchLab.

6.038. Version 0.7.6 — Connecteurs DEX v1, vague 3

Réalisé :

• ajout du premier décodeur Meteora DBC,
• prise en charge initiale des événements create_pool et swap,
• persistance des événements Meteora DBC dans kb_dex_decoded_events,
• ajout de la détection métier Meteora DBC vers pool / pair / listing,
• émission des signaux dédiés new_pool, new_pair et first_listing_seen,
• préparation du lot suivant pour Meteora DAMM v2, Meteora DAMM v1 et LaunchLab / Fun Launch.

6.039. Version 0.7.7 — Meteora DAMM v2

Réalisé :

• ajout du premier décodeur Meteora DAMM v2,
• prise en charge initiale des événements de création de pool via initialize_pool, initialize_pool_with_dynamic_config et initialize_customizable_pool,
• prise en charge initiale des swaps via swap et swap2,
• persistance des événements Meteora DAMM v2 dans kb_dex_decoded_events,
• ajout de la détection métier Meteora DAMM v2 vers pool / pair / listing,
• préparation du rattachement futur entre Meteora DBC et Meteora DAMM v2.

6.040. Version 0.7.8 — Meteora DAMM v1

Réalisé :

• ajout du premier décodeur Meteora DAMM v1,
• prise en charge initiale des événements de création de pool via initialize_pool et initialize_pool_with_config,
• prise en charge initiale des swaps via swap,
• persistance des événements Meteora DAMM v1 dans kb_dex_decoded_events,
• ajout de la détection métier Meteora DAMM v1 vers pool / pair / listing,
• préparation du rattachement futur entre Meteora DBC et Meteora DAMM v1.

6.041. Version 0.7.9 — Launch origins / Fun Launch

Réalisé :

• ajout d’un registre des surfaces de lancement,
• ajout d’un registre de clés observables par surface de lancement,
• ajout d’une attribution entre événements/pools détectés et surfaces connues,
• premier support de Meteora Fun Launch comme surface d’origine au-dessus de Meteora DBC,
• branchement automatique de l’attribution depuis le pipeline de résolution transactionnelle,
• conservation d’une séparation stricte entre protocole on-chain et origine de lancement.

6.042. Version 0.7.10 — Orca / Whirlpools

Réalisé :

• ajout du premier décodeur Orca Whirlpools,
• prise en charge initiale des événements de création de pool via initialize_pool et initialize_pool_v2,
• prise en charge initiale des swaps via swap et swap_v2,
• persistance des événements Orca Whirlpools dans kb_dex_decoded_events,
• ajout de la détection métier Orca Whirlpools vers pool / pair / listing,
• utilisation de KbPoolKind::Clmm pour refléter la nature concentrée de Whirlpools.

6.043. Version 0.7.11 — FluxBeam

Réalisé :

• ajout du premier décodeur FluxBeam,
• prise en charge initiale des événements de création de pool via un premier décodage create_pool / initialize_pool,
• prise en charge initiale des swaps via swap,
• persistance des événements FluxBeam dans kb_dex_decoded_events,
• ajout de la détection métier FluxBeam vers pool / pair / listing,
• conservation d’un premier décodage heuristique à raffiner ultérieurement avec des transactions FluxBeam réelles.

6.044. Version 0.7.12 — DexLab

Réalisé :

• ajout du premier décodeur DexLab Swap/Pool,
• prise en charge initiale des événements de création de pool via un premier décodage create_pool / initialize_pool,
• prise en charge initiale des swaps via swap,
• persistance des événements DexLab dans kb_dex_decoded_events,
• ajout de la détection métier DexLab vers pool / pair / listing,
• conservation d’une séparation entre pool DexLab natif et éventuel OpenBook Market ID créé ensuite.

6.045. Version 0.7.13 — Bags / Moonit comme origines de lancement

Réalisé :

• extension de la couche launch origins à Bags et Moonit,
• ajout d’un enregistrement programmatique des mappings Bags à partir des champs tokenMint, dbcConfigKey, dbcPoolKey et dammV2PoolKey,
• prise en charge de l’attribution Bags par matching exact sur config_account, pool_account et token_mint,
• prise en charge de l’attribution Moonit par détection automatique des token mints se terminant par moon,
• conservation d’une séparation stricte entre origine de lancement et protocole on-chain.

6.046. Version 0.7.14 — Consolidation multi-DEX

Réalisé :

• ajout d’une couche commune pool origins pour enregistrer la première signature vue par le modèle pour chaque pool détecté,
• rattachement d’un pool à son decoded_event, à son pair, à son pool_listing et à son éventuelle launch_attribution,
• amélioration de la traçabilité inter-protocoles sans modifier les connecteurs DEX déjà validés,
• conservation d’une logique idempotente avec mise à jour douce des liens pair / listing / launch attribution,
• préparation de la future couche analytique sur une base multi-DEX plus cohérente.

6.047. Version 0.7.15 — Wallets, holdings et participants observés

Réalisé :

• ajout d’une première couche wallets pour les adresses observées dans le pipeline,
• ajout d’une première couche wallet participations pour rattacher une adresse à une transaction, un decoded event, un pool et un pair,
• extraction des rôles observés depuis les payloads décodés (creator, payer, owner, user),
• branchement automatique depuis le pipeline de résolution transactionnelle,
• report des holdings à l’étape suivante afin de conserver une séparation nette entre acteurs observés et balances observées.

6.048. Version 0.7.16 — Séries de prix, volumes et agrégats DEX

Réalisé :

• ajout d’une première table trade events pour normaliser les swaps observés,
• ajout d’une première table pair metrics pour agréger les swaps par paire,
• prise en charge des compteurs trade_count, buy_count, sell_count,
• prise en charge optionnelle des volumes bruts base / quote et du dernier prix dérivé quote_per_base,
• branchement automatique dans le pipeline de résolution transactionnelle,
• conservation d’un modèle simple et idempotent en préparation de futures candles / séries temporelles.

6.049. Version 0.7.17 — Renforcement temps réel WS hybride

Réalisé :

• conservation de logsSubscribe comme source canonique de signatures candidates,
• ajout d’une collecte de cibles programSubscribe à partir des DEX actifs connus,
• ajout d’une collecte de cibles accountSubscribe à partir des pools actifs connus,
• ajout d’une couche d’observations techniques WS hybrides pour logs / program / account,
• ajout d’une première déduplication en mémoire des notifications techniques reçues en parallèle,
• ajout d’une façade runtime pour exposer ce comportement au futur branchement ws_manager.

6.050. Version 0.7.18 — Backfill historique ciblé par token

Réalisé :

• ajout d’un premier service de backfill ciblé par token_mint,
• récupération des signatures historiques via getSignaturesForAddress,
• résolution des transactions pertinentes via getTransaction,
• relecture du pipeline interne pour reconstruire transactions, décodage DEX, détection métier, origins, wallets et trade metrics,
• ajout d’une seconde passe sur les pools découverts pour le token afin de récupérer des signatures supplémentaires liées à l’activité du pool,
• conservation d’un périmètre ciblé sur des tokens encore actifs au lieu d’un scan exhaustif de la blockchain.

6.051. Version 0.7.19 — Holdings observés

Réalisé :

• ajout d’une première table wallet holdings pour agréger les couples wallet/token observés,
• rattachement des holdings observés à la dernière transaction, au dernier decoded event, au dernier pool et au dernier pair connus,
• conservation d’un champ balance_raw optionnel sans prétendre encore reconstruire un portefeuille complet,
• alimentation automatique à partir des événements DEX déjà décodés et des wallets déjà observés,
• branchement automatique dans le pipeline de résolution transactionnelle.

6.052. Version 0.7.20 — Candles / OHLCV

Réalisé :

• ajout d’une première table pair candles pour matérialiser les agrégats OHLCV par paire,
• stockage en base des timeframes usuels (1m, 5m, 15m, 1h),
• conservation de trade events comme source brute de vérité,
• ajout d’un service de régénération à la demande pour un timeframe arbitraire,
• possibilité de choisir dynamiquement le timeframe lors d’une requête analytique,
• branchement automatique dans le pipeline de résolution transactionnelle pour maintenir les candles matérialisées à jour.

6.053. Version 0.7.21 — Signaux analytiques plus riches

Réalisé :

• ajout d’une première table pair analytic signals dédiée aux signaux dérivés par paire,
• prise en charge initiale des signaux first_trade_seen, trade_burst_60s, buy_sell_imbalance_60s, price_jump_up_60s, price_jump_down_60s et volume_spike_60s,
• calcul des signaux à partir des pair metrics, pair candles et trade events,
• persistance idempotente des signaux par paire et par bucket,
• branchement automatique dans le pipeline de résolution transactionnelle.

6.054. Version 0.7.22 — kb_app : inspection et tests du pipeline 0.7.x

Objectif : permettre depuis l’application desktop de tester, inspecter et valider tout le pipeline 0.7.x sans recourir uniquement aux logs bruts ou à SQLite.

À faire :

• ajouter une ou plusieurs vues kb_app dédiées à l’inspection des transactions résolues, événements DEX décodés, pools, paires, launch origins, pool origins, wallets observés, holdings observés et trade events,
• permettre la recherche par signature, pool, paire, token mint ou wallet,
• afficher les liens entre objets techniques et objets métier,
• permettre de lancer manuellement certains backfills ou inspections ciblées,
• fournir un socle UI pour tester en pratique tout ce qui a été construit dans la série 0.7.x.

6.055. 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.

Protocoles cibles :

• Meteora DBC
• Meteora DAMM v2
• Meteora DAMM v1
• LaunchLab / Fun Launch
• Pump.fun
• PumpSwap
• Raydium
• Orca
• Bags
• FluxBeam
• DexLab
• Moonit

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,
• 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.056. 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.

6.057. Version 1.x.y — Wallets et swap préparatoire

Objectif : préparer la couche d’action.

À faire :

• gestion du répertoire wallets,
• chargement sécurisé des keypairs,
• abstraction wallet,
• préparation d’ordres et de swaps,
• simulation et garde-fous.

6.058. 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,
• journaux d’exécution.

6.059. 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,
• politique de répartition par source.

7. Organisation des modules ciblés

7.1. kb_lib

Modules cibles à court terme :

• 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

7.2. kb_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.

8. Ligne de conduite sur le WsClient

Le WsClient doit être conçu en plusieurs couches :

1. transport brut WebSocket,
2. encodage/décodage JSON texte,
3. couche JSON-RPC 2.0,
4. couche Solana subscribe/unsubscribe/notification,
5. couche métier pour la répartition des messages.

Cette séparation évite de mélanger :

• les réponses à requêtes simples,
• les réponses de subscribe,
• les réponses de unsubscribe,
• les notifications push.

9. Politique initiale de reconnexion

Au départ :

• pas de reconnexion automatique,
• pas de resubscribe automatique,
• comportement explicite contrôlé par l’appelant.

Plus tard, ce comportement pourra devenir configurable dans config.json et pilotable depuis l’application.

10. Politique initiale de fermeture

À la fermeture d’un WsClient :

1. marquer le client en arrêt,
2. tenter les unsubscribe actifs,
3. attendre les réponses dans une fenêtre bornée,
4. forcer la purge locale si nécessaire,
5. fermer proprement le flux d’écriture,
6. laisser se terminer le flux de lecture,
7. journaliser clairement les cas dégradés.

11. Documentation et livrables de référence

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 tests unitaires robustes,
• les bindings TS générés via cargo test export_bindings lorsque les types partagés évoluent.

12. Priorité immédiate

La priorité immédiate est désormais la suivante :

1. finaliser complètement la fin de série 0.7.x avant l’ouverture de 0.8.x,
2. ajouter un renforcement temps réel hybride avec logsSubscribe, programSubscribe et accountSubscribe en parallèle des sources déjà exploitées,
3. conserver la résolution transactionnelle comme source de normalisation commune,
4. ajouter ensuite un mode de backfill historique ciblé par token_mint pour des tokens encore actifs donnés explicitement,
5. compléter la couche métier avec des holdings observés,
6. ajouter des candles / OHLCV et une première couche de signaux analytiques plus riches,
7. doter kb_app d’une vraie UI d’inspection et de test pour l’ensemble du pipeline 0.7.x,
8. préparer enfin l’arrivée de Yellowstone gRPC comme extension de capacité, et non comme remplacement du socle existant.