<!-- file: ROADMAP.md -->

# khadhroony-bobobot — Roadmap

## État courant — clôture `0.7.54 pump_fun` et ouverture `0.7.55 pump_fees`

`0.7.54 pump_fun` est clos pour la surface Pump.fun principale. La tranche a transformé l'ouverture documentaire en decoder local maximal : inventaire des `40` instructions et `23` events Anchor de l'IDL locale, coverage local, décodage Anchor/self-CPI/log, tests synthétiques, routes catalogue et matérialisation prudente.

Décisions de clôture Pump.fun :

- `pump_fun.buy` et `pump_fun.sell` restent matérialisés directement quand les montants sont fiables ;
- `pump_fun.buy_exact_sol_in` est matérialisé directement, y compris quand un `Program data` tronqué permet d'extraire les montants exacts ;
- `pump_fun.buy_v2`, `pump_fun.sell_v2` et `pump_fun.buy_exact_quote_in_v2` sont decoded/audit/routing, mais ne sont pas matérialisés directement ;
- `pump_fun.trade_event` devient la source canonique des montants exécutés pour les v2/exact quand il est corrélé à l'instruction sans ambiguïté ;
- les `trade_event` déjà couverts par un trade direct reçoivent un skip explicite pour empêcher le double-count ;
- les non-trades Pump.fun sont matérialisés seulement vers `launch`, `fee`, `reward`, `admin` ou `lifecycle` quand le contexte est fiable ; sinon ils restent decoded-only/audit-only avec skip reason ;
- les validations `Q00`, `Q04`, `Q05`, `Q06`, `Q07`, `Q08`, `Q11` sont propres ; la watchlist globale ne contient plus de `pump_fun`.

Replay final rapporté : `1679 replayed`, `89 trades`, `10 lifecycle`, `348 candle upserts`, `13905 instructionObservations`, catalogue `52 tokens / 50 pools / 50 pairs`.

### Phasage immédiat après `0.7.54`

| Priorité | Tranche | Surface | Raison |
|---:|---|---|---|
| 1 | `0.7.55` | `pump_fees` | Backlog global restant : `get_fees`, `create_fee_sharing_config`, `update_fee_shares`; programme fee associé à Pump. Tout décoder et tout matérialiser si fiable. |
| 2 | `0.7.56+` | `meteora_*` | Corriger les gaps locaux Meteora reportés volontairement. |
| 3 | ultérieur | `jupiter_swap` / agrégateurs | Routes et comptes auxiliaires à traiter sans double-count des DEX effectifs. |


## 0.7.47-1FE5 — Décision de planification : ne plus viser “tous les events en une session”

La phase `0.7.47` a montré que l’objectif “réimplémenter tous les décodeurs Carbon et toutes les sources en un seul bloc” est trop large. Le plan est donc redécoupé en **un DEX/version par tranche**, avec une matrice documentaire dédiée : `docs/DEX_DECODER_MATRIX.md`.

Règles de planification :

- chaque DEX/version doit avoir sa propre phase de corpus ;
- chaque phase doit lister explicitement les sources Git/IDL consultées ;
- tous les events/instructions disponibles dans les sources doivent être inventoriés, même si seuls certains deviennent matérialisés ;
- le statut par event doit rester séparé : `upstream_git_unverified`, `upstream_git_mapped_unverified`, `upstream_git_local_corpus_observed`, `audit-only`, `materialized` ;
- un decoder local spécialisé peut remplacer `upstream_git.instruction_match`, mais ne doit pas créer de trade/candle sans validation de montants et de sens économique ;
- OpenBook v2 et Phoenix v1 restent `audit-only` à ce stade, malgré leurs layouts partiellement décodés.

### Sources upstream obligatoires à vérifier

| Source | Usage |
|---|---|
| `idls/` | Corpus local d’IDL Solscan téléchargés et versionnés dans le workspace ; source locale obligatoire à comparer aux liens Git avant décision de decoder. |
| `https://github.com/sevenlabs-hq/carbon/tree/main/decoders` | Source principale des decoders multi-protocoles. |
| `https://github.com/0xfnzero/solana-streamer` | Source complémentaire PumpFun/PumpSwap/Bonk/Raydium CPMM. |
| `https://github.com/0xfnzero/sol-parser-sdk/tree/main/idls` | IDL complémentaires. |
| `https://github.com/pinax-network/substreams-solana-idls/tree/main/src` | IDL et layouts additionnels. |
| `https://github.com/hodlwarden/solana-tx-parser/tree/main/src` | Parsers transactionnels complémentaires. |
| `https://github.com/openbook-dex/openbook-v2` | Source officielle OpenBook v2. |
| `https://github.com/all-in-one-blockchain/phoenix-onchain-mm` | Source Phoenix/MM complémentaire. |
| `https://docs.vybenetwork.com/docs/available-dexs-amms` | Source externe de découverte DEX/AMM, non vérifiante. |

### Plan révisé `0.7.53+` — une version par `program_id`

Règle de planification validée après `0.7.52` : **une version cible = un `program_id`**.

Exceptions : les comptes non-programmes (`platform_config`, token authority, comptes de configuration, comptes de pool, accounts de programme) ne créent pas de version decoder autonome. Ils restent des sources de contexte ou d’enrichissement. `SOLSCAN_ACCOUNT_SOURCES` reste un inventaire de découverte, pas une preuve de support local.

