diff --git a/CHANGELOG.md b/CHANGELOG.md index e19d4b5..2f8dc22 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -73,3 +73,4 @@ 0.7.40 - Ajout de Demo3 pour la constitution de corpus on-chain par `dex_code` / `program_id` via `getSignaturesForAddress` + `getTransaction`, extraction des mints, deltas SPL Token, comptes pool/state/vault/program candidats, ajout du backfill par signature dans Demo Pipeline 2, et validation pratique sur Raydium AMM v4 sans promotion automatique des comptes candidats. 0.7.41 - Raydium AMM v4 swap decoder v1 : décodage des inner instructions `675kPX...`, extraction pool/state, authority, vaults, mints, routeSource et montants exploitables, matérialisation trades/candles sur transactions OK, matrice AMM v4 passée en `supported`, et validation locale avec invariants trade/candle propres. 0.7.42 - Consolidation famille Raydium : audit conservatoire des instructions Raydium non décodées, décodage CLMM legacy `swap`, cleanup des audits remplacés, classification HTTP `getTransaction` comme requête lourde avec retry/backoff de backfill, mapping des événements non-swap prouvés `raydium_clmm` (`increase_liquidity_v2`, `decrease_liquidity_v2`, `open_position_with_token22_nft`, `close_position`) et `raydium_cpmm` (`initialize`, `withdraw`, `collect_creator_fee`), matérialisation de 25 liquidity events, 1 lifecycle event et 2 fee events sur corpus élargi, conservation des non-swaps AMM v4 legacy en audit. +0.7.43-E5C - Reprise documentaire et normalisation DEX-first : `0.7.43` est conservé comme point de reprise non clos pour le lot Meteora, la suite est redécoupée par DEX/version séparés, le besoin d’un ledger de décodage/replay est acté, les statuts `known` / `observed` / `decoded` / `materialized` / `verified_by_corpus` deviennent obligatoires, et aucun `program_id` ne doit être marqué vérifié sans preuve/corpus reproductible. diff --git a/Cargo.toml b/Cargo.toml index 406befb..63dd31d 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -8,7 +8,7 @@ members = [ ] [workspace.package] -version = "0.7.42" +version = "0.7.43" edition = "2024" license = "MIT" repository = "https://git.sasedev.com/Sasedev/khadhroony-bobobot" @@ -88,3 +88,4 @@ match_like_matches_macro = "allow" single_match = "allow" manual_unwrap_or_default = "allow" manual_find = "allow" +explicit_counter_loop = "allow" diff --git a/README.md b/README.md index 5936b07..7cd0ce3 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 clôture documentaire `0.7.42` : le socle transport HTTP/WS, la résolution transactionnelle, le modèle SQLite, plusieurs connecteurs DEX, les candles, les signaux analytiques, la validation locale, la matrice DEX commune, Demo3, le backfill par signature et la consolidation Raydium DEX-first existent déjà. La famille Raydium est maintenant couverte sur swaps effectifs et premiers événements non-trade prouvés ; les non-swaps AMM v4 legacy restent conservés en audit, et le cas Orca Whirlpools est reporté à `0.7.44`. +Ce document reflète le point de reprise `0.7.43-E5C`. La version Cargo reste `0.7.43`, mais le lot Meteora ouvert en `0.7.43` n’est pas considéré comme terminé. La priorité immédiate est maintenant de normaliser la roadmap DEX-first, d’ajouter un ledger de décodage/replay pour éviter les rescans inutiles, puis de reprendre les DEX un par un, variante par variante. ## 1. Objectif @@ -13,12 +13,12 @@ L’objectif opérationnel est de construire progressivement une application cap - détecter l’apparition de nouveaux tokens, pools, paires et listings sur Solana ; - identifier en priorité les DEX effectifs sur lesquels les swaps, liquidités et événements de marché sont réellement exécutés ; - décoder les transactions pertinentes des DEX ciblés, puis seulement ensuite les launch surfaces et origines de mint/lancement ; -- séparer les swaps/candles des événements utiles seulement à l’analyse : liquidité, cycle de vie de pool, fees, rewards, administration, wallets observés ; +- séparer strictement les swaps/candles des événements utiles seulement à l’analyse : liquidité, cycle de vie de pool, fees, rewards, administration, wallet activity, mint/burn, migration ; - produire des métriques exploitables : prix, volume, candles/OHLCV, activité, bursts, déséquilibres buy/sell, signaux analytiques ; - préparer ensuite des règles déterministes de filtrage, d’achat, de vente, de stop-loss et de trailing stop ; -- conserver une traçabilité locale suffisante pour rejouer, diagnostiquer et améliorer les décodeurs. +- conserver une traçabilité locale suffisante pour rejouer, diagnostiquer et améliorer les décodeurs sans retraiter inutilement toute la base. -Le but court terme n’est pas encore le live trading. Le but court terme est de fiabiliser le décodage multi-DEX et la matérialisation des objets métier nécessaires au trading. +Le but court terme n’est pas encore le live trading. Le but court terme est de fiabiliser le décodage multi-DEX, la matérialisation des objets métier nécessaires au trading et le mécanisme de replay incrémental. ## 2. Workspace @@ -26,12 +26,12 @@ Le workspace contient deux crates principales. | Crate | Rôle | |---|---| -| `kb_lib` | Bibliothèque métier : configuration, tracing, clients réseau, pool HTTP, manager WS, résolution transactionnelle, décodage DEX, détection métier, persistance SQLite, backfill, metadata, candles, signaux analytiques. | -| `kb_demo_app` | Application Tauri V2 de démonstration et d’inspection : fenêtres `Demo Ws`, `Demo Ws Manager`, `Demo Http`, `Demo Pipeline`, `Demo Pipeline 2`, graphiques candles et commandes de backfill/replay. | +| `kb_lib` | Bibliothèque métier : configuration, tracing, clients réseau, pool HTTP, manager WS, résolution transactionnelle, décodage DEX, détection métier, persistance SQLite, backfill, metadata, candles, signaux analytiques, validation et diagnostics. | +| `kb_demo_app` | Application Tauri V2 de démonstration et d’inspection : fenêtres `Demo Ws`, `Demo Ws Manager`, `Demo Http`, `Demo Pipeline`, `Demo Pipeline 2`, `Demo3`, graphiques candles et commandes de backfill/replay. | -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. +La logique métier doit rester dans `kb_lib`. `kb_demo_app` doit rester une façade UI/Tauri utilisée pour inspecter, backfiller et constituer du corpus on-chain ; elle ne doit pas récupérer de logique DEX profonde. -## 3. État actuel après `0.7.42` +## 3. État actuel au point de reprise `0.7.43-E5C` ### 3.1. Socle stabilisé à ne pas refactorer maintenant @@ -44,7 +44,7 @@ Ces éléments fonctionnent et ne sont pas bloquants pour les DEX. Ils ne doiven - couches JSON-RPC WS/HTTP déjà stabilisées ; - orchestration réseau utilisée par les fenêtres de démonstration. -Ils pourront être améliorés plus tard, mais la priorité actuelle est le décodage DEX, les événements métier et les tables d’analyse. +Ils pourront être améliorés plus tard, mais la priorité actuelle est le décodage DEX, les événements métier, les tables d’analyse et le replay incrémental. ### 3.2. Pipeline métier existant @@ -56,95 +56,118 @@ Le pipeline `0.7.x` couvre déjà les étapes suivantes : 4. décodage DEX dans `k_sol_dex_decoded_events` ; 5. détection métier vers tokens, pools, paires, listings, origins et wallets observés ; 6. matérialisation des trades exploitables ; -7. agrégation pair metrics ; -8. génération candles/OHLCV ; -9. signaux analytiques simples ; -10. inspection via l’application de démonstration. +7. matérialisation partielle des événements non-trade prouvés ; +8. agrégation pair metrics ; +9. génération candles/OHLCV ; +10. signaux analytiques simples ; +11. inspection via l’application de démonstration. -### 3.3. Connecteurs validés ou observés via l’application de démo +### 3.3. Résultat local observé avant normalisation -Les connecteurs suivants sont les surfaces actuellement les plus importantes pour la validation locale : +Un corpus local de reprise contient notamment : -- `pump_fun` comme surface de launch / mint initial ; -- `pump_swap` pour les swaps post-migration Pump ; -- `raydium_cpmm` : swaps `swap_base_input` / `swap_base_output`, lifecycle `initialize`, liquidity `withdraw` et `collect_creator_fee` sur corpus prouvé ; -- `raydium_clmm` : swaps `swap_v2` et legacy `swap`, liquidité/positions `increase_liquidity_v2`, `decrease_liquidity_v2`, `open_position_with_token22_nft`, `close_position` sur corpus prouvé ; -- `raydium_amm_v4` : swaps AMM v4 legacy `675kPX...` matérialisés ; non-swaps legacy conservés en audit tant que le corpus ne permet pas une promotion fiable ; -- `meteora_dlmm` ; -- `meteora_damm_v1`, partiel : les swaps sans payload montant/prix exploitable restent conservés mais non actionnables ; -- `meteora_damm_v2`, observé dans le corpus `0.7.36`, mais les swaps sans payload montant/prix exploitable sont maintenant `non_actionable_trade` ; -- `meteora_dbc`, observé dans le corpus `0.7.36`, mais les swaps sans payload montant/prix exploitable sont maintenant `non_actionable_trade`. +| Indicateur | Valeur observée | +|---|---:| +| transactions chain | `2956` | +| decoded events | `7159` | +| trade events | `2738` | +| liquidity events | `0` | +| pool lifecycle events | `1` | +| fee events | `0` | +| reward events | `0` | +| admin events | `0` | -### 3.4. Connecteurs à consolider par corpus en priorité DEX-first +Cette distribution montre que les swaps sont déjà fortement présents, mais que la matérialisation non-trade n’est pas encore homogène sur le corpus courant. Les nombreux `instruction_audit`, surtout côté Meteora, doivent devenir un axe de travail DEX par DEX. -Les modules ou surfaces suivantes existent, sont partiellement représentés dans le code ou doivent être recherchés, mais doivent être consolidés par corpus local, invariants et documentation avant de reprendre les launch surfaces : +### 3.4. Connecteurs validés ou observés via l’application de démo -- `raydium_stable_swap` ; -- `orca_whirlpools` ; -- `fluxbeam` ; -- `dexlab` ; -- `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc` et `meteora_dlmm` pour la couverture non-trade complète ; -- `metaDAO` et `printr`, apparus comme DEX à vérifier côté sources externes de découverte ; -- tout DEX ou programme récurrent détecté dans `k_sol_protocol_candidates`, DEX Screener ou les transactions locales. +Les surfaces suivantes existent dans le code, dans la matrice ou dans le corpus local. Leur niveau de preuve doit rester explicite. -Les launch origins déjà amorcées (`meteora_fun_launch`, `bags`, `moonit`) et les launch surfaces enregistrables (`raydium_launchlab`, `raydium_launchpad`, `letsbonk`, `bonk_fun`, `bags`, `moonshot`, `moonit`, `boop_fun`, `believe`, `heaven`) sont conservées dans la documentation, mais elles ne sont plus prioritaires tant que les DEX effectifs ne sont pas suffisamment couverts. +| Code | Statut de travail | Commentaire | +|---|---|---| +| `pump_fun` | launch surface | Surface de launch / mint initial. À traiter après les DEX effectifs sauf besoin de migration. | +| `pump_swap` | DEX effectif | Swaps `buy` / `sell` observés. Non-trade à étendre plus tard. | +| `raydium_cpmm` | DEX effectif consolidé partiellement | Swaps et premiers events non-trade prouvés sur corpus antérieur. | +| `raydium_clmm` | DEX effectif consolidé partiellement | Swaps v2/legacy, positions et liquidity events prouvés sur corpus antérieur. | +| `raydium_amm_v4` | DEX effectif legacy | Swaps AMM v4 legacy matérialisés ; non-swaps legacy conservés en audit tant que le corpus ne permet pas une promotion fiable. | +| `meteora_dlmm` | DEX effectif à reprendre séparément | Présent et observé ; events non-trade à normaliser. | +| `meteora_damm_v1` | DEX effectif à reprendre séparément | Swaps présents ; plusieurs events restent en audit ou non actionnables. | +| `meteora_damm_v2` | DEX effectif à reprendre séparément | Swaps et create_pool observés ; nombreux audits à traiter. | +| `meteora_dbc` | launch/bonding + DEX effectif partiel à reprendre séparément | Gros volume d’audits ; séparer bonding/launch, swap effectif et migration. | +| `orca_whirlpools` | DEX effectif à vérifier | À revalider par corpus dédié avant promotion. | +| `fluxbeam` | DEX effectif à vérifier | Program id, corpus et events à vérifier. | +| `dexlab` | DEX effectif à vérifier | Program id, corpus et events à vérifier. | +| `metaDAO` | candidat à vérifier | Aucun `program_id` ne doit être déclaré vérifié sans preuve/corpus. | +| `printr` | candidat à vérifier | Aucun `program_id` ne doit être déclaré vérifié sans preuve/corpus. | -### 3.5. Validation acquise en `0.7.36` +### 3.5. Statuts de preuve obligatoires -La validation `0.7.36_meteora_family_consolidation` est considérée comme réalisée lorsque les invariants suivants restent vrais après replay local : +Aucun `program_id`, DEX ou event ne doit être documenté comme vérifié sans preuve reproductible. -- `validationPassed = true` ; -- `diagnosticsClean = true` ; -- `blockingIssueCount = 0` ; -- `decodedTradeCandidateWithoutTradeEventCount = 0` ; -- `decodedTradeCandidateWithoutAmountPayloadCount = 0` ; -- `missingTradeEventCount = 0` ; -- `pairWithoutTradeCount = 0` pour les paires actionnables ; -- `pairWithoutCandleCount = 0` pour les paires actionnables. +| Statut | Sens | +|---|---| +| `known` | Connu/listé dans le code, une doc, une source externe ou la matrice. | +| `observed` | Vu dans une transaction, une instruction, une base locale ou un corpus on-chain. | +| `decoded` | Un decoder produit un event structuré ou un `instruction_audit` classé. | +| `materialized` | L’event alimente une table métier dédiée : trade, liquidity, lifecycle, fee, reward, admin, mint/burn, etc. | +| `verified_by_corpus` | Validé par requêtes SQL, signatures/corpus reproductibles et invariants de validation. | -Point important : `meteora_damm_v2` et `meteora_dbc` peuvent produire beaucoup d’événements `swap` décodés sans produire de `trade_events` lorsque les montants ou prix ne sont pas fiables. Ces événements doivent rester `non_actionable_trade` et ne doivent pas être comptés comme `tradeCandidate` ou `candleCandidate`. +## 4. Matrice DEX : priorité révisée -## 4. Matrice DEX : DEX effectifs d’abord, launch surfaces ensuite +À partir du point de reprise `0.7.43-E5C`, la priorité est : -La distinction de travail à partir de `0.7.39` est la suivante : +1. **DEX effectifs actuels** : programmes où les swaps, pools, liquidités, positions, fees, rewards, admin/config, burns/mints ou migrations sont réellement exécutés ; +2. **launch surfaces** : surfaces de mint, bonding, launchpad, migration ou origine ; +3. **DEX historiques / legacy / faibles priorités** : programmes anciens, peu observés, ou uniquement utiles à la compatibilité/replay historique. -- un **DEX effectif** est un programme ou une famille de programmes sur lesquels des swaps, pools, liquidités, fees, rewards, admin/config, burns ou mints utiles sont réellement observables ; -- une **launch surface** peut être la première source de mint ou de lancement, mais elle ne doit pas masquer la priorité donnée aux programmes où le swap final est exécuté ; -- pour le trading, le DEX effectif, la qualité de décodage du swap et les événements de pool sont prioritaires ; la launch origin reste une information de filtrage à réintroduire après stabilisation des DEX. +Chaque DEX ou variante de DEX doit avoir sa propre étape de validation. Les familles larges restent utiles pour la navigation, mais le travail de décodage doit être fait par version/protocole : `raydium_cpmm`, `raydium_clmm`, `raydium_amm_v4`, `meteora_dlmm`, `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc`, etc. -### 4.1. Matrice de travail +### 4.1. Ordre de travail DEX effectifs -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. +| Priorité | Code cible | Rôle | Action prochaine | +|---:|---|---|---| +| 1 | `pump_swap` | AMM / swap | Maintenir les invariants swaps et chercher les non-trade prouvés. | +| 2 | `raydium_cpmm` | AMM | Garder consolidé ; ne rouvrir que sur nouveaux discriminators/corpus. | +| 3 | `raydium_clmm` | CLMM | Garder consolidé ; ne rouvrir que sur nouveaux discriminators/corpus. | +| 4 | `raydium_amm_v4` | AMM legacy actif | Garder swaps ; ne promouvoir les non-swaps qu’avec corpus. | +| 5 | `meteora_dlmm` | DLMM | Reprendre séparément : swaps, liquidity, positions, lifecycle, fees/rewards/admin. | +| 6 | `meteora_damm_v1` | AMM | Reprendre séparément : swaps exploitables, pools, liquidity, fees/admin. | +| 7 | `meteora_damm_v2` | AMM | Reprendre séparément : create_pool, swaps exploitables, configs dynamiques, non-trade. | +| 8 | `meteora_dbc` | bonding / DEX effectif partiel | Reprendre séparément : swap effectif, bonding curve, migration, launch attribution. | +| 9 | `orca_whirlpools` | CLMM | Revalider par corpus dédié. | +| 10 | `fluxbeam` | AMM | Vérifier program id, events et corpus. | +| 11 | `dexlab` | AMM | Vérifier program id, events et corpus. | +| 12 | `metaDAO` | candidat DEX | Vérifier par corpus avant toute promotion. | +| 13 | `printr` | candidat DEX | Vérifier par corpus avant toute promotion. | -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. +### 4.2. Launch surfaces reportées -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. +À reprendre après les DEX effectifs, sauf si une surface est indispensable pour comprendre une migration vers un pool tradable : -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. +- `pump_fun` ; +- `raydium_launchlab` ; +- `raydium_launchpad` ; +- `letsbonk` / `bonk_fun` ; +- `bags` ; +- `moonshot` ; +- `moonit` ; +- `boop_fun` ; +- `believe` ; +- `heaven` ; +- autres launch origins découvertes par corpus. -| Code cible | Type | Priorité `0.7.39+` | Prochaine action | -|---|---:|---|---| -| `pump_swap` | AMM / swap | haute | conserver les invariants trade/candle et étendre les événements non-trade prouvés. | -| `raydium_cpmm` | AMM | haute | couvert pour swaps input/output, `initialize`, `withdraw` et `collect_creator_fee` prouvés ; poursuivre seulement sur nouveaux discriminators. | -| `raydium_clmm` | CLMM | haute | couvert pour swaps v2/legacy, increase/decrease liquidity et open/close position prouvés ; poursuivre seulement sur nouveaux discriminators. | -| `raydium_amm_v4` | AMM legacy | haute | swaps legacy couverts et matérialisés ; non-swaps AMM v4 conservés en audit, à compléter plus tard si corpus suffisant. | -| `raydium_stable_swap` | AMM legacy | moyenne | vérifier l’usage réel de `5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h` et ne l’activer qu’avec corpus. | -| `meteora_dlmm` | DLMM | haute | verrouiller swaps, positions, liquidité et lifecycle. | -| `meteora_damm_v1` | AMM legacy | haute | conserver le skip sans amounts exploitables et rechercher un corpus swap/liquidité exploitable. | -| `meteora_damm_v2` | AMM | haute | vérifier `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG`, les swaps, les configs dynamiques et les événements non-trade. | -| `meteora_dbc` | bonding curve / DEX effectif partiel | haute | séparer ce qui relève du swap, du bonding curve et de la migration sans faux trade/candle. | -| `orca_whirlpools` | CLMM | haute | consolider par corpus fiable : create_pool, swap, liquidité/positions. | -| `fluxbeam` | AMM | moyenne | vérifier program id, corpus réel et instructions utiles. | -| `dexlab` | AMM | moyenne | vérifier program id, corpus réel, swaps et liens OpenBook éventuels. | -| `metaDAO` | DEX à vérifier | haute | rechercher le ou les program ids, corpus, comptes et types d’événements avant toute promotion. | -| `printr` | DEX à vérifier | haute | rechercher le ou les program ids, corpus, comptes et types d’événements avant toute promotion. | -| `okx_dex` | Aggregator/router | basse DEX direct | classifier sans matérialiser en trade direct avant preuve. | -| Launch surfaces (`pump_fun`, `raydium_launchlab`, `raydium_launchpad`, `bags`, `letsbonk`, `bonk_fun`, `boop_fun`, `moonshot`, `moonit`, `believe`, `heaven`) | Launch / origine | reportée | reprendre après consolidation des DEX effectifs ; aucun `program_id` fictif. | -| `zora` | À vérifier | hors priorité | ne pas intégrer avant preuve de programme Solana pertinent. | +### 4.3. DEX historiques ou faibles priorités -## 5. Base de données +À garder dans la matrice mais sans bloquer les versions immédiates : -SQLite reste le stockage local initial. +- `raydium_stable_swap` tant que son usage réel n’est pas démontré par corpus local ; +- vieux programmes legacy uniquement utiles pour compatibilité ou replay historique ; +- agrégateurs/routeurs comme `okx_dex` tant qu’ils ne correspondent pas à un DEX direct matérialisable ; +- entrées ambiguës comme `zora` tant qu’aucun programme Solana pertinent n’est prouvé. + +## 5. Base de données et replay incrémental + +SQLite reste le stockage local initial. Le fichier `config.json` peut pointer vers une base différente pour travailler par corpus, par DEX ou sur base vierge. Le schéma est créé au lancement via les `CREATE TABLE IF NOT EXISTS` existants. Organisation actuelle à conserver : @@ -154,60 +177,76 @@ Organisation actuelle à conserver : - les entités persistées sont sous `kb_lib/src/db/entities/` ; - les DTO applicatifs sont sous `kb_lib/src/db/dtos/`. -`schema.rs` n’est donc pas un fichier métier à splitter immédiatement. Il reste acceptable tant qu’il garde uniquement la responsabilité de création de schéma. - ### 5.1. Tables existantes importantes Le modèle actuel contient déjà notamment : -- transactions et instructions Solana normalisées ; -- DEX connus ; -- événements DEX décodés ; -- tokens, pools, pool tokens, paires, listings ; -- launch surfaces et attributions ; -- pool origins ; -- swaps et trade events ; -- liquidity events ; -- wallets, participations, holdings ; -- candles ; -- metrics et analytic signals ; -- diagnostics locaux. +- `k_sol_chain_transactions` ; +- `k_sol_chain_instructions` ; +- `k_sol_dexes` ; +- `k_sol_dex_decoded_events` ; +- `k_sol_tokens` ; +- `k_sol_pools` ; +- `k_sol_pairs` ; +- `k_sol_pool_tokens` ; +- `k_sol_trade_events` ; +- `k_sol_liquidity_events` ; +- `k_sol_pool_lifecycle_events` ; +- `k_sol_fee_events` ; +- `k_sol_reward_events` ; +- `k_sol_pool_admin_events` ; +- `k_sol_token_mint_events` ; +- `k_sol_token_burn_events` ; +- `k_sol_transaction_classifications` ; +- `k_sol_protocol_candidates`. -### 5.2. Tables existantes à stabiliser pour les cas non-trade et inconnus +### 5.2. Prochaine évolution DB : ledger de décodage/replay -Avant d’étendre trop agressivement les DEX, ces tables doivent être stabilisées et raccordées progressivement aux diagnostics et matérialisations : +Le replay actuel peut retraiter trop largement les transactions déjà connues. La prochaine tranche DB doit ajouter une structure de suivi permettant de ne pas rescanner les events certains, sauf option explicite. -| Table cible | Rôle | +Objectifs : + +- mémoriser qu’une transaction/instruction a déjà été traitée par un decoder donné ; +- stocker le statut de décodage : certain, partiel, inconnu, erreur, non-actionnable, multi-token ambigu ; +- associer le résultat au `decoder_code` et à une version logique de decoder ; +- permettre un mode `force` qui ignore le ledger ; +- permettre un mode de reprise ciblé lorsque le decoder change ; +- ne pas skipper automatiquement les transactions multi-token, multi-pool ou multi-event ambiguës ; +- conserver les failed transactions comme traçables mais non actionnables. + +Nom de table à décider dans la tranche DB, par exemple : + +- `k_sol_decode_attempts` ; ou +- `k_sol_replay_decode_ledger`. + +Champs conceptuels attendus : + +| Champ conceptuel | Rôle | |---|---| -| `k_sol_transaction_classifications` | classifier les transactions connues, inconnues, partielles, échouées, non-DEX, DEX-candidates, launch-candidates. | -| `k_sol_protocol_candidates` | conserver les programmes ou patterns suspects/récurrents qui ne correspondent pas encore à un DEX connu. | -| `k_sol_pool_lifecycle_events` | matérialiser initialize/create/migrate/open/close/status events. | -| `k_sol_fee_events` | conserver fees, creator fees, protocol fees, fund fees. | -| `k_sol_reward_events` | conserver reward params, init rewards, collect rewards. | -| `k_sol_pool_admin_events` | conserver changements de config, authority, pause/resume, paramètres de pool. | +| `transaction_id` / `signature` | rattachement transactionnel stable | +| `instruction_id` / `instruction_index` | granularité instruction si possible | +| `program_id` | programme effectivement traité | +| `protocol_name` | protocole/DEx résolu | +| `decoder_code` | decoder logique utilisé | +| `decoder_version` | version logique du decoder | +| `decode_status` | certain, partial, unknown, failed, skipped, ambiguous | +| `certainty` | niveau de confiance machine | +| `event_count` | nombre d’events produits | +| `payload_hash` / `instruction_hash` | détection de changement d’entrée | +| `reason_code` / `error_json` | diagnostic sans panic | +| `created_at` / `updated_at` | audit local | -`k_sol_liquidity_events` existe déjà et doit être stabilisée/étendue plutôt que recréée sans nécessité. +## 6. Politique de replay -## 6. Politique de refactor actuelle +Règles cibles : -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 : - -- ne pas casser les fonctionnalités déjà validées ; -- ne pas toucher pour le moment aux clients et managers réseau stabilisés ; -- faire des étapes courtes, testables et rejouables ; -- conserver les invariants de replay local ; -- ne pas transformer un événement non price-action en trade/candle ; -- documenter les nouveaux types publics avec une rustdoc utile mais pas surchargée ; -- laisser `local_pipeline_diagnostics` servir d’outil temporaire de validation tant que les DEX ne sont pas stabilisés. - -Les fichiers à surveiller en priorité sont : - -| Fichier | Action recommandée | -|---|---| -| `kb_lib/src/dex_decode.rs` | extraire classification, catégories d’événements et enrichissement commun. | -| `kb_lib/src/dex_detect.rs` | extraire helpers communs pool/pair/listing/origin/wallets et isoler les handlers par famille. | -| `kb_lib/src/trade_aggregation.rs` | isoler extraction de montants, normalisation trade et pricing. | -| `kb_lib/src/dex/*.rs` | homogénéiser les contrats de décodeurs sans forcer un gros trait prématuré. | +- par défaut, ne pas retraiter une instruction dont le ledger indique un décodage certain avec le même decoder/version et la même entrée ; +- retraiter si `force = true` ; +- retraiter si le decoder concerné change de version logique ; +- retraiter si la transaction contient plusieurs tokens/pools/events et que le ledger la classe comme ambiguë ou partielle ; +- retraiter si un event précédemment `instruction_audit` devient décodable par un nouveau decoder ; +- ne jamais créer de faux trade/candle pour un event dont les montants ne sont pas fiables ; +- conserver les audits utiles pour améliorer les decoders. ## 7. Contraintes de code @@ -221,36 +260,36 @@ Contraintes maintenues : - `#![deny(unreachable_pub)]` et `#![warn(missing_docs)]` dans les racines concernées ; - pas de `anyhow` ; - pas de `thiserror` ; -- pas de `?`, `unwrap`, `expect` dans le code applicatif ; -- usage privilégié de `match`, `if let Err`, `let Err = ... else` ; +- pas de `?`, `unwrap`, `expect` dans le code applicatif de `kb_lib` ; +- `kb_demo_app` peut rester plus souple tant qu’elle reste une application de démonstration ; +- usage privilégié de `match`, `if let Err`, `let Err = ... else` dans `kb_lib` ; - imports externes limités, sauf traits lorsque nécessaire ; - tests unitaires et tests de replay maintenus. -Les tests peuvent rester plus souples lorsque cela clarifie le test. +Si une requête DB est ajoutée ou modifiée, mettre à jour les re-exports dans `kb_lib/src/db.rs`, puis dans `kb_lib/src/lib.rs` si la surface publique l’exige. ## 8. Priorité immédiate -Les phases `0.7.39`, `0.7.40`, `0.7.41` et `0.7.42` sont considérées comme closes côté documentation lorsque les tests locaux passent et que les requêtes SQL de contrôle Raydium confirment les invariants de la famille Raydium. +La priorité immédiate après le point de reprise `0.7.43-E5C` est : -État acquis : +1. `0.7.43` : resynchronisation documentaire, normalisation DEX-first et gel du point de reprise ; +2. `0.7.44` : ajout du ledger de décodage/replay et options de replay `force` / skip sûr ; +3. `0.7.45` : reprise séparée de `meteora_dlmm` ; +4. `0.7.46` : reprise séparée de `meteora_damm_v1` ; +5. `0.7.47` : reprise séparée de `meteora_damm_v2` ; +6. `0.7.48` : reprise séparée de `meteora_dbc` ; +7. `0.7.49` : revalidation séparée de `orca_whirlpools` ; +8. `0.7.50+` : FluxBeam, DexLab, metaDAO, Printr, puis launch surfaces. -- `0.7.39_dex_first_effective_swap_surfaces` : matrice DEX-first, suppression de l’alias `raydium`, ajout de `metaDAO` et `Printr` en `to_verify`, aucun `program_id` fictif ; -- `0.7.40` : Demo3 découvre on-chain signatures, mints, deltas SPL Token et comptes candidats par DEX/program id ; Demo Pipeline 2 peut backfiller une signature précise ; -- `0.7.41` : `raydium_amm_v4.swap` décode les inner instructions `675kPX...`, produit trades/candles lorsque les montants sont exploitables, et conserve les failed transactions sans matérialisation marché ; -- `0.7.42` : `raydium_cpmm`, `raydium_clmm` et `raydium_amm_v4` sont consolidés comme surfaces Raydium effectives ; CLMM/CPMM couvrent les premiers événements non-trade prouvés ; AMM v4 non-swap reste en audit legacy. +Garde-fous constants : -Résultat de corpus Raydium `0.7.42` : - -- swaps Raydium matérialisés : AMM v4, CLMM `swap_v2`, CLMM legacy `swap`, CPMM `swap_base_input`, CPMM `swap_base_output` ; -- non-trade Raydium matérialisés : `25` liquidity events, `1` pool lifecycle event, `2` fee events ; -- événements CLMM prouvés : `increase_liquidity_v2`, `decrease_liquidity_v2`, `open_position_with_token22_nft`, `close_position` ; -- événements CPMM prouvés : `initialize`, `withdraw`, `collect_creator_fee` ; -- audits restants AMM v4 : conservés comme `raydium_amm_v4.instruction_audit` informatifs, non promus sans preuve ; -- transactions failed : traçables mais exclues de `trade_events`, metrics et candles. - -Limite connue hors Raydium : la base locale peut encore contenir des decoded events `orca_whirlpools.swap` partiels issus du corpus courant. Orca Whirlpools est volontairement reporté à `0.7.44`; ce point ne doit pas bloquer la clôture Raydium `0.7.42`. - -La prochaine étape est maintenant `0.7.43_meteora_effective_surfaces`, puis `0.7.44` pour Orca/FluxBeam/DexLab/metaDAO/Printr. +- pas de faux trade ; +- pas de fausse candle ; +- pas de `program_id` fictif ; +- pas de promotion d’un DEX sans corpus transactionnel ; +- pas de logique métier DEX profonde dans `kb_demo_app` ; +- pas de metadata manquante bloquante ; +- pas de refactor réseau inutile tant que les clients HTTP/WS existants suffisent. ## 9. Fichiers utiles pour reprendre dans une nouvelle session @@ -260,6 +299,8 @@ Pour reprendre rapidement le codage dans une nouvelle session, fournir au minimu - `ROADMAP.md` ; - `CHANGELOG.md` ; - `Cargo.toml` racine ; +- `clippy.toml` ; +- `config.json` ; - `kb_lib/Cargo.toml` ; - `kb_lib/src/lib.rs` ; - `kb_lib/src/constants.rs` ; @@ -267,15 +308,19 @@ Pour reprendre rapidement le codage dans une nouvelle session, fournir au minimu - `kb_lib/src/dex/*.rs` ; - `kb_lib/src/dex_decode.rs` ; - `kb_lib/src/dex_detect.rs` ; +- `kb_lib/src/dex_support_matrix.rs` ; +- `kb_lib/src/dex_event_classification.rs` ; +- `kb_lib/src/non_trade_event_materialization.rs` ; - `kb_lib/src/trade_aggregation.rs` ; - `kb_lib/src/pair_candle_aggregation.rs` ; - `kb_lib/src/local_pipeline_replay.rs` ; - `kb_lib/src/local_pipeline_validation.rs` ; - `kb_lib/src/local_pipeline_diagnostics.rs` ; +- `kb_lib/src/onchain_dex_pair_discovery.rs` ; - `kb_lib/src/db/schema.rs` ; - `kb_lib/src/db.rs` ; - `kb_lib/src/db/entities.rs` et `kb_lib/src/db/entities/*` ; - `kb_lib/src/db/dtos.rs` et `kb_lib/src/db/dtos/*` ; - `kb_lib/src/db/queries.rs` et `kb_lib/src/db/queries/*`. -Ajouter `kb_demo_app/src/demo_pipeline*.rs`, les fichiers frontend associés et les nouvelles démos (`Demo3`, `Demo4`, `Demo10`) seulement si la tâche concerne l’UI, la recherche de corpus, les diagnostics affichés ou le watcher temps réel. +Ajouter `kb_demo_app/src/demo_pipeline*.rs`, `kb_demo_app/src/demo3.rs`, les fichiers frontend associés et les nouvelles démos seulement si la tâche concerne l’UI, la recherche de corpus, les diagnostics affichés ou le watcher temps réel. diff --git a/ROADMAP.md b/ROADMAP.md index a7f9dae..9f1b2de 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1019,35 +1019,129 @@ Réalisé : Limite connue non-Raydium : un corpus local peut encore contenir des événements `orca_whirlpools.swap` partiels. Orca Whirlpools est explicitement reporté à `0.7.44`; cela ne remet pas en cause la clôture Raydium `0.7.42`. -Décision : `0.7.42` est clos côté Raydium. La suite immédiate est `0.7.43` pour Meteora, puis `0.7.44` pour Orca/FluxBeam/DexLab/metaDAO/Printr. +Décision : `0.7.42` est clos côté Raydium. Le lot `0.7.43` ouvert pour Meteora n’est pas considéré comme clos : il devient le point de reprise `0.7.43-E5C`, puis la suite est découpée en étapes plus petites pour éviter les lots multi-DEX trop larges. -### 6.075. Version `0.7.43` — Meteora effectif : DLMM, DAMM v1/v2, DBC -Objectif : compléter la famille Meteora en couvrant les événements réellement utiles au DEX effectif, avec corpus enrichi par Demo3 si nécessaire. +### 6.075. Version `0.7.43` — Point de reprise, normalisation DEX-first et documentation +Objectif : figer le point de reprise après saturation de session, clarifier l’état réel du corpus et empêcher la roadmap de regrouper plusieurs DEX/versions dans une seule tranche de validation. + +À faire / acté : + +- documenter que `0.7.43` n’est pas une clôture Meteora complète ; +- conserver les résultats locaux observés : `2956` transactions, `7159` decoded events, `2738` trade events, `0` liquidity events sur le corpus courant, `1` lifecycle event, `0` fee/reward/admin events ; +- acter que les nombreux `instruction_audit` Meteora sont une dette de décodage, pas une preuve d’événements non-trade matérialisés ; +- imposer un ordre de travail : vrais DEX effectifs, puis launch surfaces, puis DEX historiques/legacy ; +- imposer une validation séparée par DEX/version : `meteora_dlmm`, `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc`, etc. ; +- distinguer les statuts `known`, `observed`, `decoded`, `materialized`, `verified_by_corpus` ; +- maintenir la règle : aucun `program_id` n’est vérifié sans signature/corpus/requête de validation. + +### 6.076. Version `0.7.44` — Ledger de décodage/replay et skip sûr +Objectif : empêcher le replay local de rescanner inutilement les transactions/instructions dont le décodage est déjà certain, tout en gardant la possibilité de forcer ou de retraiter les cas ambigus. À faire : -- conserver la validation `0.7.36` : les swaps DAMM v2 / DBC sans amounts fiables restent `non_actionable_trade` ; -- vérifier `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG` et les autres programmes Meteora dans le corpus local ; -- consolider `meteora_dlmm` pour swaps, positions, add/remove liquidity, lifecycle et non-trade events ; -- consolider `meteora_damm_v1` et `meteora_damm_v2` pour pools, swaps exploitables, configs dynamiques, fees/admin ; -- clarifier la part `launch/bonding_curve` et la part `dex_effective` de `meteora_dbc` ; -- éviter tout trade/candle artificiel lorsque les montants ou prix ne sont pas prouvés. +- ajouter une table de suivi type `k_sol_decode_attempts` ou `k_sol_replay_decode_ledger` dans `kb_lib/src/db/schema.rs` ; +- stocker `transaction_id`, `signature`, `instruction_id` lorsque disponible, `program_id`, `protocol_name`, `decoder_code`, `decoder_version`, `decode_status`, `certainty`, `event_count`, hash d’entrée, reason/error et timestamps ; +- ajouter les entities/dtos/queries associées ; +- mettre à jour les re-exports dans `kb_lib/src/db.rs`, puis `kb_lib/src/lib.rs` si nécessaire ; +- intégrer le ledger dans `local_pipeline_replay.rs` sans changer la sémantique trade/candle ; +- ajouter une option `force` pour ignorer le ledger ; +- ne pas skipper automatiquement les transactions multi-token, multi-pool, multi-event ou marquées `partial` / `ambiguous` ; +- retraiter les lignes concernées lorsqu’un decoder change de version logique ; +- ajouter les diagnostics SQL permettant de mesurer skipped/replayed/ambiguous/forced. -### 6.076. Version `0.7.44` — Autres DEX effectifs : Orca, FluxBeam, DexLab, metaDAO, Printr -Objectif : consolider les DEX non-Raydium/Meteora et intégrer les DEX récemment observés comme candidats vérifiables. +### 6.077. Version `0.7.45` — `meteora_dlmm` séparé +Objectif : consolider `meteora_dlmm` comme DEX effectif séparé, avec corpus dédié et events utiles au trading. À faire : -- revalider `orca_whirlpools` sur corpus dédié : create_pool, swap, liquidité, positions, mints et montants fiables ; -- traiter explicitement les swaps Orca partiels comme non-actionnables tant que les montants ne sont pas reconstruits ; -- constituer des corpus locaux pour `fluxbeam` et `dexlab` ; -- vérifier les `program_id`, comptes, préfixes `data_json` et familles d’instructions utiles ; -- vérifier `metaDAO` et `Printr` par corpus on-chain local avant toute promotion ; -- ne pas confondre source externe de découverte et preuve on-chain ; -- marquer explicitement les variantes partiellement supportées ou heuristiques. +- vérifier le ou les `program_id` par corpus local, pas seulement par constante ; +- consolider swaps exploitables, add/remove liquidity, positions, lifecycle et audits restants ; +- matérialiser uniquement les events prouvés dans les tables dédiées ; +- conserver tout event incomplet en `instruction_audit` ou non-actionnable ; +- ajouter les compteurs diagnostics par event kind. -### 6.077. Version `0.7.45` — Couverture événementielle DEX : swap, liquidité, fees, rewards, admin, burns -Objectif : s’assurer que chaque DEX effectif expose les événements utiles au scoring et au risque sans polluer les trades/candles. +### 6.078. Version `0.7.46` — `meteora_damm_v1` séparé +Objectif : reprendre `meteora_damm_v1` sans le mélanger à DAMM v2, DBC ou DLMM. + +À faire : + +- valider les swaps exploitables et les cas sans amounts ; +- rechercher create/init pool, liquidity, fee/admin/config et autres events utiles ; +- maintenir la règle : pas de trade/candle si base/quote amount ou prix ne sont pas fiables ; +- produire un corpus SQL minimal pour chaque event promu. + +### 6.079. Version `0.7.47` — `meteora_damm_v2` séparé +Objectif : reprendre `meteora_damm_v2` comme DEX effectif séparé, avec traitement spécifique des nombreux `instruction_audit`. + +À faire : + +- vérifier `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG` dans le corpus local avant de le marquer `verified_by_corpus` ; +- consolider `create_pool`, swaps exploitables, configs dynamiques, fees/admin et events lifecycle ; +- conserver les swaps sans payload montant/prix fiables comme `non_actionable_trade` ; +- ne promouvoir aucun event depuis `instruction_audit` sans signature de validation. + +### 6.080. Version `0.7.48` — `meteora_dbc` séparé +Objectif : séparer proprement bonding/launch, swap effectif, migration et attribution d’origine dans `meteora_dbc`. + +À faire : + +- distinguer les events de bonding curve / launch des events de DEX effectif ; +- vérifier swaps exploitables, migration, lifecycle, mint/burn éventuels et launch attribution ; +- éviter toute candle artificielle sur events de bonding/launch non pricés ; +- documenter les signatures/corpus avant toute promotion. + +### 6.081. Version `0.7.49` — `orca_whirlpools` séparé +Objectif : revalider Orca Whirlpools par corpus dédié avant toute promotion au même niveau que Raydium/Meteora. + +À faire : + +- revalider create_pool, swap, liquidité, positions, mints et montants fiables ; +- traiter les swaps Orca partiels comme non-actionnables tant que les montants ne sont pas reconstruits ; +- matérialiser uniquement les events prouvés ; +- ajouter des diagnostics par event kind. + +### 6.082. Version `0.7.50` — `fluxbeam` séparé +Objectif : vérifier FluxBeam comme DEX effectif distinct. + +À faire : + +- constituer un corpus local ; +- vérifier `program_id`, comptes, préfixes `data_json` et familles d’instructions utiles ; +- valider swaps, pools, liquidity et events non-trade prouvés ; +- marquer explicitement les parties heuristiques ou non-actionnables. + +### 6.083. Version `0.7.51` — `dexlab` séparé +Objectif : vérifier DexLab comme DEX effectif distinct, sans le confondre avec OpenBook ou une autre couche de marché. + +À faire : + +- constituer un corpus local ; +- vérifier `program_id`, comptes, préfixes `data_json` et familles d’instructions utiles ; +- valider swaps, pools et éventuels liens de market/pool ; +- conserver les cas partiels en audit. + +### 6.084. Version `0.7.52` — `metaDAO` candidat DEX +Objectif : rechercher et vérifier metaDAO sans inventer de `program_id`. + +À faire : + +- rechercher les signatures/corpus via Demo3, DEX Screener ou sources externes de découverte ; +- ne considérer une source externe que comme indice ; +- promouvoir uniquement après preuve on-chain locale ; +- documenter chaque programme, event et limite. + +### 6.085. Version `0.7.53` — `printr` candidat DEX +Objectif : rechercher et vérifier Printr sans inventer de `program_id`. + +À faire : + +- rechercher les signatures/corpus via Demo3, DEX Screener ou sources externes de découverte ; +- ne considérer une source externe que comme indice ; +- promouvoir uniquement après preuve on-chain locale ; +- documenter chaque programme, event et limite. + +### 6.086. Version `0.7.54` — Couverture événementielle DEX consolidée +Objectif : s’assurer que chaque DEX effectif supporté expose les événements utiles au scoring et au risque sans polluer les trades/candles. À faire : @@ -1060,8 +1154,8 @@ Objectif : s’assurer que chaque DEX effectif expose les événements utiles au - ajouter des compteurs et samples diagnostics par DEX et par type d’événement ; - conserver l’invariant : aucun fee/reward/admin/liquidity/lifecycle/burn non price-action ne produit de trade, metric ou candle. -### 6.078. Version `0.7.46` — `kb_demo_app` Demo4 : DEX Screener et sources externes de découverte -Objectif : utiliser des sources externes comme aides à la découverte de corpus sans les traiter comme vérité métier, après la première consolidation Raydium. +### 6.087. Version `0.7.55` — `kb_demo_app` Demo4 : DEX Screener et sources externes de découverte +Objectif : utiliser des sources externes comme aides à la découverte de corpus sans les traiter comme vérité métier. À faire : @@ -1072,7 +1166,7 @@ Objectif : utiliser des sources externes comme aides à la découverte de corpus - permettre de copier les signatures/adresses candidates pour backfill ; - ne jamais promouvoir automatiquement un DEX, un `program_id` ou une paire sur la seule base d’une réponse externe. -### 6.079. Version `0.7.47` — Démos spécialisées launch surfaces après DEX effectifs +### 6.088. Version `0.7.56` — Démos spécialisées launch surfaces après DEX effectifs Objectif : préparer des vues spécialisées pour les launch surfaces, mais seulement après stabilisation des DEX effectifs. À faire plus tard : @@ -1083,7 +1177,7 @@ Objectif : préparer des vues spécialisées pour les launch surfaces, mais seul - exposer les origins dans les diagnostics et l’UI d’inspection ; - maintenir l’interdiction de faux program ids, faux trades et fausses candles. -### 6.080. Version `0.7.48` — `kb_demo_app` Demo10 : watcher WebSocket live DEX +### 6.089. Version `0.7.57` — `kb_demo_app` Demo10 : watcher WebSocket live DEX Objectif : valider le passage du replay/backfill vers l’observation temps réel contrôlée. À faire : @@ -1097,7 +1191,7 @@ Objectif : valider le passage du replay/backfill vers l’observation temps rée - afficher les compteurs live, erreurs, subscriptions actives et derniers objets persistés ; - prévoir un arrêt propre avec unsubscribe avant close. -### 6.081. Version `0.7.49` — Validation DEX v1 consolidée +### 6.090. Version `0.7.58` — Validation DEX v1 consolidée Objectif : rejouer tous les DEX effectifs supportés et valider les invariants du pipeline complet avant de revenir aux launch surfaces ou à l’analyse `0.8.x`. À faire : @@ -1110,7 +1204,7 @@ Objectif : rejouer tous les DEX effectifs supportés et valider les invariants d - 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.082. Version `0.8.x` — Analyse et filtrage +### 6.091. Version `0.8.x` — Analyse et filtrage Objectif : transformer les événements bruts en signaux exploitables. À faire : @@ -1282,29 +1376,33 @@ Le projet doit maintenir au minimum : ## 12. Priorité immédiate -La priorité immédiate après `0.7.42` est `0.7.43_meteora_effective_surfaces`. La consolidation Raydium est considérée comme close côté Raydium : `raydium_cpmm`, `raydium_clmm` et `raydium_amm_v4` sont traités comme surfaces Raydium effectives, avec les limites explicitement documentées ci-dessous. +La priorité immédiate après le point de reprise `0.7.43-E5C` n’est plus de terminer Meteora en un seul bloc. Le lot Meteora groupé a montré ses limites : les events, les audits, les surfaces bonding/launch et les variantes de DEX doivent être traités séparément. -Préconditions validées avant `0.7.43` : +Préconditions considérées acquises avant cette reprise : -1. validation `0.7.36` acquise : Meteora consolidé, transactions failed traçables mais non actionnables, swaps sans amounts classés `non_actionable_trade`, aucun diagnostic bloquant masqué ; +1. validation `0.7.36` acquise : Meteora consolidé au niveau baseline, transactions failed traçables mais non actionnables, swaps sans amounts classés `non_actionable_trade`, aucun diagnostic bloquant masqué ; 2. validation `0.7.37` acquise : compteurs metadata/catalog exposés, backfill metadata idempotent, `pair_symbol` rafraîchissables, metadata manquantes non bloquantes ; 3. validation `0.7.38` acquise : `tokenMetadataGapSamples` priorisés, Demo Pipeline 2 raccordé, registre local `WSOL`/`USDC`/`USDT`/`JUP`/`RAY`/`BONK` disponible ; 4. `0.7.39` acquis : matrice DEX-first, suppression de l’alias `raydium`, `metaDAO` et `Printr` en `to_verify`, aucun `program_id` fictif ; 5. `0.7.40` acquis : `Demo3` découvre on-chain des signatures, mints, deltas et comptes candidats ; Demo Pipeline 2 peut backfiller une signature précise ; 6. `0.7.41` acquis : `raydium_amm_v4.swap` décode les inner instructions `675kPX...`, produit des trades/candles lorsque les montants sont exploitables, et conserve les transactions failed sans matérialisation marché ; -7. `0.7.42` acquis côté Raydium : CLMM/CPMM couvrent swaps et premiers non-swaps prouvés ; AMM v4 couvre les swaps et conserve les non-swaps legacy en audit ; les non-trade events utiles prouvés alimentent leurs tables dédiées ; -8. la dette Orca Whirlpools observée dans le corpus local est reportée à `0.7.44` et ne doit pas être mélangée à la clôture Raydium. +7. `0.7.42` acquis côté Raydium : CLMM/CPMM couvrent swaps et premiers non-swaps prouvés ; AMM v4 couvre les swaps et conserve les non-swaps legacy en audit ; +8. `0.7.43-E5C` est le point de reprise documentaire et technique, avec Clippy `kb_lib` validé localement après correction. Ordre de travail recommandé pour la suite : -1. `0.7.43` : consolider Meteora effectif (`meteora_dlmm`, `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc`) avec la même approche corpus-first ; -2. `0.7.44` : revalider Orca Whirlpools, puis FluxBeam, DexLab, metaDAO et Printr ; -3. `0.7.45` : établir une couverture transversale des événements DEX utiles au scoring : swaps, liquidités, lifecycle, fees, rewards, admin/config, burns/mints ; -4. `0.7.46` : ajouter Demo4 pour les sources externes de découverte sans promotion automatique ; -5. `0.7.47` : ajouter des démos spécialisées launch surfaces après DEX effectifs ; -6. `0.7.48` : ajouter Demo10 pour le watcher WebSocket live DEX ; -7. `0.7.49` : validation DEX v1 consolidée ; -8. passer ensuite à l’analyse `0.8.x`, puis à la couche wallet. +1. `0.7.44` : ledger de décodage/replay et skip sûr ; +2. `0.7.45` : `meteora_dlmm` ; +3. `0.7.46` : `meteora_damm_v1` ; +4. `0.7.47` : `meteora_damm_v2` ; +5. `0.7.48` : `meteora_dbc` ; +6. `0.7.49` : `orca_whirlpools` ; +7. `0.7.50` : `fluxbeam` ; +8. `0.7.51` : `dexlab` ; +9. `0.7.52` : `metaDAO` candidat DEX ; +10. `0.7.53` : `printr` candidat DEX ; +11. `0.7.54` : couverture événementielle DEX consolidée ; +12. `0.7.55+` : sources externes de découverte, launch surfaces, watcher live et validation consolidée. Garde-fous constants : @@ -1314,4 +1412,5 @@ Garde-fous constants : - pas de promotion d’un DEX sans corpus transactionnel ; - pas de logique métier DEX profonde dans `kb_demo_app` ; - pas de metadata manquante bloquante ; -- pas de refactor réseau inutile tant que les clients HTTP/WS existants suffisent. +- pas de refactor réseau inutile tant que les clients HTTP/WS existants suffisent ; +- pas de skip replay sur transaction/instruction ambiguë, multi-token ou multi-event sans preuve ledger. diff --git a/kb_demo_app/frontend/demo3.html b/kb_demo_app/frontend/demo3.html index 3ef0ef2..49aa21b 100644 --- a/kb_demo_app/frontend/demo3.html +++ b/kb_demo_app/frontend/demo3.html @@ -24,7 +24,7 @@
-
+
@@ -37,24 +37,59 @@ Recherche directement sur Solana via getSignaturesForAddress + getTransaction. Le résultat sert à trouver une signature, un pool ou un mint à backfiller ensuite dans Demo Pipeline 2.

