0.7.45

README.md

@@ -4,7 +4,7 @@
 
 `khadhroony-bobobot` est un workspace Rust destiné à la détection, au décodage, à l’analyse et, à terme, au trading semi-automatisé de tokens Solana.
 
-Ce document reflète le point de reprise `0.7.43-E5C`. La version Cargo reste `0.7.43`, mais le lot Meteora ouvert en `0.7.43` n’est pas considéré comme terminé. La priorité immédiate est maintenant de normaliser la roadmap DEX-first, d’ajouter un ledger de décodage/replay pour éviter les rescans inutiles, puis de reprendre les DEX un par un, variante par variante.
+Ce document reflète le point de reprise `0.7.43-E5C` et l’état de consolidation atteint après `0.7.45` pour `meteora_dlmm`. La version Cargo a évolué ensuite à `0.7.45` côté `kb_lib`. Le lot Meteora initialement ouvert en bloc a été redécoupé : `meteora_dlmm` est traité séparément, puis la suite reprend `meteora_damm_v1`, `meteora_damm_v2` et `meteora_dbc` un par un.
 
 ## 1. Objectif
 
@@ -90,7 +90,7 @@ Les surfaces suivantes existent dans le code, dans la matrice ou dans le corpus
 | `raydium_cpmm` | DEX effectif consolidé partiellement | Swaps et premiers events non-trade prouvés sur corpus antérieur. |
 | `raydium_clmm` | DEX effectif consolidé partiellement | Swaps v2/legacy, positions et liquidity events prouvés sur corpus antérieur. |
 | `raydium_amm_v4` | DEX effectif legacy | Swaps AMM v4 legacy matérialisés ; non-swaps legacy conservés en audit tant que le corpus ne permet pas une promotion fiable. |
-| `meteora_dlmm` | DEX effectif à reprendre séparément | Présent et observé ; events non-trade à normaliser. |
+| `meteora_dlmm` | DEX effectif consolidé en `0.7.45` | Swaps, Anchor CPI swap events, liquidity, positions, fees et lifecycle principaux validés par corpus local ; deux Anchor CPI audits résiduels `e8abf2613a4d232d` restent volontairement non mappés. |
 | `meteora_damm_v1` | DEX effectif à reprendre séparément | Swaps présents ; plusieurs events restent en audit ou non actionnables. |
 | `meteora_damm_v2` | DEX effectif à reprendre séparément | Swaps et create_pool observés ; nombreux audits à traiter. |
 | `meteora_dbc` | launch/bonding + DEX effectif partiel à reprendre séparément | Gros volume d’audits ; séparer bonding/launch, swap effectif et migration. |
@@ -112,6 +112,35 @@ Aucun `program_id`, DEX ou event ne doit être documenté comme vérifié sans p
 | `materialized` | L’event alimente une table métier dédiée : trade, liquidity, lifecycle, fee, reward, admin, mint/burn, etc. |
 | `verified_by_corpus` | Validé par requêtes SQL, signatures/corpus reproductibles et invariants de validation. |
 