| Version cible | Decoder / surface | Program id | Famille | Objectif de clôture |
|---|---|---|---|---|
| `0.7.53` | `pump_swap` | `pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA` | Pump / AMM | **Clos** : `buy/sell/buy_exact_quote_in` matérialisés seulement depuis sources exactes ; events Anchor audit-only ; tests synthétiques IDL ; SQL global. |
| `0.7.54` | `pump_fun` | `6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P` | Pump / launch-bonding | **Clos** : decoder maximal IDL/local, trades directs `buy/sell/buy_exact_sol_in`, v2/exact via `trade_event`, non-trades matérialisés selon contexte, validations Pump.fun propres. |
| `0.7.55` | `pump_fees` | `pfeeUxB6jkeY1Hxd7CsFCAjcbHA9rWtchMGdZ6VojVZ` | Pump / fee | Couvrir fee accounting/claim/config observés ; aucun trade/candle direct. |
| `0.7.56` | `meteora_dbc` | `dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN` | Meteora / DBC | Compléter launch/bonding, swaps exploitables, migration, fees/admin/config. |
| `0.7.57` | `meteora_dlmm` | `LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo` | Meteora / DLMM | Parité upstream finale : swaps, bins, positions, liquidity, fees/rewards/admin. |
| `0.7.58` | `meteora_damm_v1` | `Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB` | Meteora / DAMM v1 | Parité upstream finale : pools, swaps, liquidity, lock, fees/admin. |
| `0.7.59` | `meteora_damm_v2` | `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG` | Meteora / DAMM v2 | Couverture complète : create/custom pools, swaps, liquidity, dynamic config, fees/admin. |
| `0.7.60` | `meteora_vault` | `24Uqj9JCLxUeoC3hGfh5W3s9FM9uCHDS2SG3LYwBpyTi` | Meteora / vault | Vault deposit/withdraw/fee/accounting ; pas de candle directe. |
| `0.7.61` | `system_program` | `11111111111111111111111111111111` | Système Solana | Create/assign/transfer account ; side effects de contexte, pas de trade. |
| `0.7.62` | `spl_token` | `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA` | SPL Token | Transfer, mint, burn, close account, sync native ; base transversale pour deltas. |
| `0.7.63` | `spl_token_2022` | `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` | Token-2022 | Transfers/extensions Token-2022, mint/burn/close, comptes et side effects. |
| `0.7.64` | `associated_token_account` | `ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL` | Système token | Création ATA, rattachement wallet/token/pool. |
| `0.7.65` | `compute_budget` | `ComputeBudget111111111111111111111111111111` | Contexte tx | Budget/prioritization fee ; utile scoring/MEV, pas de trade. |
| `0.7.66` | `memo` | `MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr` | Contexte tx | Mémo transactionnel et attribution éventuelle. |
| `0.7.67` | `address_lookup_table` | `AddressLookupTab1e1111111111111111111111111` | Contexte tx | Résolution/diagnostic ALT si nécessaire. |
| `0.7.68` | `mpl_token_metadata` | `metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s` | Metadata | Enrichissement token/NFT/mint metadata. |
| `0.7.69` | `mpl_core` | `CoREENxT6tW1HoK8ypY1SxRMZTcVPm7R94rH4PZNhX7d` | Metadata / asset | Contexte asset si présent dans corpus. |
| `0.7.70` | `bubblegum` | `BGUMAp9Gq7iTEuizy4pqaxsTyUCBK68MDfK752saRPUY` | Compressed assets | Audit/contexte assets compressés, pas DEX. |
| `0.7.71` | `raydium_routing` | `routeUGWgWzqBWFcrCfv8tritsqukccJPu3q5GPP3xS` | Router | Route/legs Raydium ; éviter le double-count avec DEX effectifs. |
| `0.7.72` | `jupiter_swap_v6` | `JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4` | Aggregator | Route attribution, legs, no duplicate trade/candle. |
| `0.7.73` | `jupiter_swap_v4` | `JUP4Fb2cqiRUcaTHdrPC8h2gNsA2ETXiPDD33WcGuJB` | Legacy aggregator | Audit/route only si corpus encore utile. |
| `0.7.74` | `dflow_aggregator_v4` | `DF1ow4tspfHX9JwWJsAb9epbkA8hmpSEAtxXy1V27QBH` | Aggregator | Route/intent/orderflow ; pas de double matérialisation. |
| `0.7.75` | `okx_dex` | `6m2CDdhRgxpH4WjvdzxAYbGxwdGUz5MziiL5jek2kBma` | Aggregator/router | Route attribution ; trades seulement si source exacte non doublonnée. |
| `0.7.76` | `onchain_labs_dex_v2` | `proVF4pMXVaYqmy4NjniPh4pqKNfMmsihgd4wdkCX3u` | Router/DEX candidat | Corpus d’abord ; classifier route vs DEX effectif. |
| `0.7.77` | `titan_router` | `T1TANpTeScyeqVzzgNViGDNrkQ6qHz9KrSBS4aNXvGT` | Router | Audit route-only sauf preuve de trade direct non doublonné. |
| `0.7.78` | `sanctum_router` | `stkitrT1Uoy18Dk1fTrgPw8W6MVzoCfYoAFT4MLsmhq` | Router | Route/liquid staking context ; pas de candle DEX directe. |
| `0.7.79` | `orca_whirlpools` | `whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc` | DEX avec IDL/source | Swaps, pools, positions, liquidity, fees/rewards. |
| `0.7.80` | `stabble_stable_swap` | `swapNyd8XiQwJ6ianp9snpu4brUqFxadzvHebnAXjJZ` | DEX avec IDL/source | Stable swap ; deltas exacts, liquidity/admin. |
| `0.7.81` | `stabble_weighted_swap` | `swapFpHZwjELNnjvThjajtiVmkz3yPQEHjLtka2fwHW` | DEX avec IDL/source | Weighted swap, deltas exacts, liquidity/admin. |
| `0.7.82` | `stabble_clmm` | `6dMXqGZ3ga2dikrYS9ovDXgHGh5RUsb2RTUj6hrQXhk6` | DEX avec IDL/source | CLMM Stabble si corpus utile. |
| `0.7.83` | `bonkswap` | `BSwp6bEBihVLdqJRKGgzjcGLHkcTuzmSo1TQkHepzH8p` | DEX avec IDL/source | Swap/liquidity/non-trade. |
| `0.7.84` | `boop_fun` | `boop8hVGQGqehUK2iVEMEnMrL5RbjywRzHKBmBE7ry4` | Launch/DEX candidat | Launch/swap/migration selon corpus. |
| `0.7.85` | `byreal_clmm` | `REALQqNEomY6cQGZJUGwywTBD2UmDT32rZcNnfxQ5N2` | DEX avec IDL/source | CLMM ; corpus puis matérialisation contrôlée. |
| `0.7.86` | `fusionamm` | `fUSioN9YKKSa3CUC2YUc4tPkHJ5Y6XW1yz8y6F7qWz9` | DEX avec IDL/source | AMM ; swaps/liquidity si corpus. |
| `0.7.87` | `goosefx_v1` | `GAMMA7meSFWaBXF25oSUgmGRwaW6sCMFLmBNiMSdbHVT` | DEX avec IDL/source | DEX/AMM selon corpus. |
| `0.7.88` | `goosefx_v2` | `GFXsSL5sSaDfNFQUYsHekbWBW1TsFdjDYzACh62tEHxn` | DEX avec IDL/source | DEX/AMM selon corpus. |
| `0.7.89` | `guac_swap` | `Gswppe6ERWKpUTXvRPfXdzHhiCyJvLadVvXGfdpBqcE1` | DEX avec IDL/source | Swap/liquidity si corpus. |
| `0.7.90` | `hylo_exchange` | `HYEXCHtHkBagdStcJCp3xbbb9B7sdMdWXFNj6mdsG4hn` | DEX/source à classifier | Classer DEX/lending/stable selon IDL/corpus. |
| `0.7.91` | `printr` | `T8HsGYv7sMk3kTnyaRqZrbRPuntYzdh12evXBkprint` | Launch/DEX candidat | Corpus d’abord ; surface launch/swap à confirmer. |
| `0.7.92` | `moonit` | `MoonCVVNZFSYkqNXP6bxHLPL6QQJiMagDL3qcqUQTrG` | Launch/DEX candidat | Launch/migration/swap si prouvé. |
| `0.7.93` | `metadao_amm_v0_5` | `AMMJdEiCCa8mdugg6JPF7gFirmmxisTfDJoSNSUi5zDJ` | DEX avec source | AMM futarchy ; corpus et price semantics. |
| `0.7.94` | `metadao_bid_wall` | `WALL8ucBuUyL46QYxwYJjidaFYhdvxUFrgvBxPshERx` | Order/bid-wall | Order/bid-wall context ; pas de candle directe sans fill exact. |
| `0.7.95` | `metadao_launchpad` | `moontUzsdepotRGe5xsfip7vLPTJnVuafqdUWexVnPM` | Launch surface | Launch/ICO surface ; pas DEX effectif par défaut. |
| `0.7.96` | `vertigo` | `vrTGoBuy5rYSxAfV3jaRJWHH6nN9WK4NRExGxsk1bCJ` | DEX/source | Swap/launch selon corpus. |
| `0.7.97` | `virtuals` | `5U3EU2ubXtK84QcRjWVmYt9RaDyA8gKxdUrPFXmZyaki` | Launch/DEX candidat | Launch/AMM à confirmer. |
| `0.7.98` | `wavebreak` | `waveQX2yP3H1pVU8djGvEHmYg8uamQ84AuyGtpsrXTF` | DEX/source | Corpus et rôle exact. |
| `0.7.99` | `woofi` | `WooFif76YGRNjk1pA8wCsN67aQsD9f9iLsz4NcJ1AVb` | DEX/router | Swap/route selon corpus. |
| `0.7.100` | `pancake_swap` | `HpNfyc2Saw7RKkQd8nEL4khUcuPhQ7WwY1B2qjx8jxFq` | DEX/source | DEX Solana à confirmer par corpus. |
| `0.7.101` | `gavel` | `srAMMzfVHVAtgSJc8iH6CfKzuWuUTzLHVCE81QU1rgi` | Source upstream | Corpus d’abord ; rôle exact à classer. |
| `0.7.102` | `heaven` | `HEAVENoP2qxoeuF8Dj2oT1GHEnu49U5mJYkdeC8BAX2o` | Launch/DEX candidat | Launch/DEX selon corpus. |
| `0.7.103` | `lifinity_v2` | `2wT8Yq49kHgDzXuPxZSaeLaH1qbmGXtEyPy64bL7aD3c` | DEX legacy/actif | Support selon corpus. |
| `0.7.104` | `moonshot` | `MoonCVVNZFSYkqNXP6bxHLPL6QQJiMagDL3qcqUQTrG` | Source upstream/Solscan | À dédupliquer avec `moonit` si même program id. |
| `0.7.105` | `openbook_v2` | `opnb2LAfJYbRMAHHvqjCwQxanZn7ReEHp1k81EohpZb` | Orderbook | Audit/orderbook complet ; trade/candle seulement si fills exacts. |
| `0.7.106` | `phoenix_v1` | `PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY` | Orderbook | Audit-only complet avant toute matérialisation fill. |
| `0.7.107` | `alphaq` | `ALPHAQmeA7bjrVuccPsYPiCvsi428SNwte66Srvs4pHA` | Solscan/no IDL | Probe par Demo3 + corpus ; décider support ou abandon. |
| `0.7.108` | `aquifer` | `AQU1FRd7papthgdrwPTTq5JacJh8YtwEXaBfKU3bTz45` | Solscan/no IDL | Probe uniquement. |
| `0.7.109` | `bisonfi` | `BiSoNHVpsVZW2F7rx2eQ59yQwKxzU5NvBcmKshCSUypi` | Solscan/no IDL | Probe uniquement. |
| `0.7.110` | `dexlab` | `DSwpgjMvXhtGn6BsbqmacdBZyfLj6jSWf3HJpdJtmg6N` | Solscan/no IDL | Vérifier support partiel / corpus. |
| `0.7.111` | `fluxbeam` | `FLUXubRmkEi2q6K3Y9kBPg9248ggaZVsoSFhtJHSrm1X` | Solscan/no IDL | Vérifier support partiel / corpus. |
| `0.7.112` | `goonfi` | `goonERTdGsjnkZqWuVjs73BZ3Pb9qoCUdBUL17BnS5j` | Solscan/no IDL | Probe. |
| `0.7.113` | `goonfi_v2` | `goonuddtQRrWqqn5nFyczVKaie28f3kDkHWkHtURSLE` | Solscan/no IDL | Probe ; adresse à revérifier si erreur de taille. |
| `0.7.114` | `humidifi` | `9H6tua7jkLhdm3w8BvgpTn5LZNU7g4ZynDmCiNN3q6Rp` | Solscan/no IDL | Probe. |
| `0.7.115` | `obric_v2` | `obriQD1zbpyLz95G5n7nJe6a4DPjpFwa5XYPoNm113y` | Solscan/no IDL | Probe. |
| `0.7.116` | `ondo_global_market` | `XzTT4XB8m7sLD2xi6snefSasaswsKCxx5Tifjondogm` | Solscan IDL | Rôle marché/tokenized assets à confirmer. |
| `0.7.117` | `scorch` | `SCoRcH8c2dpjvcJD6FiPbCSQyQgu3PcUAWj2Xxx3mqn` | Solscan/no IDL | Probe. |
| `0.7.118` | `solfi` | `SoLFiHG9TfgtdUXUjWAxi3LtvYuFyDLVhBWxdMZxyCe` | Solscan/no IDL | Probe. |
| `0.7.119` | `solfi_v2` | `SV2EYYJyRz2YhfXwXnhNAevDEui5Q6yrfyo13WtupPF` | Solscan/no IDL | Probe. |
| `0.7.120` | `zerofi` | `ZERor4xhbUycZ6gb9ntrhqscUcZmAbQDjEAtCf4hbZY` | Solscan/no IDL | Probe. |
| `0.7.121` | `zora` | `zoRabwLGd5zXaV7Gxacppw8tcceXEiTrSKyNLSaSTUc` | Solscan/no IDL | Probe, pas de promotion sans corpus. |
| `0.7.122` | `1dex` | `DEXYosS6oEGvk8uCDayvwEZz4qEyDJRf9nFgYCaqPMTm` | Solscan/no IDL | Probe. |
| `0.7.123` | `aldrin_amm` | `AMM55ShdkoGRB5jVYPjWziwk8m5MpwyDgsMWHaMSQWH6` | Legacy/no IDL | Historique/probe. |
| `0.7.124` | `aldrin_amm_v2` | `CURVGoZn8zycx6FXwwevgBTB2gVvdbGTEpvMJDbgs2t4` | Legacy/no IDL | Historique/probe. |
| `0.7.125` | `crema_finance` | `CLMM9tUoggJu2wagPkkqs9eFG4BWhVBZWkP1qv3Sp7tR` | Legacy/no IDL | Historique/probe. |
| `0.7.126` | `cropper_finance` | `CTMAxxk34HjKWxQ3QLZK1HpaLXmBveao3ESePXbiyfzh` | Legacy/no IDL | Historique/probe. |
| `0.7.127` | `cropper_whirlpool` | `H8W3ctz92svYg6mkn1UtGfu2aQr2fnUFHM1RhScEtQDt` | Legacy/no IDL | Historique/probe. |
| `0.7.128` | `mercurial_stable_swap` | `MERLuDFBMmsHnsBPZw2sDQZHvXFMwp8EdjudcU2HKky` | Legacy/no IDL | Historique stable swap ; deltas exacts si support. |
| `0.7.129` | `saber_stable_swap` | `SSwpkEEcbUqx4vtoEByFjSkhKdCT862DNVb52nZg1UZ` | Legacy/no IDL | Historique stable swap. |
| `0.7.130` | `saros_amm` | `SSwapUtytfBdBn1b9NUGG6foMVPtcWgpRU32HToDUZr` | Legacy/no IDL | Historique/probe. |
| `0.7.131` | `step_finance_swap` | `SSwpMgqNDsyV7mAgN9ady4bDVu5ySjmmXejXvy2vLt1` | Legacy/no IDL | Historique/probe. |
| `0.7.132` | `stepn_dooar_swap` | `Dooar9JkhdZ7J3LHN3A7YCuoGRUggXhQaG4kijfLGU2j` | Legacy/no IDL | Historique/probe. |
| `0.7.133` | `raydium_amm_v2_legacy` | `RVKd61ztZW9GUwhRbbLoYVRE5Xf1B2tVscKqwZqXgEr` | Raydium legacy/no IDL | Historique Raydium ; corpus d’abord. |
| `0.7.134` | `raydium_amm_v3_legacy` | `27haf8L6oxUeXrHrgEgsexjSY5hbVUWEmvv9Nyxg8vQv` | Raydium legacy/no IDL | Historique Raydium ; ne pas confondre avec CLMM moderne. |
| `0.7.135` | `raydium_pool_v4_json_audit` | aucun `program_id` prouvé par le fichier seul | Audit source annexe | Vérifier `sol-parser-sdk/idls/raydium_pool_v4.json` après les surfaces documentées ; patch AMM v4 si amélioration, sinon clôture no-op. |
| `0.7.136` | cleanup `SOLSCAN_ACCOUNT_SOURCES` | n/a | Nettoyage registry/constants | Retirer doublons/promotions ; les programmes validés deviennent constantes/support matrix, les comptes non-programmes restent contexte ou sont supprimés. |
| `0.7.137` | base neuve multi-programmes | n/a | Validation consolidée | Replay consolidé, coverage global, zéro faux trade/candle, diagnostics bloquants à zéro. |

Ce plan remplace les regroupements larges qui mélangeaient plusieurs DEX ou plusieurs `program_id` dans une seule tranche. `raydium_pool_v4.json` est explicitement repoussé vers la fin : il ne bloque plus `0.7.53`.


## 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_demo_app` : application Demo 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_demo_app` ne doit pas embarquer la logique métier réseau ou Solana.
- `kb_demo_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 `kb_lib::Error`,
- création de `kb_lib::Config`,
- création de `kb_lib::init_tracing`,
- création des constantes Solana officielles,
- préparation des modules `ws_client` et `http_client`,
- remise de `kb_demo_app/src/lib.rs` en conformité,
- documentation de `kb_demo_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_demo_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_demo_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_demo_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 `kb_lib::Database`,
- premier schéma technique,
- table `k_sol_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 `k_sol_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 `k_sol_db_runtime_events`,
- ajout des observations on-chain brutes via `k_sol_onchain_observations`,
- ajout des signaux d’analyse via `k_sol_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_demo_app`
Réalisé :

- ajout d’une fenêtre `Demo Ws Manager` dans `kb_demo_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 `k_sol_onchain_observations` et `k_sol_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 `k_sol_chain_slots`, `k_sol_chain_transactions` et `k_sol_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 `k_sol_pools`, `k_sol_pairs`, `k_sol_pool_tokens` et `k_sol_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 `k_sol_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 `k_sol_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 `k_sol_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 `k_sol_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 `k_sol_dex_decoded_events`,
- ajout de la détection métier `Orca Whirlpools` vers `pool / pair / listing`,
- utilisation de `PoolKind::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 `k_sol_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 `k_sol_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 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_demo_app` : inspection et tests du pipeline `0.7.x`
Réalisé :

- ajout d’une fenêtre dédiée `Demo Pipeline` dans `kb_demo_app`,
- inspection du pipeline persistant par `signature`,
- inspection du pipeline persistant par `token mint`,
- inspection du pipeline persistant par `pair id`,
- inspection du pipeline persistant par `pool address`,
- affichage structuré des transactions résolues, événements DEX décodés, pools, paires, listings, launch origins, pool origins, wallets observés, holdings observés, trade events, pair metrics, candles et signaux analytiques,
- possibilité d’utiliser un timeframe custom pour régénérer à la demande les candles non matérialisées,
- conservation d’une instance partagée de `Database` dans `kb_demo_app` afin d’éviter la réouverture de la base et la réinitialisation du schéma à chaque commande UI,
- validation pratique de l’inspection du pipeline `0.7.x` sans dépendre uniquement des logs bruts ou de la consultation manuelle de SQLite.

### 6.055. Version `0.7.23` — `kb_demo_app` : backfill token ciblé
Réalisé :

- ajout d’un pilotage UI du backfill historique ciblé par `token mint` dans `kb_demo_app`,
- sélection du `token mint`, du rôle HTTP et des limites de signatures `mint / pool`,
- exécution de `TokenBackfillService` depuis une commande Tauri dédiée,
- affichage du résumé de backfill dans `Demo Pipeline`,
- réinspection automatique du token après backfill lorsque des objets persistés exploitables sont effectivement reconstruits,
- gestion explicite du cas où le backfill réussit sans matérialiser de token exploitable dans la base locale.

### 6.056. Version `0.7.24` — `kb_demo_app` : visualisation candles / OHLCV
Réalisé :

- ajout d’un affichage graphique des candles / OHLCV dans `kb_demo_app` via `echarts`,
- sélection dynamique de la paire inspectée,
- sélection dynamique du timeframe disponible,
- affichage conjoint des chandeliers OHLC et du volume,
- prise en charge des candles matérialisées et des candles régénérées à la demande pour un timeframe custom,
- intégration du rendu graphique directement dans `Demo Pipeline`.

### 6.057. Version `0.7.25` — Enrichissement metadata des tokens
Réalisé :

- Ajout :
  - relecture locale du pipeline à partir des transactions brutes persistantes de la chaîne,
  - actualisation optionnelle des métadonnées de jetons manquantes lors de la relecture locale,
  - reconstruction des symboles de paires à partir des métadonnées des jetons,
  - commandes d’interface utilisateur dans le pipeline de démonstration 2 pour la relecture locale,
  - flux de travail d’actualisation du catalogue de jetons/paires piloté par les métadonnées.