- +
Choisis un DEX ou saisis un program id manuellement.
- +
- +
- + +
Used to filter matched instructions. With address source, signatures are fetched from Source address instead.
- + +
+
+ + +
+
+ + +
+
Use address source to discover signatures around a pool, vault, position, config or mint while keeping the program id filter.
+
+
+
+ + +
Use this to find corpus signatures for non-swap decoders without promoting unverified events.
+
@@ -71,8 +106,20 @@
+
+
+ + +
+
+
+
+ + +
+
- +
@@ -81,7 +128,7 @@
- +

Filtres locaux optionnels

@@ -103,15 +150,20 @@
- +

Résumé

Signatures: 0
+
Unique candidates: 0
Tx fetched: 0
Missing tx: 0
Failed tx: 0
+
Skipped failed: 0
+
Skipped swap tx: 0
+
Extracted: 0
+
Rejected by target: 0
Candidates: 0
Local pairs: 0
@@ -120,9 +172,13 @@ Target: -
+
+ Backfill signatures: + - +
- +

Logs

@@ -131,7 +187,7 @@
- +
@@ -144,6 +200,7 @@ Slot Kind Confidence + Data prefix Verified pool Token A Token B @@ -154,13 +211,39 @@ - No on-chain candidate. + + No on-chain candidate. +
- + +
+
+

Rejected candidate summary

+
+ + + + + + + + + + + + + + + +
KindPrefixInstructionReasonCount
No rejected candidate summary.
+
+
+
+

Recherche locale DB

@@ -179,13 +262,15 @@ - No local pool/pair sample. + + No local pool/pair sample. +
- +

Raw result JSON

@@ -211,4 +296,4 @@ - + \ No newline at end of file diff --git a/kb_demo_app/frontend/demo_pipeline2.html b/kb_demo_app/frontend/demo_pipeline2.html index f61b432..36c6e8e 100644 --- a/kb_demo_app/frontend/demo_pipeline2.html +++ b/kb_demo_app/frontend/demo_pipeline2.html @@ -179,7 +179,8 @@