+### 3.6. État validé de `meteora_dlmm` en `0.7.45`
+
+La tranche `0.7.45` clôt la normalisation séparée de `meteora_dlmm` sur le corpus DLMM élargi constitué via `Demo3`, backfill par signatures anciennes et backfill par pool address.
+
+Éléments validés :
+
+| Famille | Events DLMM couverts |
+|---|---|
+| Swaps | `swap`, `swap2`, `swap_exact_out` lorsque présents, avec enrichissement `anchorSwapEvent` pour `Swap` / `Swap2Evt`. |
+| Création / lifecycle | `create_pool`, `lb_pair_create_event`, `initialize_bin_array`, `initialize_position`. |
+| Positions | `position_create_event`, `position_close_event`, `close_position_if_empty`. |
+| Liquidité | `add_liquidity_event`, `add_liquidity_by_strategy2`, `add_liquidity_by_weight`, `remove_liquidity_event`, `remove_liquidity`, `remove_liquidity_by_range2`. |
+| Fees | `claim_fee_event`, `claim_fee2`. |
+| Rewards | Décodeurs Anchor CPI présents pour `claim_reward_event` / `fund_reward_event`, mais non observés dans le corpus final `0.7.45`. |
+
+Validation locale finale sur la base DLMM dédiée :
+
+| Indicateur | Valeur observée |
+|---|---:|
+| 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` |
+
+Les deux audits restants sont `e445a52e51cb9a1d + e8abf2613a4d232d`. Ils restent en `meteora_dlmm.instruction_audit`, car aucun mapping Carbon/IDL suffisamment fiable n’a été confirmé. Ils ne bloquent pas la clôture de `0.7.45`.
+
+
 ## 4. Matrice DEX : priorité révisée
 
 À partir du point de reprise `0.7.43-E5C`, la priorité est :
@@ -200,11 +229,11 @@ Le modèle actuel contient déjà notamment :
 - `k_sol_transaction_classifications` ;
 - `k_sol_protocol_candidates`.
 
-### 5.2. Prochaine évolution DB : ledger de décodage/replay
+### 5.2. Ledger de décodage/replay implémenté en `0.7.44`
 
-Le replay actuel peut retraiter trop largement les transactions déjà connues. La prochaine tranche DB doit ajouter une structure de suivi permettant de ne pas rescanner les events certains, sauf option explicite.
+Le replay local dispose maintenant de la table `k_sol_dex_decode_replay_ledger`. Elle permet de ne pas relancer l’étape `DexDecodeService` lorsqu’une transaction a déjà été décodée avec certitude pour la même version logique de decoder. Les étapes de détection, matérialisation non-trade, trades, candles et classifications restent rejouées afin de reconstruire les tables dérivées après reset.
 
-Objectifs :
+Objectifs maintenus :
 
 - mémoriser qu’une transaction/instruction a déjà été traitée par un decoder donné ;
 - stocker le statut de décodage : certain, partiel, inconnu, erreur, non-actionnable, multi-token ambigu ;
@@ -214,26 +243,23 @@ Objectifs :
 - ne pas skipper automatiquement les transactions multi-token, multi-pool ou multi-event ambiguës ;
 - conserver les failed transactions comme traçables mais non actionnables.
 
-Nom de table à décider dans la tranche DB, par exemple :
+Table actuelle :
 
-- `k_sol_decode_attempts` ; ou
-- `k_sol_replay_decode_ledger`.
+- `k_sol_dex_decode_replay_ledger`.
 
-Champs conceptuels attendus :
+Champs principaux :
 
 | Champ conceptuel | Rôle |
 |---|---|
 | `transaction_id` / `signature` | rattachement transactionnel stable |
-| `instruction_id` / `instruction_index` | granularité instruction si possible |
-| `program_id` | programme effectivement traité |
-| `protocol_name` | protocole/DEx résolu |
-| `decoder_code` | decoder logique utilisé |
+| `decoder_scope` | périmètre logique du decoder, actuellement `dex_decode.local_pipeline` |
 | `decoder_version` | version logique du decoder |
-| `decode_status` | certain, partial, unknown, failed, skipped, ambiguous |
-| `certainty` | niveau de confiance machine |
-| `event_count` | nombre d’events produits |
-| `payload_hash` / `instruction_hash` | détection de changement d’entrée |
-| `reason_code` / `error_json` | diagnostic sans panic |
+| `decode_status` | `decoded` ou `no_events` dans la première implémentation |
+| `certainty` | `sure` ou `unsafe` |
+| `event_count` | nombre total d’events persistés |
+| `distinct_token_mint_count` | garde-fou multi-token |
+| `force_replay_required` | indique que le décodage doit être relancé |
+| `status_reason` | diagnostic lisible sans panic |
 | `created_at` / `updated_at` | audit local |
 
 ## 6. Politique de replay
@@ -274,7 +300,7 @@ La priorité immédiate après le point de reprise `0.7.43-E5C` est :
 
 1. `0.7.43` : resynchronisation documentaire, normalisation DEX-first et gel du point de reprise ;
 2. `0.7.44` : ajout du ledger de décodage/replay et options de replay `force` / skip sûr ;
-3. `0.7.45` : reprise séparée de `meteora_dlmm` ;
+3. `0.7.45` : reprise séparée de `meteora_dlmm` — clôturée côté corpus DLMM actuel ;
 4. `0.7.46` : reprise séparée de `meteora_damm_v1` ;
 5. `0.7.47` : reprise séparée de `meteora_damm_v2` ;
 6. `0.7.48` : reprise séparée de `meteora_dbc` ;