- Modifications :
  - les symboles de paires sont désormais dérivés comme `BASE/QUOTE` lorsque les deux symboles de jetons sont disponibles,
  - l’actualisation des métadonnées évite de nécessiter un remplissage complet de la blockchain lorsque les données de transaction brutes existent déjà localement.
- Corrections :
  - suppression des cycles complets de suppression/remplissage répétés pour les métadonnées et les entités locales dérivées,
  - conservation de l’accès SQL dans les modules de requêtes de base de données au lieu du SQL brut au niveau du service.

### 6.058. Version `0.7.26` — Diagnostics locaux, replay et extraction instruction-scoped
Réalisé :

- Ajout du diagnostic local complet du pipeline persisté :
  - transactions OK / échouées,
  - événements décodés,
  - trade candidates,
  - trade events,
  - candles,
  - tokens,
  - pools,
  - pairs,
  - diagnostics par DEX,
  - diagnostics par paire,
  - samples d’événements manquants ou multi-trades.
- Ajout des compteurs de santé du pipeline :
  - `diagnosticsClean`,
  - `blockingIssueCount`,
  - `actionableMissingTradeEventCount`,
  - `ignoredFailedTransactionTradeCandidateCount`,
  - `duplicateDecodedEventTradeCount`,
  - `multiTradeSignaturePairCount`,
  - `duplicateCandleBucketCount`.
- Correction de l’agrégation des trades Raydium via extraction instruction-scoped des transferts SPL Token depuis `meta.innerInstructions`.
- Correction des cas CPMM contenant plusieurs swaps dans une même transaction, sans mélange des montants entre instructions.
- Conservation des transactions échouées comme événements décodés traçables, sans génération de `k_sol_trade_events`.
- Clarification des compteurs de replay :
  - `pairCandleUpsertCount`,
  - `analyticSignalUpsertCount`.
- Validation :
  - aucun trade candidate issu d’une transaction OK n’est perdu,
  - aucun trade event invalide n’est persisté,
  - aucun doublon réel par `decoded_event_id`,
  - aucune candle dupliquée par bucket,
  - aucune paire sans trade ni candle après replay,
  - seuls les trade candidates issus de transactions échouées restent ignorés.

### 6.059. Version `0.7.27` — Validation multi-DEX des connecteurs déjà branchés
Objectif : verrouiller la non-régression du pipeline actuel avant d’ajouter de nouveaux DEX ou d’ouvrir la phase d’analyse `0.8.x`.

Réalisé / validé :

- replay local et bases neuves de test utilisés pour stabiliser `pump_fun`, `pump_swap`, `raydium_cpmm` et `raydium_clmm` ;
- aucun nouveau DEX ajouté dans cette étape : la version a bien servi de verrou de non-régression ;
- vérification du triptyque `decoded_event_count / trade_event_count / pair_candle_count` par DEX ;
- garde-fous maintenus sur `diagnosticsClean`, `blockingIssueCount`, `actionableMissingTradeEventCount`, `duplicateDecodedEventTradeCount` et `duplicateCandleBucketCount` ;
- refus des trades sans montant ou prix exploitable ;
- conservation des transactions échouées comme decoded events traçables sans produire de `k_sol_trade_events` ;
- maintien des champs d’enrichissement dans `payload_json` : `eventCategory`, `tradeCandidate`, `candleCandidate`, `liquidityCandidate`, `feeCandidate`, `rewardCandidate`, `adminCandidate`, `poolLifecycleCandidate` ;
- couverture testée dans les zones critiques : `dex_decode`, `dex_detect`, `trade_aggregation`, `pair_candle_aggregation`, `pair_analytic_signal`, `local_pipeline_replay`, `local_pipeline_diagnostics` ;
- requêtes SQL de diagnostic conservées comme contrôle manuel après backfill ou replay local.

### 6.060. Version `0.7.28` — Refactor DEX commun et préparation extension
Réalisé :

- ne pas toucher à `ws_client.rs`, `ws_manager.rs`, `http_client.rs`, `http_pool.rs` ni aux couches JSON-RPC déjà stabilisées,
- extraire depuis `dex_decode.rs` les catégories communes d’événements : trade, candle candidate, liquidity candidate, fee candidate, reward candidate, admin candidate, pool lifecycle candidate,
- créer une représentation interne documentée pour les familles d’événements DEX afin d’éviter les chaînes dispersées dans plusieurs fichiers,
- clarifier la différence entre événement décodé, événement actionnable, trade candidate, candle candidate et événement conservé seulement pour analyse,
- simplifier `dex_decode.rs` en gardant son rôle de service de persistance-orchestration,
- simplifier `dex_detect.rs` en extrayant les helpers communs pool/pair/listing/origin/wallet quand cela réduit la duplication,
- homogénéiser les contrats des modules `kb_lib/src/dex/*.rs` sans imposer trop tôt un trait générique lourd,
- vérifier la rustdoc publique : utile, courte, orientée responsabilité ; supprimer la documentation redondante ou trop chargée,
- conserver les tests verts et ajouter des tests de non-régression sur les catégories d’événements existantes.

Contraintes :

- refactor agressif autorisé si le résultat est plus propre,
- chaque changement doit rester rejouable et testable,
- aucun changement de comportement métier volontaire dans cette version,
- aucun événement non price-action ne doit devenir un trade ou une candle.

### 6.061. Version `0.7.29` — Matrice DEX commune et validation baseline
Réalisé :

- ajouter `kb_lib/src/dex_support_matrix.rs` comme source commune de metadata DEX/surfaces ;
- exposer pour chaque entrée : code interne, famille, version, type de surface, program id connu ou à vérifier, support actuel, statut, confiance, raisons de skip et activation catalogue ;
- raccorder `dex_catalog`, `transaction_classification` et `protocol_candidate_recording` à cette matrice ;
- ajouter le profil `0.7.29_multi_dex_matrix_baseline` ;
- exposer la matrice dans le rapport de validation local ;
- conserver explicitement le comportement `0.7.28` : transactions failed traçables mais non actionnables, et `meteora_damm_v1.swap` sans payload montant/prix non candidat trade/candle.

Matrice cible initiale :

| Code cible | Type | Statut `0.7.29` | Objectif immédiat |
|---|---:|---|---|
| `pump_fun` | launch + bonding curve | partiel | rattacher mint initial, bonding curve et migration |
| `pump_swap` | AMM / swap | supporté | conserver trades/candles |
| `raydium_cpmm` | AMM | supporté | conserver trades/candles |
| `raydium_clmm` | CLMM | supporté | conserver trades/candles |
| `raydium_launchpad` | launch surface | planifié, program id local connu | ajouter decoder/materialization dédiée |
| `raydium_amm_v4` | AMM legacy | partiel | corpus dédié après autres Raydium |
| `raydium_router` | router | partiel | ne pas matérialiser en trade direct avant preuve |
| `raydium_stable_swap` | AMM legacy | supporté / 0.7.52 clos | swaps depuis deltas vault exacts ; failed tx decoded-only |
| `meteora_dlmm` | DLMM | supporté | verrouiller corpus et non-régression |
| `meteora_damm_v1` | AMM legacy | partiel | garder skip explicite sans payload montant/prix |
| `meteora_damm_v2` | AMM | partiel | corpus et séparation events |
| `meteora_dbc` | launch / bonding curve | partiel | lifecycle, migration, swaps utiles |
| `meteora_dlc` | à vérifier | à vérifier | confirmer surface/program id avant intégration |
| `orca_whirlpools` | CLMM | partiel | validation par corpus |
| `fluxbeam` | AMM | partiel | validation par corpus |
| `dexlab` | AMM | partiel | validation par corpus |
| `bags` | launch surface | planifié | attribution fiable, migration si prouvée |
| `letsbonk` / `bonk` | launch surface | planifié | origine mint/lancement, sans supposer un AMM autonome |
| `okx_dex` | aggregator/router | planifié | classifier sans trade direct avant preuve |
| `boop_fun` | launch surface | planifié | origine mint/lancement/migration |
| `moonshot` / `moonit` | launch surface | planifié | corpus, éviter heuristique faible |
| `believe` | launch surface | planifié | confirmer comptes et migrations |
| `heaven` | launch + AMM candidat | planifié | corpus et séparation launch/swap |
| `zora` | à vérifier | à vérifier | hors phasage actif avant preuve Solana |

### 6.062. Version `0.7.30` — Classification fine des événements DEX décodés
Réalisé :

- ajouter `DexEventLifecycleKind` pour distinguer `trade_swap`, `pool_creation`, `pair_creation`, `liquidity_add`, `liquidity_remove`, `position_open`, `position_close`, `migration`, `launch`, `mint`, `burn`, `fee_collection`, `reward`, `admin_config` et `unknown`,
- ajouter `DexEventActionability` pour distinguer `trade_candidate`, `non_actionable_trade`, `non_trade_useful`, `failed_transaction`, `informational` et `unknown`,
- enrichir les payloads décodés avec `eventLifecycleKind`, `eventActionability` et `nonTradeUseful`,
- exposer les compteurs diagnostics `decodedNonTradeUsefulEventCount`, `decodedNonActionableTradeEventCount` et `decodedUnknownEventCount`,
- ajouter un résumé diagnostic par catégorie / lifecycle / actionability,
- ajouter le profil `0.7.30_non_trade_event_classification`,
- ne pas matérialiser encore les événements non-trade dans leurs tables dédiées.

### 6.063. Version `0.7.31` — Politique de matérialisation des failed transactions
Réalisé :

- empêcher `TradeAggregationService` de matérialiser une transaction dont `err_json` est renseigné ;
- conserver les événements DEX décodés des failed transactions pour audit et diagnostic ;
- réinitialiser les tables dérivées de marché pendant le replay local : `k_sol_trade_events`, `k_sol_pair_metrics`, `k_sol_pair_candles`, `k_sol_pair_analytic_signals` ;
- reconstruire ensuite les trades/candles uniquement à partir des événements `tradeCandidate=true` et de transactions OK ;
- exposer `resetMarketMaterializationDeletedCount` dans le résultat de replay UI ;
- conserver la validation multi-DEX et la matrice DEX comme garde-fous avant d’ajouter les surfaces restantes.

### 6.064. Version `0.7.32` — Sémantique des diagnostics et compteurs de validation
Réalisé :

- conserver la politique `0.7.31` : transactions failed traçables mais exclues des `trade_events`, metrics et candles ;
- clarifier que `pairWithoutTradeCount` et `pairWithoutCandleCount` sont des compteurs de gaps bloquants/actionnables, pas des compteurs littéraux sur tout le catalogue ;
- ajouter `literalPairWithoutTradeCount` et `literalPairWithoutCandleCount` pour les paires de catalogue sans trade/candle matérialisé ;
- ajouter `blockingPairWithoutTradeCount` et `blockingPairWithoutCandleCount` comme noms explicites des anciens compteurs bloquants ;
- ajouter les compteurs de matérialisation par paire : `tradeMaterializedPairCount`, `candleMaterializedPairCount`, `actionablePairCount`, `candleBucketTimeframeCount` et `candlesAreBucketed` ;
- ajouter `pairActionabilitySummaries` pour distinguer les paires matérialisées, actionnables sans matérialisation, candidates failed, non-actionables, décodées sans trade candidate et catalog-only ;
- ajouter le profil `0.7.32_validation_report_semantics` ;
- ajouter des garde-fous de validation sur la matrice DEX : entrées `supported` entièrement matérialisées, entrées `partial` avec `skipReason`, entrées `planned/to_verify` non activées au catalogue ;
- ne pas modifier la logique de replay, trade aggregation ou candle aggregation validée en `0.7.31`.

Repoussé après cette clarification : consolider les transactions inconnues et protocol candidates sans polluer les trades/candles.

### 6.065. Version `0.7.33` — Readiness trading des paires
Réalisé :

- ajouter une classification diagnostique `pairTradingReadiness` pour chaque paire inspectée localement ;
- distinguer `direct_wsol_quote`, `direct_stable_quote`, `inverse_wsol_base`, `inverse_stable_base`, `cross_quote_requires_router`, `unknown_quote` et `non_trade_materialized` ;
- exposer `quoteAssetClass` et `tradingRouteRequired` dans les diagnostics par paire ;
- ajouter `pairTradingReadinessSummaries` dans le résumé local du pipeline ;
- ajouter le profil `0.7.33_pair_trading_readiness` ;
- valider que les résumés de readiness couvrent toutes les paires et restent cohérents avec les compteurs `tradeMaterializedPairCount`, `tradeEventCount` et `pairCandleCount` ;
- ne pas modifier la logique de replay, `trade_events`, metrics ou candles.

Objectif : préparer la future couche d’achat/vente en distinguant les paires immédiatement exploitables contre WSOL/stable des paires qui nécessitent inversion de lecture ou routeur/aggregator.

### 6.066. Version `0.7.34` — Événements non-trade v1 : liquidité et cycle de vie pool
Réalisé :

- stabiliser et étendre `k_sol_liquidity_events` au lieu de la recréer inutilement,
- ajouter `k_sol_pool_lifecycle_events`,
- matérialiser les événements `initialize`, `create_pool`, `migrate`, `open_position`, `close_position`, `increase_liquidity`, `decrease_liquidity`, `add_liquidity`, `remove_liquidity` et assimilés,
- rattacher chaque événement à `dex_id`, `pool_id`, `pair_id`, `transaction_id`, `decoded_event_id`, `signature` et `slot` lorsque les informations existent,
- conserver le `payload_json` source pour audit,
- alimenter les diagnostics locaux avec les compteurs liquidité/lifecycle,
- garantir qu’un événement de liquidité ou de cycle de vie ne produit jamais de candle directement.

### 6.067. Version `0.7.35` — Événements non-trade v2 : fees, rewards et administration
Objectif : conserver les événements utiles au risque, au scoring, à l’économie du pool et à la traçabilité opérationnelle.

