# Khadhroony Bobot — Global TODO / Roadmap > This roadmap is a living document. > Completed versions reflect the current implemented state. > Planned versions are indicative and may evolve as architecture and product needs become clearer. --- ## Project goals The project is split into several major applications sharing `khbb_lib`: - `khbb_listener_app` - listen to Solana data sources, - detect token / mint / token-account / bootstrap / pair / pool related activity, - enrich and store observed data. - `khbb_pattern_analyser_app` - analyze recurring patterns on tokens, mints, pools, names, lifetimes, scam patterns, bootstrap flows, early activity. - `khbb_trader_app` - consume early detections and pattern outputs, - take automated trading decisions, - apply entry/exit logic based on price, duration, confidence, and risk. --- ## Current architectural direction The implementation started from an inline listener loop in order to validate, one step at a time: - Solana HTTP RPC transport, - Solana WebSocket transport, - raw data storage, - event normalization, - early domain classification, - heuristic signals, - HTTP enrichment, - candidate tracking and persistence. This bootstrap architecture has been useful for validation, but it is no longer the target shape of the project. ### Target architecture direction The target architecture should progressively move toward: - multiple concurrent data sources, - autonomous source clients, - async task-based source runtimes, - command/event channels, - source aggregation hub, - separation between: - transport, - normalization, - enrichment, - correlation, - persistence, - strategy/trading, - UI/runtime control. This especially applies to: - multiple WebSocket clients, - Yellowstone gRPC client(s), - HTTP enrichment workers, - future external data sources, - a Tauri desktop shell for `khbb_listener_app`. --- ## Completed versions ### v0.1.x - initial project skeleton - workspace setup - strict coding conventions - config loading - tracing bootstrap - SQLite bootstrap ### v0.2.x - basic listener runtime - listener session creation - SQLite connectivity validation - initial runtime loop - first persistence primitives ### v0.3.0 - HTTP JSON-RPC client foundation - manual request ids - use of official Solana RPC request/response types where applicable - basic `getSlot` support - raw HTTP RPC storage ### v0.3.1 - tests added around config and storage - tests added around HTTP RPC request/response parsing - stronger validation of config and SQLite helpers ### v0.3.2 - HTTP polling integrated into listener runtime - `getSlot` polling stored as raw RPC traffic ### v0.4.1 - initial Solana WebSocket RPC support - subscription primitives - support for: - `slotSubscribe` - `logsSubscribe` - `programSubscribe` - raw WS message storage ### v0.4.3 - centralized WebSocket read loop improvements - safe unsubscribe handling - shutdown flow improvements - Rustls provider initialization fixes ### v0.4.4 - centralized WS dispatch between: - JSON-RPC responses - notifications - better separation of response wait logic and notification flow ### v0.4.5 - active WS subscription registry - source metadata attached to subscriptions - cleaner handling of multiple subscription kinds ### v0.4.6 - WS notification normalization layer - normalized events introduced for: - slot - logs - program notifications ### v0.5.0 - first domain event layer - normalized WS events converted into domain events ### v0.5.1 - known program registry - first known-program classification layer - SPL Token / Token-2022 / System / ComputeBudget / ATA recognition ### v0.5.2 - official `ids.rs` module added - heuristic signal layer introduced - first weak signals around: - token account activity - mint activity - initial token activity - bootstrap-style activity ### v0.5.3 - heuristic refinement - associated token account style signals - stronger bootstrap-oriented heuristics from known logs ### v0.5.4 - targeted HTTP enrichment via `getAccountInfo` - enriched account snapshot - first distinction between: - potential token account - potential mint account - unknown account ### v0.5.5 - enriched classification layer - confirmed enriched events introduced: - confirmed token account activity - confirmed mint account activity - unknown token-program-owned account activity ### v0.5.6 - local correlation layer between: - enriched events - heuristics - correlated signals introduced: - confirmed token account update - potential new token mint - potential token bootstrap flow ### v0.5.7 - candidate layer introduced - first domain candidates: - token account candidate - mint candidate - bootstrap flow candidate - listener maximum tick count made configurable ### v0.5.8 - in-memory session candidate tracker - session-local deduplication - lightweight score and confidence - per-session candidate upsert flow ### v0.5.9 - session candidate snapshots - sorted candidate summaries - confidence-based filtering - end-of-session summary logs ### v0.6.0 - dedicated session candidate persistence in SQLite - reusable candidate persistence base for later analyser/trader reuse - listener end-of-session candidate persistence flow ### v0.6.1 (in progress / bootstrap-valid) - first refactor toward an autonomous WebSocket source client - `listener.rs` no longer owns the low-level WebSocket transport directly - `ws_source.rs` now encapsulates: - connection lifecycle, - subscribe operations, - event reception, - close/shutdown behavior - listener runtime can now complete without hanging during WS shutdown - current state is considered a **valid bootstrap of the autonomous WS client**, but not yet the final multi-instance source runtime --- ## Current status summary At the current stage, the project can already: - connect to Solana HTTP RPC, - connect to Solana WebSocket RPC, - subscribe to slot/logs/program streams, - store raw HTTP and WS payloads, - normalize notifications, - derive domain events, - classify known programs, - emit heuristic signals, - enrich accounts with `getAccountInfo`, - confirm token-account-like activity, - correlate signals, - track session candidates in memory, - persist session candidates, - summarize candidates at the end of a run. What is still missing is the transition from generic token activity detection to true: - mint detection, - token bootstrap detection, - pool/pair detection, - DEX-aware activity detection, - robust multi-source runtime orchestration, - Tauri runtime/UI control, - pattern analysis, - trading integration. --- ## Planned versions > Planned versions are provisional and may change. ### v0.6.x — autonomous multi-instance WS client branch This branch is now reserved for stabilizing the WebSocket source runtime as an autonomous reusable component. ### v0.6.2 - stabilize `ws_source` contract and lifecycle - improve unit/integration coverage around: - spawn, - connect, - subscriptions, - event reception, - shutdown, - close - document the exact shutdown semantics - reduce coupling between listener business logic and WS source internals ### v0.6.3 - support multiple concurrent WS source clients - allow different endpoints/providers simultaneously - introduce source identity and source metadata - prepare failover / redundancy / specialization by source ### v0.6.4 - introduce source aggregation hub for multiple WS clients - merge multi-source WS events into a unified ingestion pipeline - prepare prioritization and deduplication across sources ### v0.6.5 - prepare transport-level abstraction so that WS sources and future gRPC sources can share a common high-level source contract - identify what must remain WS-specific vs source-generic ### v0.6.6 - begin Yellowstone gRPC source runtime design and first bootstrap implementation - align WS and gRPC runtime expectations before moving to a broader source orchestration branch ### v0.7.x — `khbb_listener_app` migration to Tauri v2 This branch is now reserved for transforming `khbb_listener_app` into a Tauri v2 desktop application. ### v0.7.0 - introduce Tauri v2 shell for `khbb_listener_app` - add desktop window with: - start button, - stop button, - readonly scrollable log area - keep current listener runtime available through Tauri commands ### v0.7.1 - load `config.json` through the desktop app flow - adapt tracing so logs can be surfaced both to file/stdout and to Tauri events - define first Tauri runtime commands/events contract ### v0.7.2 - support start/stop lifecycle entirely through Tauri runtime control - add runtime state reporting to UI - prevent double-start / invalid stop / inconsistent state transitions ### v0.7.3 - improve desktop log streaming and session summaries - expose listener candidate summaries in UI - prepare future status panels beyond the initial log textarea ### v0.8.0 - improve token-account vs mint distinction - decode more token-specific account information - improve quality of confirmed mint detection - reduce weak false candidate generation ### v0.8.1 - introduce first persistent mint candidates - introduce first persistent token-account candidates - session-to-database promotion logic refinement ### v0.8.2 - begin real bootstrap flow persistence and tracking - correlate: - token accounts - mint accounts - bootstrap-like logs - source timing ### v0.9.0 - begin DEX-aware detection layer - identify relevant program ids for first supported DEXes - start with a small prioritized list, likely including: - Raydium - Meteora - Pump-like ecosystems - detect pool/pair creation-related activity ### v0.9.1 - add first pair / pool candidate models - begin liquidity/bootstrap/pair-side inference - distinguish token-only activity from pair/pool activity ### v0.9.2 - add market-related enrichment: - liquidity hints - price hints - pool metadata - start preparing listener outputs for trading eligibility ### v0.10.0 - begin `khbb_pattern_analyser_app` - consume persisted candidates/signals from listener - define first recurring pattern models: - mint lifetime - suspicious bootstrap - likely scam patterns - repeated naming patterns - repeated creator behavior ### v0.10.1 - pattern scoring - candidate clustering - repeated-behavior analysis across sessions ### v1.0.0 - first end-to-end listener milestone - persistent candidate ingestion - autonomous source-client foundations - Tauri listener control foundations - DEX-aware first detection - pattern analyser initial interoperability --- ## Future trader-oriented roadmap ### Trader preparation - define normalized outputs consumable by `khbb_trader_app` - define candidate confidence / risk / eligibility model - define basic token entry exclusion filters - define liquidity / market-cap / bootstrap safety gates ### Early trading versions - paper-trading mode first - wallet integration - transaction builder integration - buy/sell strategy primitives - time-based and price-based exits - risk caps and kill switches --- ## Cross-cutting technical TODO ### Transport / source runtime - [x] move away from single inline WS runtime model - [x] introduce first autonomous async WS source task - [ ] stabilize the autonomous WS source API and lifecycle contract - [ ] add multi-WS support - [ ] add gRPC source runtime - [ ] unify source event interface - [ ] add source aggregation hub ### Desktop / runtime control - [ ] introduce Tauri v2 shell for `khbb_listener_app` - [ ] add start/stop commands - [ ] stream tracing logs to UI - [ ] load runtime config via desktop flow - [ ] expose runtime state to UI ### Storage - [x] persist session candidates - [ ] define candidate history tables - [ ] define mint/pool/pair tables - [ ] define source tables / provider metadata tables ### Classification / heuristics - [ ] reduce weak token-account/mint ambiguity - [ ] improve ATA detection - [ ] refine bootstrap-flow detection - [ ] correlate logs with program/account enrichment more strongly ### DEX support - [ ] define first supported DEX list - [ ] list official program ids and account models - [ ] detect pair creation events - [ ] detect liquidity initialization - [ ] enrich pool metadata ### Pattern analysis - [ ] define persistent pattern schema - [ ] score repeated token behaviors - [ ] score suspicious creators / repeated rugs / short lifetimes ### Trading - [ ] define trader input schema - [ ] define safe simulation mode - [ ] define buy filters - [ ] define sell rules - [ ] define risk management rules --- ## Notes - Current versions intentionally favored iterative validation over final architecture purity. - The autonomous WS source refactor is now started and validated enough to continue as the main direction for `0.6.x`. - The Tauri migration is intentionally separated into `0.7.x` so transport/runtime stabilization can happen first. - Candidate/correlation layers may continue to evolve before stabilizing. - Future versions may be renumbered, merged, split, or reprioritized depending on what real Solana traffic reveals.