Réalisé :

- ajout des tables `k_sol_fee_events`, `k_sol_reward_events` et `k_sol_pool_admin_events` ;
- ajout des DTO, entities, requêtes, index et re-exports associés ;
- matérialisation contrôlée des événements fees/rewards/admin lorsque la classification et les comptes le permettent ;
- rattachement aux transactions, decoded events, pools et paires lorsque les données disponibles sont fiables ;
- raccordement aux diagnostics locaux via `feeEventCount`, `rewardEventCount` et `poolAdminEventCount` ;
- ajout du profil `0.7.35_non_trade_fee_reward_admin` ;
- invariant maintenu : aucun fee/reward/admin ne produit de trade, metric ou candle.

Limite connue : le corpus local `0.7.38` ne contient pas encore d’événements fee/reward/admin matérialisés ; les compteurs peuvent donc rester à zéro sans bloquer la validation.

### 6.068. Version `0.7.36` — Meteora : DBC / DAMM v1 / DAMM v2 / DLMM
Réalisé :

- consolidation de Meteora comme famille multi-programmes au lieu de traiter `DBC`, `DAMM v1`, `DAMM v2` et `DLMM` comme des cas isolés ;
- ajout/correction des discriminants et classifications utiles pour `meteora_damm_v2`, `meteora_dbc`, `meteora_damm_v1` et `meteora_dlmm` ;
- correction du cas `meteora_damm_v2` où la classification de data était appelée depuis le mauvais scope ;
- ajout de garde-fous sur les fixtures et les instructions internes afin d’éviter les faux positifs ;
- validation du profil `0.7.36_meteora_family_consolidation` sur corpus local mixte ;
- conservation de `meteora_damm_v2.swap` et `meteora_dbc.swap` sans payload montant/prix fiable comme `non_actionable_trade` ;
- suppression des faux diagnostics bloquants liés aux swaps Meteora sans amounts : `missingTradeEventCount = 0`, `decodedTradeCandidateWithoutTradeEventCount = 0`, `decodedTradeCandidateWithoutAmountPayloadCount = 0` ;
- maintien de l’invariant : aucun événement sans montant/prix exploitable ne peut alimenter `trade_events`, `pair_metrics` ou `pair_candles` ;
- documentation de la limite connue : `meteora_damm_v2` et `meteora_dbc` peuvent être observés et décodés sans être encore matérialisables en trades/candles.

### 6.069. Version `0.7.37` — Token metadata et catalogue local
Objectif : rendre le catalogue local exploitable et lisible avant d’ajouter davantage de launch surfaces.

Réalisé :

- ajout du profil `0.7.37_token_metadata_catalog_enrichment` ;
- exposition des compteurs metadata/catalog dans les diagnostics et le rapport de validation : `tokenCount`, `tokenMetadataMissingCount`, `tradableTokenMetadataMissingCount`, `quoteTokenMetadataMissingCount`, `pairSymbolFallbackCount`, `pairSymbolResolvedCount`, `wsolQuotePairCount`, `stableQuotePairCount` ;
- raccordement UI Demo Pipeline 2 au profil `0.7.37` puis au profil `0.7.38` ;
- maintien volontaire du caractère non bloquant des metadata manquantes ;
- backfill metadata des tokens déjà présents dans `k_sol_tokens` sans nécessiter un nouveau backfill transactionnel ;
- enrichissement depuis les sources disponibles : registre local, payloads Pump.fun, comptes SPL/Token-2022, Metaplex lorsque le service dispose d’un `HttpEndpointPool` ;
- rafraîchissement des `pair_symbol` après enrichissement des tokens ;
- commande UI disponible via `Demo Pipeline 2 > Replay local > Refresh missing token metadata` avec limite dédiée ;
- idempotence attendue : le backfill metadata met à jour tokens et symboles de paires sans recréer pools, paires, trades, candles ou origins ;
- registre local minimal consolidé : `SOL`, `WSOL`, `USDC`, `USDT`.

Limite non bloquante : les diagnostics détaillés par origine de découverte restent une amélioration de confort ; l’étape `0.7.38` fournit déjà une liste priorisée exploitable via `tokenMetadataGapSamples`.

### 6.070. Version `0.7.38` — Priorisation des metadata manquantes
Objectif : transformer les compteurs metadata/catalog de `0.7.37` en liste d’action priorisée sans rendre les metadata manquantes bloquantes.

Réalisé :

- ajout du profil `0.7.38_token_metadata_gap_prioritization` ;
- exposition de `tokenMetadataGapSamples` dans les diagnostics locaux, la validation et les bindings Demo Pipeline 2 ;
- priorisation des tokens manquants par usage : `tradable_quote_missing_metadata`, `tradable_token_missing_metadata`, `quote_token_missing_metadata`, puis `catalog_token_missing_metadata` ;
- raccordement Demo Pipeline 2 au nouveau profil par défaut ;
- conservation de l’invariant : les metadata manquantes ne créent pas de blocking issue tant que les trades/candles actionnables restent sains ;
- validation locale confirmée avec `validationPassed = true`, `blockingIssueCount = 0`, `missingTradeEventCount = 0`, `decodedTradeCandidateWithoutTradeEventCount = 0` ;
- les samples permettent de sélectionner les prochains mints à enrichir via registre local, payloads DEX, Token-2022, Metaplex ou backfill HTTP.

Décision : `0.7.38` est clos. La clôture `0.7.38-B` conserve la logique de stable quotes limitée à `USDC`/`USDT` et ajoute un registre metadata local pour `JUP`, `RAY` et `BONK` sans les classer automatiquement comme quotes. La suite de développement commence à `0.7.39` avec une priorité DEX-first : consolider les DEX effectifs de swap avant de revenir aux launch surfaces.

### 6.071. Version `0.7.39` — Réorientation DEX-first et inventaire des DEX effectifs
Objectif : remplacer la priorité précédemment donnée aux launch surfaces par une consolidation des vrais DEX sur lesquels les swaps et événements de marché sont exécutés.

Réalisé :

- modification de la matrice DEX pour distinguer explicitement les rôles de surface : `dex_effective`, `aggregator_router`, `launch_surface`, `to_verify` ;
- suppression de l’alias ambigu `raydium` comme code DEX autonome ; `raydium` reste uniquement une famille, avec `raydium_amm_v4` comme surface legacy explicite ;
- ajout de `metaDAO` et `Printr` comme entrées `to_verify` sans `program_id` inventé ;
- conservation des DEX de swap principaux déjà connus dans la matrice : `pump_swap`, `raydium_cpmm`, `raydium_clmm`, `raydium_amm_v4`, `raydium_stable_swap`, `meteora_dlmm`, `meteora_damm_v1`, `meteora_damm_v2`, `meteora_dbc`, `orca_whirlpools`, `fluxbeam`, `dexlab` ;
- maintien des launch surfaces comme surfaces reportées et non prioritaires ;
- ajout du profil `0.7.39_dex_first_effective_swap_surfaces` ;
- validation locale confirmée avec `validationPassed = true`, `blockingIssueCount = 0`, `actionableMissingTradeEventCount = 0` et `missingTradeEventCount = 0` ;
- confirmation par corpus local initial que Raydium CLMM est observé ; les tranches ultérieures ont ensuite clôturé Raydium AMM v4 en `0.7.51` et Stable Swap en `0.7.52`.

Décision : `0.7.39` est clos. La suite immédiate ne doit pas commencer par un décodeur Raydium AMM v4 sans corpus. Il faut d’abord ajouter les outils de découverte on-chain et de backfill ciblé afin d’obtenir des signatures, pools/state accounts, token mints et instructions exploitables.

### 6.072. Version `0.7.40` — Demo3 on-chain discovery et backfill par signature
Objectif : ajouter les outils de constitution de corpus nécessaires avant de consolider les décodeurs DEX incomplets.

Réalisé :

- ajout de `Demo3` dans `kb_demo_app` pour rechercher on-chain à partir d’un `dex_code` et/ou d’un `program_id` ;
- utilisation de la chaîne `getSignaturesForAddress(program_id)` puis `getTransaction(signature)` pour récupérer des transactions récentes liées à un programme DEX ;
- extraction générique, indépendante des décodeurs DEX existants, de preuves on-chain : `observedTokenMints`, `tokenBalanceDeltas`, `candidatePoolAccounts`, `candidateTokenVaultAccounts` et `candidateProgramAccounts` ;
- distinction explicite entre `verifiedPoolAddress` et comptes candidats : un compte candidat n’est pas promu en pool vérifié sans décodage/layout/corpus fiable ;
- conservation de `metaDAO` et `Printr` comme surfaces à vérifier sans `program_id` ;
- ajout du backfill par signature dans Demo Pipeline 2, en complément du backfill par token mint et pool address ;
- réutilisation du pipeline existant pour le backfill signature : résolution transactionnelle, projection `k_sol_chain_transactions` / `k_sol_chain_instructions`, décodage DEX existant, détection, matérialisation non-trade, trades, candles et classification ;
- validation pratique sur `raydium_amm_v4` : les signatures et inner instructions associées au programme `675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8` sont maintenant persistées et inspectables ;
- observation de patterns Raydium AMM v4 récurrents dans les instructions projetées : `accounts_json[1]` comme candidat pool/state, `accounts_json[2]` comme autorité Raydium AMM, `accounts_json[3]` et `accounts_json[4]` comme vaults candidats, avec les comptes utilisateur en fin d’instruction ;
- maintien des invariants : aucune transaction failed ne produit `trade_events`, metrics ou candles ; aucun candidat sans montants exploitables ne devient trade/candle ; aucun `program_id` n’est inventé.

Décision : `0.7.40` est clos. `Demo3` et Demo Pipeline 2 suffisent pour constituer le corpus nécessaire à la suite immédiate. `Demo4` est décalée à une version ultérieure, car la priorité est maintenant d’utiliser le corpus on-chain local pour consolider `raydium_amm_v4`.

### 6.073. Version `0.7.41` — Raydium AMM v4 swap decoder v1
Objectif : ajouter un premier décodeur fiable pour les swaps Raydium AMM v4 observés dans le corpus constitué avec Demo3 et Demo Pipeline 2.

Réalisé :

- ajout du décodeur `raydium_amm_v4.swap` pour les instructions de swap AMM v4 ;
- prise en charge des inner instructions dont `program_id = 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8`, notamment lorsqu’elles sont appelées via Jupiter ou un autre routeur top-level ;
- conservation dans le payload décodé des informations de routage utiles : `routeSource`, programme parent, `innerInstruction`, `instructionIndex`, `innerInstructionIndex` et comptes complets ;
- extraction des comptes selon les layouts observés : token program, pool/state, authority, vault A, vault B, comptes intermédiaires et comptes utilisateur lorsque disponibles ;
- dérivation des mints et montants via deltas SPL Token et transferts instruction-scoped, avec refus des cas sans payload exploitable ;
- production de `eventActionability = trade_candidate` uniquement lorsque les mints et montants sont exploitables ;
- matérialisation des pools, paires, listings, `trade_events`, metrics et candles uniquement pour les transactions OK ;
- maintien des transactions failed comme traçables mais sans `trade_events`, metrics ni candles ;
- ajout du profil `0.7.41_raydium_amm_v4_swap_decoder` dans la validation locale et dans Demo Pipeline 2 ;
- mise à jour de la matrice DEX : `raydium_amm_v4` passe en `observed = true`, `status = supported`, `confidence = high`, sans `skipReason` ;
- validation locale confirmée avec `validationPassed = true`, `blockingIssueCount = 0`, `warningCount = 0`, `actionableMissingTradeEventCount = 0`, `missingTradeEventCount = 0`, `decodedTradeCandidateWithoutAmountPayloadCount = 0` et `invalidTradeEventCount = 0`.

Résultat de corpus validé : `raydium_amm_v4` produit 58 decoded events, 58 trade candidates, 58 trade events, 11 pools/paires et 147 candles sur la base de test Raydium AMM v4. Les routes Jupiter ou routeurs top-level restent annotées comme sources de route, tandis que le decoded event métier est attribué au DEX effectif `raydium_amm_v4`.

Décision : `0.7.41` est clos. La suite immédiate est `0.7.42_raydium_family_consolidation` afin de verrouiller ensemble `raydium_cpmm`, `raydium_clmm`, `raydium_amm_v4` et les surfaces Raydium non encore matérialisées.

### 6.074. Version `0.7.42` — Raydium family consolidation
Objectif : verrouiller ensemble `raydium_cpmm`, `raydium_clmm` et `raydium_amm_v4` comme surfaces Raydium effectives supportées, avec swaps et premiers non-swaps prouvés.

Réalisé :

- ajout du profil `0.7.42_raydium_family_event_coverage` ;
- conservation audit des instructions Raydium non décodées en `raydium_*.instruction_audit`, non-actionnables, sans trade/candle ;
- enrichissement des audits avec comptes, data base58, discriminator hex, `instructionIndex`, `innerInstructionIndex`, programme parent et statut de transaction ;
- décodage du legacy CLMM `raydium_clmm.swap` en plus de `raydium_clmm.swap_v2` ;
- cleanup des audits remplacés : un audit d’instruction est supprimé lorsqu’un vrai événement est maintenant décodé pour la même instruction ;
- adaptation du backfill historique : `getTransaction` classé en requête HTTP lourde, retry/backoff et poursuite du backfill en cas d’erreur transitoire ;
- mapping des discriminators CLMM prouvés : `decrease_liquidity_v2`, `increase_liquidity_v2`, `open_position_with_token22_nft`, `close_position` ;
- mapping des discriminators CPMM prouvés : `initialize`, `withdraw`, `collect_creator_fee` ;
- matérialisation des événements non-trade Raydium prouvés dans les tables dédiées : `k_sol_liquidity_events`, `k_sol_pool_lifecycle_events`, `k_sol_fee_events` ;
- validation manuelle par SQL du corpus Raydium : swaps AMM v4/CLMM/CPMM matérialisés, `25` liquidity events, `1` lifecycle event, `2` fee events, aucune instruction Raydium orpheline ;
- conservation des non-swaps AMM v4 legacy en audit informatif : les discriminators AMM v4 restants ne sont pas promus sans preuve suffisante ;
- correction de validation rapide pour grosses bases SQLite afin d’éviter de charger les diagnostics détaillés par paire pendant la validation.

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. 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` — 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 dont le décodage DEX est déjà certifié pour la même version logique de decoder, tout en laissant les tables dérivées se reconstruire normalement.

Statut : implémenté en première tranche transaction-level.

Fait :

- ajout de `k_sol_dex_decode_replay_ledger` dans `kb_lib/src/db/schema.rs` ;
- stockage de `transaction_id`, `signature`, `decoder_scope`, `decoder_version`, `decode_status`, `certainty`, `event_count`, `distinct_token_mint_count`, `force_replay_required`, reason et timestamps ;
- ajout des entities/dtos/queries associées ;
- mise à jour des re-exports dans `kb_lib/src/db.rs` puis `kb_lib/src/lib.rs` ;
- intégration dans `local_pipeline_replay.rs` sans changer la sémantique trade/candle : le skip ne concerne que `DexDecodeService`, pas la détection, la matérialisation non-trade, les trades, candles, signaux analytiques ou classifications ;
- ajout de `skip_certified_dex_decode` et `force_decode_replay` dans `LocalPipelineReplayConfig` ;
- marquage `unsafe` des transactions multi-event ou avec plus de deux mints distincts dans les events décodés ;
- version logique initiale `dex_decode.v0.7.44.ledger1`, à incrémenter lorsqu’un decoder change de comportement.

Reste à faire plus tard :

- descendre le ledger au niveau instruction/program lorsque nécessaire ;
- ajouter un hash d’entrée transaction/instruction pour détecter les mutations de payload ;
- ajouter des filtres plus fins côté UI pour diagnostiquer les lignes ledger `unsafe` ;
- ajouter des diagnostics dédiés dans `local_pipeline_diagnostics`.

### 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, sans mélanger DAMM v1, DAMM v2 ou DBC.

Statut : clos sur le corpus DLMM local élargi.

Fait :

- constitution d’un corpus dédié `meteora_dlmm` via `Demo3`, backfill manuel des signatures anciennes du pool `HTvjzsfX3yU6BUodCjZ5vZkUrAxMDTrBs3CJaq43ashR`, puis backfill par pool address ;
- confirmation locale du programme DLMM observé `LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo` dans les transactions du corpus ;
- traitement du wrapper Anchor `anchor_self_cpi_log` `e445a52e51cb9a1d` ;
- mapping prouvé localement et par IDL/upstream Git des Anchor CPI swap events : `516ce3becdd00ac4` -> `Swap`, `2e7452d7941b544d` -> `Swap2Evt` ;
- enrichissement du payload `meteora_dlmm.swap` avec `anchorSwapEvent`, montants et fees CPI décodés ;
- cleanup conservatoire des audits Anchor CPI swap déjà couverts par un swap DLMM matérialisé ;
- ajout des events Anchor CPI non-swap DLMM observés : `lb_pair_create_event`, `add_liquidity_event`, `remove_liquidity_event`, `claim_fee_event`, `claim_reward_event` / `fund_reward_event` côté decoder, `position_create_event`, `position_close_event` ;
- promotion du discriminant direct `claim_fee2` vers `meteora_dlmm.claim_fee2` ;
- promotion de `close_position_if_empty` comme event de lifecycle/position close prouvé localement ;
- promotion de `remove_liquidity_by_range2`, `add_liquidity_by_strategy2` et `add_liquidity_by_weight` selon les layouts upstream Git et le corpus local ;
- matérialisation validée des families non-trade dans les tables dédiées, notamment `k_sol_liquidity_events`, `k_sol_pool_lifecycle_events` et `k_sol_fee_events` ;
- maintien du ledger replay avec `effective_event_count`, afin que les `.instruction_audit` informatifs ne rendent pas inutilement les transactions `unsafe` ;
- version logique finale du replay pour la tranche : `dex_decode.v0.7.45.dlmm_add_liquidity_strategies1` ;
- maintien de la règle : aucun nouveau `program_id` n’est vérifié sans corpus.

Validation locale finale observée sur la base DLMM dédiée :

| Indicateur | Valeur |
|---|---:|
| transactions rejouées | `3027` |
| trades matérialisés | `530` |
| liquidity events matérialisés | `15` |
| lifecycle events matérialisés | `6` |
| candles upsert | `2120` |
| audits DLMM résiduels | `2` |

Events DLMM observés après replay :

- `meteora_dlmm.swap` ;
- `meteora_dlmm.create_pool` ;
- `meteora_dlmm.lb_pair_create_event` ;
- `meteora_dlmm.initialize_bin_array` ;
- `meteora_dlmm.initialize_position` ;
- `meteora_dlmm.position_create_event` ;
- `meteora_dlmm.position_close_event` ;
- `meteora_dlmm.close_position_if_empty` ;
- `meteora_dlmm.add_liquidity_event` ;
- `meteora_dlmm.add_liquidity_by_strategy2` ;
- `meteora_dlmm.add_liquidity_by_weight` ;
- `meteora_dlmm.remove_liquidity_event` ;
- `meteora_dlmm.remove_liquidity` ;
- `meteora_dlmm.remove_liquidity_by_range2` ;
- `meteora_dlmm.claim_fee_event` ;
- `meteora_dlmm.claim_fee2`.

Limite conservée :

- `e445a52e51cb9a1d + e8abf2613a4d232d` reste en `meteora_dlmm.instruction_audit` avec `proofStatus = observed_local_corpus_anchor_self_cpi_log`, faute de mapping upstream Git/IDL confirmé. Ces deux audits ne sont pas promus et ne bloquent pas la clôture de `0.7.45`.

Décision : `0.7.45` est clos pour `meteora_dlmm`. La suite immédiate est `0.7.46 — Demo3 multi-target discovery enabled` sur `meteora_damm_v1` uniquement.

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

Tranche `0.7.46` engagée sur les audits `meteora_damm_v1` observés dans le corpus local et mappés contre upstream Git decoder source `meteora-pools-decoder`.

Events DAMM v1 ajoutés côté decoder :

- `meteora_damm_v1.create_pool` pour les créations constant-product avec config upstream Git `InitializePermissionlessConstantProductPoolWithConfig` et `InitializePermissionlessConstantProductPoolWithConfig2`, en plus des chemins legacy déjà présents ;
- `meteora_damm_v1.add_liquidity` pour `AddBalanceLiquidity`, `AddImbalanceLiquidity` et `BootstrapLiquidity` ;
- `meteora_damm_v1.remove_liquidity` pour `RemoveBalanceLiquidity` et `RemoveLiquiditySingleSide` ;
- `meteora_damm_v1.claim_fee` pour `ClaimFee` ;
- `meteora_damm_v1.create_lock_escrow` et `meteora_damm_v1.lock_liquidity` pour les instructions de verrouillage LP.

Discriminants DAMM v1 traités dans cette tranche :

| Discriminant | Mapping upstream Git | Event local | Statut |
|---|---|---|---|
| `07a68aabceabecf4` | `InitializePermissionlessConstantProductPoolWithConfig` | `meteora_damm_v1.create_pool` | observé dans corpus local |
| `3095dc823d0b09b2` | `InitializePermissionlessConstantProductPoolWithConfig2` | `meteora_damm_v1.create_pool` | observé dans corpus local |
| `856d2cb338ee7221` | `RemoveBalanceLiquidity` | `meteora_damm_v1.remove_liquidity` | observé dans corpus local |
| `a9204f8988e84689` | `ClaimFee` | `meteora_damm_v1.claim_fee` | observé dans corpus local |
| `3657a51345e3dae0` | `CreateLockEscrow` | `meteora_damm_v1.create_lock_escrow` | observé dans corpus local |
| `1513d02bed3eff57` | `Lock` | `meteora_damm_v1.lock_liquidity` | observé dans corpus local |

Discriminants DAMM v1 ajoutés au decoder pour complétude upstream Git, même s’ils devront rester soumis au corpus avant mention `verified_by_corpus` :

- `9118acc2db7d03be` — `InitializeCustomizablePermissionlessConstantProductPool` ;
- `a8e3323ebdab54b0` — `AddBalanceLiquidity` ;
- `4f237a54ad0f5dbf` — `AddImbalanceLiquidity` ;
- `04e4d747e1fd77ce` — `BootstrapLiquidity` ;
- `5454b142feb90afb` — `RemoveLiquiditySingleSide`.

Le replay passe à la version logique `dex_decode.v0.7.46.damm_v1_events1` afin de redécoder les transactions certifiées sous la version `0.7.45` quand la tranche DAMM v1 est rejouée.

Validation locale obtenue après replay :

- `meteora_damm_v1.instruction_audit` vide sur le corpus local DAMM v1 rejoué ;
- `meteora_damm_v1.claim_fee`, `create_pool`, `create_lock_escrow`, `lock_liquidity` et `remove_liquidity` matérialisés dans les tables non-trade attendues ;
- invariant maintenu : aucun event non-trade DAMM v1 ne produit de trade/candle ;
- `cargo test -p kb_lib` et `cargo clippy -p kb_lib --all-targets -- -D warnings` validés localement après correction du warning Clippy.

Correction Demo3 adossée à `0.7.46` :

- ajout d’un décodage léger instruction-scoped pour `meteora_damm_v1` dans `onchain_dex_pair_discovery`, sans écriture DB et sans promotion de nouveau `program_id` ;
- les discriminants DAMM v1 connus par upstream Git/corpus sont classés directement en `swap`, `create_pool`, `add_liquidity`, `remove_liquidity`, `claim_fee`, `create_lock_escrow` ou `lock_liquidity` ;
- le filtre `target_event` devient strict pour les surfaces explicites afin qu’un swap ne ressorte pas comme liquidity, et inversement, quand les logs de transaction sont mixtes ;
- `excludeSwaps` ne supprime plus toute une transaction mixte lorsqu’un `target_event` explicite est sélectionné, afin de permettre la découverte d’instructions non-swap dans des routes agrégées ;
- les cibles UI `create_lock_escrow` et `lock_liquidity` sont ajoutées pour faciliter les backfills via Demo Pipeline 2.

Aucun `program_id` Meteora Vault n’est promu comme vérifié sans corpus direct séparé.

### 6.079. Version `0.7.47` — Upstream Git Registry / DEX discovery preparation
Objectif : accélérer la découverte multi-DEX en indexant les `program_id`, discriminants d’instructions, discriminants d’events et noms d’instructions issus de dépôts Git externes de decoders Solana, sans les considérer vérifiés par défaut.

À faire :

- créer un registre `upstream_registry` dans `kb_lib`, sans dépendre d’un nom de dépôt particulier ;
- stocker pour chaque entrée : `source_repo`, `decoder_code`, `program_id`, famille, type de surface, instruction/event name, discriminator hex, longueur de discriminator, statut de preuve et notes ;
- utiliser les statuts génériques : `upstream_git_unverified`, `upstream_git_mapped_unverified`, `upstream_git_local_corpus_observed`, `upstream_git_local_corpus_materialized` ;
- exposer les entrées à Demo3 pour filtrer par decoder, famille, `program_id`, discriminant, instruction/event name ou statut ;
- permettre à Demo3 de rechercher `any_upstream_unverified` pour trouver des signatures candidates à backfiller ;
- ne produire aucun trade/candle/liquidity/fee/reward/admin automatique depuis le registre ;
- n’utiliser les entrées upstream Git que comme indices de découverte et d’audit tant qu’elles ne sont pas validées par Demo3 + backfill + replay + SQL ;
- garder `kb_demo_app` comme façade UI : toute logique de registry/mapping doit rester dans `kb_lib`.

Familles prioritaires à indexer en premier :

- DEX / AMM / CLMM / orderbook : `meteora_damm_v2`, `meteora_dbc`, `meteora_dlmm`, `meteora_vault`, `raydium_amm_v4`, `raydium_clmm`, `raydium_cpmm`, `raydium_launchpad`, `raydium_liquidity_locking`, `raydium_stable_swap`, `orca_whirlpools`, `fluxbeam`, `lifinity_v2`, `phoenix_v1`, `openbook_v2`, `stabble_stable_swap`, `stabble_weighted_swap`, `bonkswap`, `boop`, `moonshot`, `heaven`, `okx_dex`, `pancake_swap`, `vertigo`, `virtuals`, `wavebreak`, `onchain_labs_dex_v1`, `onchain_labs_dex_v2` ;
- agrégateurs / ordres / perps / lending utiles au routage ou à l’analyse : `jupiter_swap`, `jupiter_dca`, `jupiter_limit_order`, `jupiter_limit_order_2`, `jupiter_perpetuals`, `jupiter_lend`, `kamino_lending`, `kamino_vault`, `kamino_farms`, `kamino_limit_order`, `drift_v2`, `marginfi_v2`, `dflow_aggregator_v4`, `zeta` ;
- contexte transactionnel non DEX : `system_program`, `token_program`, `token_2022`, `associated_token_account`, `address_lookup_table`, `memo_program`, `stake_program`, `mpl_token_metadata`, `mpl_core`, `bubblegum`, `name_service`, `marinade_finance`, `solayer_restaking_program`, `swig`, `sharky`, `circle_message_transmitter_v2`, `circle_token_messenger_v2`.

Aucun de ces programmes ne doit être marqué `verified_by_corpus` uniquement parce qu’il existe dans un dépôt Git externe.


### 6.079B. Version `0.7.48-pre` — Event coverage et checkpoint DB

Objectif : éviter de limiter la matrice aux DEX/versions et imposer une couverture événementielle exhaustive avant la reprise DEX par DEX.

Statut : implémenté en micro-tranche DB/reporting, sans modifier les decoders ni la matérialisation marché.

Fait :

- maintien de `docs/DEX_EVENT_COVERAGE_MATRIX.md` en plus de `docs/DEX_DECODER_MATRIX.md` ;
- ajout de `k_sol_dex_event_coverage_entries` dans `kb_lib/src/db/schema.rs` ;
- ajout des entity/DTO/queries/re-exports associés ;
- ajout de `DexEventCoverageService` pour synchroniser les entrées du registre upstream Git vers la table de coverage ;
- refresh des compteurs `observed_count`, `materialized_count`, `trade_count`, `first_signature` et `last_signature` depuis les events décodés et les tables métier existantes ;
- inférence conservatoire de `event_family`, `expected_db_target` et `local_event_kind`, sans promotion de `program_id` ni validation métier automatique ;
- correction du refresh SQL pour rester compatible avec `sqlx::query` en SQL statique ;
- exposition des summaries de coverage dans `LocalPipelineDiagnosticSummaryDto` et `LocalPipelineValidationReportDto` ;
- ajout du profil de validation `0.7.48-pre_event_coverage_db_checkpoint`, avec synchronisation upstream préalable ;
- contrôle bloquant des trade candidates non matérialisés borné aux DEX Raydium attendus dans ce profil, afin que les DEX partiels hors scope restent diagnostiqués sans bloquer le checkpoint DB/reporting ;
- sélection du profil `0.7.48-pre` dans Demo Pipeline 2.

Reste à faire dans les tranches DEX :

- compléter la liste exhaustive des events/instructions/logs par DEX depuis Carbon, fnzero, IDL, Pinax, HODL Warden, OpenBook, Phoenix et Vybe ;
- inclure explicitement les familles non-trade : `burn`, `mint`, `transfer`, `account_create`, `account_close`, `wrap_sol`, `unwrap_sol`, `lock`, `unlock`, `vault_deposit`, `vault_withdraw`, `admin/config`, `fee`, `reward`, `launch`, `migration` ;
- ajouter plus tard `k_sol_token_transfer_events` et `k_sol_orderbook_events` quand le besoin métier est prouvé par plusieurs DEX ;
- ne pas créer de trade/candle depuis ces nouveaux chemins sans validation économique et corpus.


### 6.080. Version `0.7.48` — `raydium_cpmm` event coverage
Objectif : reprendre `raydium_cpmm` en premier, avant Meteora, avec une couverture complète des events listés depuis Carbon/fnzero/IDL.

À faire :

- utiliser `k_sol_dex_event_coverage_entries` comme ledger de couverture attendu/observé/matérialisé ;
- lister tous les discriminants/instructions/events CPMM depuis les sources upstream ;
- comparer avec les events déjà connus localement : swap, initialize, withdraw, collect_creator_fee et audits restants ;
- conserver les swaps matérialisés uniquement si les montants et le sens économique restent validés ;
- compléter les events non-trade CPMM en audit ou matérialisation existante uniquement avec corpus local ;
- vérifier par SQL que les non-trades ne produisent aucun trade/candle.

### 6.081. Version `0.7.49` — `raydium_clmm` event coverage
Objectif : clôturer `raydium_clmm` après CPMM.

Réalisé :

- couverture locale de `45` entrées CLMM ;
- `33` instructions spécialisées, observées et décodées ;
- matérialisation contrôlée de `25` entrées vers trade, liquidity, fee, reward, admin, lifecycle et orderbook ;
- ajout de `k_sol_orderbook_events` pour les limit orders CLMM ;
- suppression automatique des fallbacks `upstream_git.instruction_match` localement couverts ;
- préparation audit-only des 11 Anchor / `Program data` events non encore observés ;
- invariants validés : aucun faux trade/candle, aucune matérialisation sur transaction échouée, `raydium_clmm.instruction_audit` résiduel à zéro.

### 6.082. Version `0.7.50-pre-r2` — Raydium CPMM/CLMM coverage closure
Objectif : clôturer la vérification CPMM/CLMM après la tranche Launchpad, en comparant le code local avec Carbon, Solscan Program IDL et `sol-parser-sdk`, puis en supprimant les familles ambiguës restantes de la matrice coverage.

Réalisé : ajout des entrées `cpi_event` CPMM/CLMM (`e445a52e51cb9a1d`), ajout de `update_dynamic_fee_config` CLMM (`0707500802c784f0`), rattachement local des Program-data events CLMM (`swap_event`, `pool_created_event`, `liquidity_change_event`, `create_personal_position_event`, `config_change_event`, `collect_protocol_fee_event`, `update_reward_infos_event`) et ajout de `k_sol_token_account_events` pour les événements type `create_support_mint_associated`. Les familles `unknown` restantes sont remplacées par `cpi_transport`, `liquidity_calculation`, `liquidity_change`, `position_open`, `pool_create`, `admin_config` ou `account_create` selon le cas.

Point audit résolu : le discriminant CPMM local `40f4bc78a7e9690a` est codé comme `raydium_cpmm.anchor_idl_instruction` avec `event_family=idl_management` et `expected_db_target=k_sol_dex_decoded_events_only`. Les signatures Solscan montrent `IdlCreateAccount` / `IdlCloseAccount` sur le compte `anchor:idl`; cette entrée reste donc informative et ne doit pas produire trade, candle, liquidity, fee ou admin métier.

Décisions de clôture CLMM : `swap_event` et `swap_router_base_in` restent `decoded_events_only` pour éviter le double comptage avec les instructions `swap` / `swap_v2`; `liquidity_calculate_event` reste diagnostic ; `close_position` / `close_protocol_position` restent décodés mais non matérialisés tant que le corpus ne fournit pas un rattachement pool/pair fiable. La matérialisation liquidity tente désormais un contexte de secours via événements frères de la même transaction quand un event CLMM porte les montants mais pas directement le pool/pair.

Suite locale : rebrancher les bases CPMM/CLMM, rejouer `forceDexDecode=yes`, vérifier que les requêtes `unknown`, fallback upstream, audit résiduel et matérialisation attendue ne remontent plus que des cas explicitement `decoded_events_only` ou des transactions failed.

Rapport associé : `docs/reports/RAYDIUM_CPMM_CLMM_RECHECK_REPORT_0_7_50_PRE_R2.md`.

### 6.083. Version `0.7.51` — `raydium_amm_v4` event coverage
Objectif : hisser AMM v4 legacy au niveau de couverture CPMM/CLMM.

Réalisé : decoder maximal AMM v4 pour tous les discriminants officiels `00..11`, spécialisation des swaps (`swap_base_in`, `swap_base_out`, `swap_base_in_v2`, `swap_base_out_v2`), suppression du legacy `raydium_amm_v4.swap`, observation locale de tous les discriminants, matérialisation validée des familles trade, liquidity, lifecycle, fee, admin/config et orderbook, `pre_initialize` conservé comme lifecycle audit deprecated/partial, `simulate_info` conservé en decoded-only, gaps successful non matérialisés expliqués, et validation des invariants failed/non-swap/single-target.

### 6.084. Version `0.7.52` — `raydium_stable_swap` event coverage
Objectif : reprendre Raydium Stable comme tranche Raydium dédiée après AMM v4.

Réalisé : decoder legacy 1 octet, surface locale `00..0d`, matérialisation lifecycle/liquidity/admin/fee/orderbook selon contexte, swaps `swap_base_in/out` matérialisés uniquement depuis deltas vault exacts (`stable_swap_vault_balance_delta`), transactions failed decoded-only, invariants trade/candle propres.

### 6.085. Versions `0.7.53` à `0.7.137` — phasage par `program_id`
Objectif : reprendre la suite après `0.7.52 raydium_stable_swap` avec une règle stricte : **une version = un `program_id`**.

Les comptes non-programmes ne créent pas de tranche decoder autonome. `SOLSCAN_ACCOUNT_SOURCES` reste un inventaire de découverte et sera nettoyé après validation des surfaces.

#### Bloc Pump

| Version | Decoder / surface | Program id | Objectif |
|---:|---|---|---|
| `0.7.53` | `pump_swap` | `pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA` | Clos : `buy/sell/buy_exact_quote_in` depuis sources exactes, non-trades spécialisés, events Anchor audit-only. |
| `0.7.54` | `pump_fun` | `6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P` | **Clos** : decoder maximal local, trades directs et `trade_event` canonique, non-trades selon contexte, validations propres. |
| `0.7.55` | `pump_fees` | `pfeeUxB6jkeY1Hxd7CsFCAjcbHA9rWtchMGdZ6VojVZ` | Couvrir fee accounting/claim/config ; aucun trade/candle direct. |

#### Bloc Meteora

| Version | Decoder / surface | Program id | Objectif |
|---:|---|---|---|
| `0.7.56` | `meteora_dbc` | `dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN` | Compléter toutes les instructions/events DBC : launch/bonding, swap exploitable, migration, fees/admin/config. |
| `0.7.57` | `meteora_dlmm` | `LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo` | Parité upstream finale : swaps, bins, positions, liquidity, fees/rewards/admin. |
| `0.7.58` | `meteora_damm_v1` | `Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB` | Parité upstream finale : pools, swaps, liquidity, lock, fees/admin. |
| `0.7.59` | `meteora_damm_v2` | `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG` | Couverture complète : create/custom pools, swaps, liquidity, dynamic config, fees/admin. |
| `0.7.60` | `meteora_vault` | `24Uqj9JCLxUeoC3hGfh5W3s9FM9uCHDS2SG3LYwBpyTi` | Vault deposit/withdraw/fee/accounting ; pas de candle directe. |

#### Bloc programmes système / contexte transactionnel

| Version | Decoder / surface | Program id | Objectif |
|---:|---|---|---|
| `0.7.61` | `system_program` | `11111111111111111111111111111111` | Create/assign/transfer account ; side effects de contexte, pas de trade. |
| `0.7.62` | `spl_token` | `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA` | Transfer, mint, burn, close account, sync native ; base transversale pour deltas. |
| `0.7.63` | `spl_token_2022` | `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` | Transfers/extensions Token-2022, mint/burn/close, comptes et side effects. |
| `0.7.64` | `associated_token_account` | `ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL` | Création ATA, rattachement wallet/token/pool. |
| `0.7.65` | `compute_budget` | `ComputeBudget111111111111111111111111111111` | Budget/prioritization fee ; utile scoring/MEV, pas de trade. |
| `0.7.66` | `memo` | `MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr` | Mémo transactionnel et attribution éventuelle. |
| `0.7.67` | `address_lookup_table` | `AddressLookupTab1e1111111111111111111111111` | Résolution/diagnostic ALT si nécessaire. |
| `0.7.68` | `mpl_token_metadata` | `metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s` | Enrichissement token/NFT/mint metadata. |
| `0.7.69` | `mpl_core` | `CoREENxT6tW1HoK8ypY1SxRMZTcVPm7R94rH4PZNhX7d` | Contexte asset si présent dans corpus. |
| `0.7.70` | `bubblegum` | `BGUMAp9Gq7iTEuizy4pqaxsTyUCBK68MDfK752saRPUY` | Audit/contexte assets compressés, pas DEX. |

#### Bloc routers / aggregators

| Version | Decoder / surface | Program id | Objectif |
|---:|---|---|---|
| `0.7.71` | `raydium_routing` | `routeUGWgWzqBWFcrCfv8tritsqukccJPu3q5GPP3xS` | Route/legs Raydium ; éviter le double-count avec AMM/CLMM/CPMM/Stable. |
| `0.7.72` | `jupiter_swap_v6` | `JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4` | Route attribution, legs, no duplicate trade/candle. |
| `0.7.73` | `jupiter_swap_v4` | `JUP4Fb2cqiRUcaTHdrPC8h2gNsA2ETXiPDD33WcGuJB` | Audit/route only si corpus encore utile. |
| `0.7.74` | `dflow_aggregator_v4` | `DF1ow4tspfHX9JwWJsAb9epbkA8hmpSEAtxXy1V27QBH` | Route/intent/orderflow ; pas de double matérialisation. |
| `0.7.75` | `okx_dex` | `6m2CDdhRgxpH4WjvdzxAYbGxwdGUz5MziiL5jek2kBma` | Route attribution ; trades seulement si source exacte non doublonnée. |
| `0.7.76` | `onchain_labs_dex_v2` | `proVF4pMXVaYqmy4NjniPh4pqKNfMmsihgd4wdkCX3u` | Corpus d’abord ; classifier route vs DEX effectif. |
| `0.7.77` | `titan_router` | `T1TANpTeScyeqVzzgNViGDNrkQ6qHz9KrSBS4aNXvGT` | Audit route-only sauf preuve de trade direct non doublonné. |
| `0.7.78` | `sanctum_router` | `stkitrT1Uoy18Dk1fTrgPw8W6MVzoCfYoAFT4MLsmhq` | Route/liquid staking context ; pas de candle DEX directe. |

#### Bloc DEX avec IDL/code/source exploitable

| Version | Decoder / surface | Program id | Objectif |
|---:|---|---|---|
| `0.7.79` | `orca_whirlpools` | `whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc` | Swaps, pools, positions, liquidity, fees/rewards. |
| `0.7.80` | `stabble_stable_swap` | `swapNyd8XiQwJ6ianp9snpu4brUqFxadzvHebnAXjJZ` | Stable swap ; deltas exacts, liquidity/admin. |
| `0.7.81` | `stabble_weighted_swap` | `swapFpHZwjELNnjvThjajtiVmkz3yPQEHjLtka2fwHW` | Weighted swap, deltas exacts, liquidity/admin. |
| `0.7.82` | `stabble_clmm` | `6dMXqGZ3ga2dikrYS9ovDXgHGh5RUsb2RTUj6hrQXhk6` | CLMM Stabble si corpus utile. |
| `0.7.83` | `bonkswap` | `BSwp6bEBihVLdqJRKGgzjcGLHkcTuzmSo1TQkHepzH8p` | Swap/liquidity/non-trade. |
| `0.7.84` | `boop_fun` | `boop8hVGQGqehUK2iVEMEnMrL5RbjywRzHKBmBE7ry4` | Launch/swap/migration selon corpus. |
| `0.7.85` | `byreal_clmm` | `REALQqNEomY6cQGZJUGwywTBD2UmDT32rZcNnfxQ5N2` | CLMM ; corpus puis matérialisation contrôlée. |
| `0.7.86` | `fusionamm` | `fUSioN9YKKSa3CUC2YUc4tPkHJ5Y6XW1yz8y6F7qWz9` | AMM ; swaps/liquidity si corpus. |
| `0.7.87` | `goosefx_v1` | `GAMMA7meSFWaBXF25oSUgmGRwaW6sCMFLmBNiMSdbHVT` | DEX/AMM selon corpus. |
| `0.7.88` | `goosefx_v2` | `GFXsSL5sSaDfNFQUYsHekbWBW1TsFdjDYzACh62tEHxn` | DEX/AMM selon corpus. |
| `0.7.89` | `guac_swap` | `Gswppe6ERWKpUTXvRPfXdzHhiCyJvLadVvXGfdpBqcE1` | Swap/liquidity si corpus. |
| `0.7.90` | `hylo_exchange` | `HYEXCHtHkBagdStcJCp3xbbb9B7sdMdWXFNj6mdsG4hn` | Classer DEX/lending/stable selon IDL/corpus. |
| `0.7.91` | `printr` | `T8HsGYv7sMk3kTnyaRqZrbRPuntYzdh12evXBkprint` | Corpus d’abord ; surface launch/swap à confirmer. |
| `0.7.92` | `moonit` | `MoonCVVNZFSYkqNXP6bxHLPL6QQJiMagDL3qcqUQTrG` | Launch/migration/swap si prouvé. |
| `0.7.93` | `metadao_amm_v0_5` | `AMMJdEiCCa8mdugg6JPF7gFirmmxisTfDJoSNSUi5zDJ` | AMM futarchy ; corpus et price semantics. |
| `0.7.94` | `metadao_bid_wall` | `WALL8ucBuUyL46QYxwYJjidaFYhdvxUFrgvBxPshERx` | Order/bid-wall context ; pas de candle directe sans fill exact. |
| `0.7.95` | `metadao_launchpad` | `moontUzsdepotRGe5xsfip7vLPTJnVuafqdUWexVnPM` | Launch/ICO surface ; pas DEX effectif par défaut. |
| `0.7.96` | `vertigo` | `vrTGoBuy5rYSxAfV3jaRJWHH6nN9WK4NRExGxsk1bCJ` | Swap/launch selon corpus. |
| `0.7.97` | `virtuals` | `5U3EU2ubXtK84QcRjWVmYt9RaDyA8gKxdUrPFXmZyaki` | Launch/AMM à confirmer. |
| `0.7.98` | `wavebreak` | `waveQX2yP3H1pVU8djGvEHmYg8uamQ84AuyGtpsrXTF` | Corpus et rôle exact. |
| `0.7.99` | `woofi` | `WooFif76YGRNjk1pA8wCsN67aQsD9f9iLsz4NcJ1AVb` | Swap/route selon corpus. |
| `0.7.100` | `pancake_swap` | `HpNfyc2Saw7RKkQd8nEL4khUcuPhQ7WwY1B2qjx8jxFq` | DEX Solana à confirmer par corpus. |
| `0.7.101` | `gavel` | `srAMMzfVHVAtgSJc8iH6CfKzuWuUTzLHVCE81QU1rgi` | Corpus d’abord ; rôle exact à classer. |
| `0.7.102` | `heaven` | `HEAVENoP2qxoeuF8Dj2oT1GHEnu49U5mJYkdeC8BAX2o` | Launch/DEX selon corpus. |
| `0.7.103` | `lifinity_v2` | `2wT8Yq49kHgDzXuPxZSaeLaH1qbmGXtEyPy64bL7aD3c` | DEX legacy/actif à confirmer. |
| `0.7.104` | `moonshot` | `MoonCVVNZFSYkqNXP6bxHLPL6QQJiMagDL3qcqUQTrG` | À dédupliquer avec `moonit` si même program id. |
| `0.7.105` | `openbook_v2` | `opnb2LAfJYbRMAHHvqjCwQxanZn7ReEHp1k81EohpZb` | Audit/orderbook complet ; trade/candle seulement si fills exacts. |
| `0.7.106` | `phoenix_v1` | `PhoeNiXZ8ByJGLkxNfZRnkUfjvmuYqLR89jjFHGqdXY` | Audit-only complet avant toute matérialisation fill. |

#### Bloc probes / DEX sans IDL fiable / historiques

| Version | Decoder / surface | Program id | Objectif |
|---:|---|---|---|
| `0.7.107` | `alphaq` | `ALPHAQmeA7bjrVuccPsYPiCvsi428SNwte66Srvs4pHA` | Demo3 + corpus ; décider support ou abandon. |
| `0.7.108` | `aquifer` | `AQU1FRd7papthgdrwPTTq5JacJh8YtwEXaBfKU3bTz45` | Probe uniquement. |
| `0.7.109` | `bisonfi` | `BiSoNHVpsVZW2F7rx2eQ59yQwKxzU5NvBcmKshCSUypi` | Probe uniquement. |
| `0.7.110` | `dexlab` | `DSwpgjMvXhtGn6BsbqmacdBZyfLj6jSWf3HJpdJtmg6N` | Vérifier support partiel / corpus. |
| `0.7.111` | `fluxbeam` | `FLUXubRmkEi2q6K3Y9kBPg9248ggaZVsoSFhtJHSrm1X` | Vérifier support partiel / corpus. |
| `0.7.112` | `goonfi` | `goonERTdGsjnkZqWuVjs73BZ3Pb9qoCUdBUL17BnS5j` | Probe. |
| `0.7.113` | `goonfi_v2` | `goonuddtQRrWqqn5nFyczVKaie28f3kDkHWkHtURSLE` | Probe ; adresse à revérifier si erreur de taille. |
| `0.7.114` | `humidifi` | `9H6tua7jkLhdm3w8BvgpTn5LZNU7g4ZynDmCiNN3q6Rp` | Probe. |
| `0.7.115` | `obric_v2` | `obriQD1zbpyLz95G5n7nJe6a4DPjpFwa5XYPoNm113y` | Probe. |
| `0.7.116` | `ondo_global_market` | `XzTT4XB8m7sLD2xi6snefSasaswsKCxx5Tifjondogm` | Rôle marché/tokenized assets à confirmer. |
| `0.7.117` | `scorch` | `SCoRcH8c2dpjvcJD6FiPbCSQyQgu3PcUAWj2Xxx3mqn` | Probe. |
| `0.7.118` | `solfi` | `SoLFiHG9TfgtdUXUjWAxi3LtvYuFyDLVhBWxdMZxyCe` | Probe. |
| `0.7.119` | `solfi_v2` | `SV2EYYJyRz2YhfXwXnhNAevDEui5Q6yrfyo13WtupPF` | Probe. |
| `0.7.120` | `zerofi` | `ZERor4xhbUycZ6gb9ntrhqscUcZmAbQDjEAtCf4hbZY` | Probe. |
| `0.7.121` | `zora` | `zoRabwLGd5zXaV7Gxacppw8tcceXEiTrSKyNLSaSTUc` | Probe, pas de promotion sans corpus. |
| `0.7.122` | `1dex` | `DEXYosS6oEGvk8uCDayvwEZz4qEyDJRf9nFgYCaqPMTm` | Probe. |
| `0.7.123` | `aldrin_amm` | `AMM55ShdkoGRB5jVYPjWziwk8m5MpwyDgsMWHaMSQWH6` | Historique/probe. |
| `0.7.124` | `aldrin_amm_v2` | `CURVGoZn8zycx6FXwwevgBTB2gVvdbGTEpvMJDbgs2t4` | Historique/probe. |
| `0.7.125` | `crema_finance` | `CLMM9tUoggJu2wagPkkqs9eFG4BWhVBZWkP1qv3Sp7tR` | Historique/probe. |
| `0.7.126` | `cropper_finance` | `CTMAxxk34HjKWxQ3QLZK1HpaLXmBveao3ESePXbiyfzh` | Historique/probe. |
| `0.7.127` | `cropper_whirlpool` | `H8W3ctz92svYg6mkn1UtGfu2aQr2fnUFHM1RhScEtQDt` | Historique/probe. |
| `0.7.128` | `mercurial_stable_swap` | `MERLuDFBMmsHnsBPZw2sDQZHvXFMwp8EdjudcU2HKky` | Historique stable swap ; deltas exacts si support. |
| `0.7.129` | `saber_stable_swap` | `SSwpkEEcbUqx4vtoEByFjSkhKdCT862DNVb52nZg1UZ` | Historique stable swap. |
| `0.7.130` | `saros_amm` | `SSwapUtytfBdBn1b9NUGG6foMVPtcWgpRU32HToDUZr` | Historique/probe. |
| `0.7.131` | `step_finance_swap` | `SSwpMgqNDsyV7mAgN9ady4bDVu5ySjmmXejXvy2vLt1` | Historique/probe. |
| `0.7.132` | `stepn_dooar_swap` | `Dooar9JkhdZ7J3LHN3A7YCuoGRUggXhQaG4kijfLGU2j` | Historique/probe. |
| `0.7.133` | `raydium_amm_v2_legacy` | `RVKd61ztZW9GUwhRbbLoYVRE5Xf1B2tVscKqwZqXgEr` | Historique Raydium ; corpus d’abord. |
| `0.7.134` | `raydium_amm_v3_legacy` | `27haf8L6oxUeXrHrgEgsexjSY5hbVUWEmvv9Nyxg8vQv` | Historique Raydium ; ne pas confondre avec CLMM moderne. |
| `0.7.135` | `raydium_pool_v4_json_audit` | aucun `program_id` prouvé par le fichier seul | Vérifier `sol-parser-sdk/idls/raydium_pool_v4.json` après les surfaces documentées ; patch AMM v4 si amélioration, sinon clôture no-op. |

#### Nettoyage / consolidation

| Version | Scope | Objectif |
|---:|---|---|
| `0.7.136` | cleanup `SOLSCAN_ACCOUNT_SOURCES` | Retirer les doublons/promotions : les vrais programmes validés deviennent constantes + support matrix ; les comptes non-programmes restent contexte ou sont supprimés. |
| `0.7.137` | base neuve multi-programmes | Replay consolidé, coverage global, zéro faux trade/candle, diagnostics bloquants à zéro. |

Garde-fous constants : pas de faux trade, pas de fausse candle, pas de `program_id` fictif, pas de promotion sans corpus transactionnel local, pas de double matérialisation router/leg, pas de logique métier DEX profonde dans `kb_demo_app`.

### 6.091. 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` ;
- indicateurs graphiques optionnels comme Ichimoku / Kumo ;
- outils de sélection manuelle de points ABC et projection d’un point D selon des règles temps/prix explicites ;
- séparation stricte entre signaux analytiques observés, projections hypothétiques et décisions de trading.

### 6.083. Version `1.x.y` — Wallets, comptes et transferts
Objectif : préparer la couche d’action sans encore brancher l’achat/vente automatique.

À faire :

- gestion du répertoire wallets ;
- création de wallet/keypair ;
- chargement sécurisé des keypairs ;
- inspection des informations wallet ;
- transfert de fonds depuis cette wallet vers un autre account ;
- garde-fous d’affichage, confirmation et simulation ;
- préparation d’ordres et de swaps seulement après stabilisation des transferts de base.

### 6.084. 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.085. 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 stables à ne pas remanier dans la phase immédiate :

- `ws_client.rs`
- `ws_manager.rs`
- `http_client.rs`
- `http_pool.rs`
- `json_rpc_ws.rs`
- `solana_pubsub_ws.rs`

Modules ciblés par le refactor et la consolidation DEX :

- `dex.rs`
- `dex/*.rs`
- `dex_decode.rs`
- `dex_detect.rs`
- `trade_aggregation.rs`
- `pair_candle_aggregation.rs`
- `pair_analytic_signal.rs`
- `launch_origin.rs`
- `pool_origin.rs`
- `wallet_observation.rs`
- `wallet_holding_observation.rs`
- `token_metadata.rs`
- `local_pipeline_replay.rs`
- `local_pipeline_validation.rs`
- `local_pipeline_diagnostics.rs`

`local_pipeline_diagnostics.rs` est volontairement conservé comme outil temporaire de validation. Il pourra devenir obsolète ou être remplacé lorsque les tests DEX seront stabilisés. Il n’est pas prioritaire de le refactorer maintenant.

### 7.2. Base de données

Organisation de la couche DB à conserver :

- `db/schema.rs` : création des tables et index uniquement ; chaque table ou index reste dans une fonction dédiée,
- `db/entities/*` : entités proches des lignes persistées,
- `db/dtos/*` : DTOs applicatifs,
- `db/queries/*` : requêtes SQL regroupées par table ou usage,
- `db/queries/local_pipeline_diagnostics.rs` : requêtes de diagnostic local, utiles pendant la validation DEX.

`schema.rs` peut rester long tant qu’il reste strictement un fichier de schéma. Le split prioritaire concerne plutôt les responsabilités métier dans `dex_decode.rs`, `dex_detect.rs` et `trade_aggregation.rs`.

### 7.3. `kb_demo_app`
Responsabilités cibles :

- lancement Tauri,
- commandes UI,
- affichage des états et messages,
- réception des événements venant de `kb_lib`,
- fenêtres de démonstration / diagnostic isolées,
- inspection du pipeline persisté,
- `Demo3` pour la recherche de paires/pools par DEX ou `program_id`,
- `Demo4` pour les requêtes DEX Screener et la comparaison avec la base locale,
- `Demo10` pour le watcher WebSocket live DEX avec start/stop,
- affichage candles et futurs overlays analytiques.

`kb_demo_app` ne doit pas contenir de logique métier DEX profonde.

## 8. Ligne de conduite sur le `WsClient`
Le `WsClient` doit être conçu en plusieurs couches :

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.

## 10.5. Jalons `0.7.29`

Réalisé / à maintenir :

- matrice DEX commune dans `kb_lib/src/dex_support_matrix.rs` ;
- raccordement minimal du catalogue DEX à cette matrice ;
- raccordement des mappings program id -> protocole utilisés par la classification transactionnelle et les protocol candidates ;
- profil `0.7.29_multi_dex_matrix_baseline` ;
- exposition de la matrice dans le rapport de validation local ;
- aucune modification volontaire du comportement trade/candle validé en `0.7.28`.

Validé en `0.7.30` : classification fine des événements décodés via `eventLifecycleKind`, `eventActionability` et `nonTradeUseful`, avec diagnostics associés et sans changement volontaire sur les trades/candles.

À poursuivre après `0.7.31` : transactions inconnues/protocol candidates, puis matérialisation contrôlée des événements non-trade utiles, sans alimenter les trades/candles actionnables.

## 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 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 considérées acquises avant cette reprise :

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 ;
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.44` : ledger de décodage/replay et skip sûr — acquis ;
2. `0.7.45` : `meteora_dlmm` — clos ;
3. `0.7.46` : `meteora_damm_v1` — clos côté corpus local ;
4. `0.7.47` : Upstream Git Registry / DEX discovery preparation — acquis ;
5. `0.7.48-pre` : event coverage + DB model checkpoint — clos ;
6. `0.7.48` : `raydium_cpmm` — clos ;
7. `0.7.49` : `raydium_clmm` — clos ;
8. `0.7.50-pre-r2` : `raydium_launchpad` clos + re-vérification CPMM/CLMM ;
9. `0.7.51` : `raydium_amm_v4` — clos ;
10. `0.7.52` : `raydium_stable_swap` — clos ;
11. `0.7.53` : `pump_swap` / `pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA` — clos ;
12. `0.7.54` : `pump_fun` / `6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P` ;
13. `0.7.55` : `pump_fees` / `pfeeUxB6jkeY1Hxd7CsFCAjcbHA9rWtchMGdZ6VojVZ` ;
14. `0.7.56+` : appliquer le phasage strict “une version = un `program_id`” défini en section `6.085`.

Garde-fous constants :

- 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 ;
- pas de skip replay sur transaction/instruction ambiguë, multi-token ou multi-event sans preuve ledger.


### Demo3 discovery note

Demo3 supports multiple selected target surfaces in one scan. The UI serializes selected checkboxes into the existing `targetEvent` filter as comma-separated values, so the backend remains backward compatible with single-target requests.


### Demo3 paged / multi-source note

Demo3 discovery now supports multiple source addresses, `before` / `until` pagination cursors, per-address max pages and `newest_first` / `oldest_first` processing order. This is intended for targeted corpus construction from known pool/pair addresses, especially when the first signatures can be identified externally with an explorer and then replayed/backfilled through Demo Pipeline 2. External explorers remain discovery aids only; verification still requires local decoder corpus and DB replay.


### 0.7.46 — clôture DAMM v1 upstream Git coverage

La tranche DAMM v1 doit couvrir les instructions/events listés par upstream Git decoder source `meteora-pools-decoder`. Les surfaces non observées localement sont volontairement persistées avec `proofStatus=upstream_git_mapped_unverified`; elles restent à valider par signatures réelles, replay et requêtes SQL.

Après backfills ciblés, les surfaces `swap` et `add_balance_liquidity` sont confirmées par corpus local et ne doivent plus rester en `upstream_git_mapped_unverified`. Les deux `remove_liquidity` non matérialisés en table liquidity sont expliqués par l’absence de `pool_id/pair_id` local pour leurs pools, pas par un échec de décodage.

### 6.080B. Clôture `0.7.48` — `raydium_cpmm` event coverage

Statut : delta préparé.

Fait :

- inventaire des entrées `raydium_cpmm` depuis Carbon et fnzero/IDL ;
- mapping local spécialisé des instructions CPMM non-swap connues ;
- ajout du décodage Anchor self-CPI audit-only `lp_change_event` et `swap_event` ;
- mise à jour de `known_local_event_kind` pour que la coverage DB reflète la couverture locale CPMM ;
- conservation de `swap_event` comme audit-only pour éviter un doublon avec les trades matérialisés depuis `swap_base_input` / `swap_base_output` ;
- maintien des règles : non-trade = zéro trade/candle, failed transaction = audit-only, upstream Git/IDL = indice et non preuve métier.

Reste à exécuter localement après application du delta :

```bash
cargo fmt
cargo test -p kb_lib
cargo clippy -p kb_lib --all-targets -- -D warnings
```

Puis relancer la validation SQL `validation_sql/SQL_VALIDATION_RAYDIUM_CPMM_0_7_48.sql` sur la base de corpus CPMM.

Complément appliqué après constitution du corpus CPMM :

- auto-sync conservatoire de `k_sol_dex_event_coverage_entries` lors d'un refresh coverage si la base neuve ne contient encore aucune entrée coverage ;
- refresh coverage best-effort après backfill token, pool ou signature ;
- décodage des events `Program data:` CPMM sans sélecteur Anchor self-CPI pour `swap_event` et `lp_change_event` ;
- maintien de `swap_event` en decoded/audit-only pour ne jamais doubler les `trade_events` issus des instructions swap ;
- matérialisation liquidity possible pour `lp_change_event` lorsque le pool/pair local est connu, avec `changeType=0` comme add/deposit et `changeType=1` comme remove/withdraw ;
- aucun changement de règle trade/candle pour les swaps existants.


### Note 0.7.48-part2-fix2 — Raydium CPMM coverage finalization

La tranche CPMM reconnaît désormais tous les discriminants instruction-level listés par Carbon / Raydium CP-Swap côté classificateur local. `lp_change_event` est traité comme famille bidirectionnelle `liquidity`, avec sens add/remove résolu par `changeType`, et le refresh coverage est confirmé après replay local sans validation séparée.

### Note 0.7.48 final — Raydium CPMM

`0.7.48` est clôturable côté `raydium_cpmm`. Le decoder couvre les instructions/events CPMM listés par Carbon/fnzero/Raydium CP-Swap, avec matérialisation locale validée pour trades, liquidity, lifecycle, fees et admin/config. `swap_event` reste audit-only pour éviter les doublons avec `swap_base_input` / `swap_base_output`. Les side effects SPL Token / Token-2022 observés via Solscan (`burn`, `transfer`, `transferChecked`, `closeAccount`) restent hors decoder CPMM direct et alimenteront une réflexion transversale future.

La suite après `0.7.52 raydium_stable_swap` a été clôturée par `0.7.53 pump_swap`, puis continue avec le phasage strict “une version = un `program_id`”. `raydium_pool_v4.json` reste repoussé vers la fin comme audit conditionnel : source Git/IDL utile seulement si elle apporte une amélioration concrète à `raydium_amm_v4` ou prouve un nouveau scope par corpus local.

## Clôture `0.7.51` — Raydium AMM v4

La tranche `0.7.51 raydium_amm_v4` est clôturable côté code et corpus local AMM v4.

Résultats de validation :

- `cargo test -p kb_lib` : `405 passed`, `0 failed` ;
- `cargo clippy -p kb_lib --all-targets -- -D warnings` : OK ;
- dernier replay : `195 replayed`, `0 decode skipped`, `168 trades`, `7 liquidity`, `15 lifecycle`, `668 candle upserts`, `instructionObservations=2599`, `resetDeleted=1578` ;
- tous les discriminants AMM v4 `00..11` sont observés localement ;
- `raydium_amm_v4.swap` legacy, decoded sans coverage, instruction observations 8 octets, non-swap trade, failed tx trade et multi-target materialization sont vides ;
- `pre_initialize` est matérialisé comme lifecycle audit minimal pour les transactions successful, sans création de pair exploitable ;
- `migrate_to_open_book` est orderbook-only ;
- `simulate_info` reste decoded-only.

Décision `raydium_pool_v4` : ne pas ouvrir de decoder autonome dans cette tranche. La roadmap conserve uniquement une entrée conditionnelle :

- même program id/layout compatible AMM v4 : intégrer dans `raydium_amm_v4` ;
- autre program id/surface strategy/wrapper/farm/lending : future tranche dédiée après corpus ;
- IDL ambiguë sans corpus : rester en audit roadmap.

Le rapport de décision est `docs/reports/RAYDIUM_POOL_V4_DECISION_NOTE.md`.

La tranche `0.7.52 raydium_stable_swap` est clôturée et `0.7.53 pump_swap` est désormais clôturé également. L'audit `raydium_pool_v4.json` reste repoussé vers la fin du phasage, avant le nettoyage/consolidation, afin de ne pas bloquer les surfaces Pump/Meteora/système/routers/DEX documentés.

### Addendum final — `0.7.52 raydium_stable_swap`

Statut : **clôturé**.

Décision finale : `raydium_stable_swap` est le code local canonique pour le program id `5quBtoiQqxF9Jv6KYKctB59NT3gtJD2Y65kdnB1Uev3h`. Le decoder utilise un layout legacy 1 octet et couvre la surface localement observée `00..0d`.

Résultat de tranche :

- `initialize` matérialise le lifecycle quand le contexte est complet ;
- `init_model_data` reste decoded-only expliqué ;
- `update_model_data` matérialise `k_sol_pool_admin_events` ;
- `deposit` / `withdraw` matérialisent `k_sol_liquidity_events` ;
- `monitor_step` / `admin_cancel_orders` matérialisent `k_sol_orderbook_events` quand le contexte est complet ;
- `set_params` matérialise `k_sol_pool_admin_events` ;
- `withdraw_pnl` / `withdraw_srm` matérialisent `k_sol_fee_events` quand le contexte est complet ;
- `simulate_info` reste decoded-only ;
- `swap_base_in` / `swap_base_out` matérialisent trades/candles uniquement depuis `amountSource=stable_swap_vault_balance_delta` ;
- `stable_swap_instruction_bounds_only` reste decoded-only et ne matérialise pas de trade/candle ;
- les transactions failed restent decoded-only avec `failed_transaction`.

Validation finale :

```text
cargo test -p kb_lib -> 407 passed, 0 failed
cargo clippy -p kb_lib --all-targets -- -D warnings -> ok
```

Replay final observé :

```text
replayed=298, trades=290, liquidity=16, lifecycle=4, candle_upserts=1160,
instructionObservations=5317, catalog=40 tokens / 59 pools / 59 pairs
```

Clôture swap spécifique :

```text
swap_base_in  stable_swap_vault_balance_delta     success 171 decoded / 171 trades
swap_base_in  stable_swap_instruction_bounds_only  failed   27 decoded / 0 trades
swap_base_out stable_swap_vault_balance_delta     success   4 decoded / 4 trades
swap_base_out stable_swap_instruction_bounds_only  failed    2 decoded / 0 trades
```

SQL de validation : `validation_sql/SQL_VALIDATION_RAYDIUM_STABLE_SWAP_0_7_52.sql`.

Rapport : `docs/reports/RAYDIUM_STABLE_SWAP_EVENT_COVERAGE_REPORT.md`.

### Addendum — `0.7.53 pump_swap`

La reprise après `0.7.52 raydium_stable_swap` cible uniquement le program id `pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA`. Le decoder local `pump_swap` couvre désormais les discriminants d’instructions upstream connus : trades matérialisables (`buy`, `sell`), swap decoded-only provisoire (`buy_exact_quote_in` tant que les montants exacts ne sont pas prouvés), liquidity (`deposit`, `withdraw`), pool/config (`create_pool`, `create_config`, `update_fee_config`), creator/protocol fee paths, cashback/token incentives et volume accumulator. Les events Program-data associés sont conservés comme entrées de coverage explicites ; ils ne doivent pas créer de doublon trade si l’instruction locale matérialise déjà le swap effectif.

Delta post-replay : `toggle_cashback_enabled` est admin-only, `migrate_pool_coin_creator` est admin/config et l’index `k_sol_instruction_observations` nomme les discriminants PumpSwap observés. Les trois discriminants d’abord inconnus (`01214eb921432c5c`, `fbe0ab92a01a71e9`, `cfbdb247a77a44b4`) sont maintenant nommés : `transfer_creator_fees_to_pump_v2` et `update_buyback_config` sont confirmés par le raw Solscan IDL ; `set_reserved_fee_recipient` reste une entrée observée dans les logs locaux, probablement une instruction ancienne/supprimée ou non exposée dans ce raw.

Critères de fermeture : corpus Demo3/backfill/replay dédié, coverage `pump_swap` synchronisée, zéro fallback `upstream_git.instruction_match` pour les instructions couvertes localement, failed tx sans trade/candle, non-swap sans trade/candle, et SQL `validation_sql/SQL_VALIDATION_PUMP_SWAP_0_7_53.sql` vide sur les requêtes d’anomalies.