This commit is contained in:
2026-06-19 10:29:17 +02:00
parent 319be14aa6
commit 58f9b36969
24 changed files with 6432 additions and 741 deletions

View File

@@ -1,9 +1,15 @@
<!-- file: docs/DEX_DECODER_MATRIX.md -->
# DEX Decoder Matrix — `khadhroony-bobobot` `0.7.56 meteora_dbc closed`
# DEX Decoder Matrix — `khadhroony-bobobot` `0.7.57 meteora_dlmm closed`
## Note `0.7.57 closed` — Meteora DLMM clôturé et suite discovery
La tranche `0.7.57` ferme `meteora_dlmm` / `LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo`. Elle remplace la couverture partielle historique `0.7.45` par un decoder local maximal aligné sur l'IDL locale, avec correction du discriminant `75c73e67068e1fcb` en `initialize_preset_parameter_v2`. Les résidus observés utiles ne restent plus en decoded-only.
La prochaine étape n'est pas un nouveau decoder direct, mais `0.7.58 demo4_program_surface_discovery` : affichage et scoring des contenus inconnus/non pris en compte, sans auto-materialization ni auto-promotion.
## Note `0.7.56 closed` — Meteora DBC clôturé, DLMM ensuite
La tranche `0.7.56` ferme `meteora_dbc` / `dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN` depuis l'IDL locale `idls/meteora_dbc.dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN.json`.
@@ -81,7 +87,7 @@ Cette matrice complète `kb_lib/src/dex_support_matrix.rs`. Elle documente **ce
| 8 | `pump_fun` | `supported / 0.7.54 closed` | Surface launch/bonding/migration Pump.fun couverte localement ; trades directs et `trade_event` canonique validés. | Ne rouvrir que pour bug prouvé ou changement externe. |
| 9 | `pump_fees` | `supported / 0.7.55 closed` | Surface fee/config/accounting couverte localement : `29` instructions, `20` events Anchor, fee/reward/admin/lifecycle, tests synthétiques Anchor IDL non observés, failed tx audit-only. | Aucun trade/candle direct ; conserver les deux discriminators Solscan hors IDL comme futures surfaces non observées. |
| 10 | `meteora_dbc` | `supported / closed 0.7.56` | Decoder local maximal : `28` instructions, `23` events Anchor, swaps `swap/swap2`, lifecycle/admin/fees, `k_sol_fee_event_amounts`, validation SQL propre. | Ne pas rouvrir sauf bug prouvé ; préserver la policy fee parent+legs et la recovery allowlistée. |
| 11 | `meteora_dlmm` | `next / 0.7.57 full decode` | Couverture partielle historique validée en `0.7.45`; IDL locale `76` instructions / `30` events Anchor. | Reprendre depuis base neuve : full decode, full materialization fiable, fees/rewards via `fee_event_amounts`, no double-count avec events Anchor. |
| 11 | `meteora_dlmm` | `supported / closed 0.7.57` | Decoder local maximal : `76` instructions IDL, `30` events Anchor, `12` accounts, correction `initialize_preset_parameter_v2`, swaps/exact-out, liquidity, bins, positions, lifecycle, fees/rewards, admin/config et orderbook. | Ne pas rouvrir sauf bug prouvé ; `swap_event/swap2_evt` restent lifecycle `swap_log`, pas trade ; préserver recovery fee/reward allowlistée. |
| 12 | `meteora_damm_v1` | `supported / 0.7.58 parity` | Couverture `0.7.46` : swap, create_pool, add/remove liquidity, claim_fee, create_lock_escrow, lock_liquidity. | Vérifier les surfaces upstream non observées ; améliorer rattachement pool/pair pour remove_liquidity non matérialisés ; revalidation stricte. |
| 13 | `meteora_damm_v2` | `partial / 0.7.59 planned` | `swap`, `instruction_audit`, registry/discriminants et corpus Demo3 existent. | Couvrir tous les events Carbon/source : create pool, liquidity, fees, dynamic config, admin ; déterminer actionability des swaps ; matérialiser si montants fiables. |
| 14 | `phoenix_v1` | `audit-only / 0.7.60 planned` | Decoder local audit-only ; `log_audit`, order place/cancel, withdraw ; parsing strict `0x0f`; events `Reduce`, `Place`, `TimeInForce` observés ; `trade_count=0`. | Terminer tous les events Git : `Fill`, `FillSummary`, `Fee`, `Evict`, `ExpiredOrder`, etc. ; ajouter counts/flags audit ; seulement ensuite étudier trade materialization. |
@@ -346,8 +352,14 @@ La tranche a été validée sur base SQLite dédiée : tous les discriminants `0
Validation finale : `446` tests, clippy OK, `480 replayed`, `264 trades`, `1 liquidity`, `122 lifecycle`, `1056 candles`, `89` parents fee DBC, `96` fee amount legs, invariants SQL propres.
## 0.7.57 — Meteora DLMM prochain
## 0.7.57 — Meteora DLMM clôturé
| Decoder | Program id | Statut | Source locale | Couverture attendue | Décision métier |
| Decoder | Program id | Statut | Source locale | Couverture finale | Décision métier |
|---|---|---|---|---|---|
| `meteora_dlmm` | `LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo` | `next / full decode + full materialization` | `idls/meteora_dlmm.LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo.json` | `76` instructions IDL + `30` events Anchor IDL | Swaps/exact-out, liquidity/bin/position, fees/rewards/admin/config, limit order events ; no duplicate trade/candle ; `fee_event_amounts` obligatoire pour fees. |
| `meteora_dlmm` | `LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo` | `supported / closed 0.7.57` | `idls/meteora_dlmm.LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo.json` | `76` instructions IDL, `30` events Anchor, `12` accounts, `initialize_preset_parameter_v2` ajouté depuis corpus local | Les 6 swaps instructionnels produisent seuls les trades/candles ; Anchor `swap_event/swap2_evt` = lifecycle `swap_log`; liquidity/bin/position/lifecycle/admin/orderbook/fee/reward matérialisés selon cible ; failed tx audit-only. |
Validation finale : `460` tests, clippy OK, `769 replayed`, `106 trades`, `664 liquidity`, `1107 lifecycle`, `424 candles`, `8062` instruction observations, catalogue `169/218/218`. Checks SQL bloquants propres.
### 0.7.57 pre.001 — Meteora DLMM
`meteora_dlmm` passe de tranche `next` à tranche ouverte `pre.001` : lIDL locale complète est inventoriée, tous les discriminants instruction/event sont classifiés localement, et les familles non prouvées restent decoded-only/audit-safe avec `skip*Reason`.

View File

@@ -1,6 +1,6 @@
<!-- file: docs/DEX_EVENT_COVERAGE_MATRIX.md -->
# DEX Event Coverage Matrix — `khadhroony-bobobot` `0.7.54 pump_fun closed`
# DEX Event Coverage Matrix — `khadhroony-bobobot` `0.7.57 meteora_dlmm closed`
Cette matrice complète `docs/DEX_DECODER_MATRIX.md` avec une lecture par familles d'événements. Elle ne remplace pas la preuve locale : une entrée Git/IDL reste un indice tant qu'elle n'est pas observée dans le corpus local puis validée par replay et SQL.
@@ -326,17 +326,28 @@ Programme : `dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN`. Source locale priorit
Validation finale DBC : `89` parents fee, `96` legs fee amount, aucun parent scalaire sans leg, aucun leg orphelin, aucun decoded event local sans coverage, aucun failed tx matérialisé, aucun multi-target, aucun non-swap vers trade/candle.
## 0.7.57 — Meteora DLMM à reprendre
## `0.7.57``meteora_dlmm` final coverage
Programme : `LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo`. Source locale : `idls/meteora_dlmm.LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo.json`.
Programme : `LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo`. Source locale : `idls/meteora_dlmm.LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo.json`. Surface finale : `76` instructions IDL, `30` events Anchor, `12` accounts, plus correction locale `initialize_preset_parameter_v2` (`75c73e67068e1fcb`) observée dans le corpus.
| Groupe | Entrées IDL | Famille | Cible DB attendue | Décision à valider |
Validation finale : `460` tests, clippy OK, `769` replayed, `106` trades, `664` liquidity, `1107` lifecycle, `424` candle upserts, `8062` instruction observations. Les checks decoded sans coverage, successful non-materialized, failed tx materialized, multi-target, non-swap trade/candle, fee scalar sans leg, orphan fee legs et coverage duplicates sont vides.
| Famille | Entrées DLMM | Statut `0.7.57` | Cible DB | Justification / règle |
|---|---|---|---|---|
| swaps | `swap`, `swap2`, `swap_exact_out*`, `swap_with_price_impact*`, `Swap`, `Swap2Evt` | swap | `k_sol_trade_events` + candles | Montants exécutés uniquement ; éviter double-count instruction/event. |
| pools / bins | `initialize_*lb_pair*`, `initialize_bin_array*`, `close_bin_array`, `LbPairCreate` | lifecycle | `k_sol_pool_lifecycle_events`, catalog/pair | Catalog si comptes pool/mints/config fiables. |
| liquidity / positions | `add_liquidity*`, `remove_liquidity*`, `remove_all_liquidity`, `rebalance_liquidity`, position create/close/update events | liquidity/lifecycle | `k_sol_liquidity_events`, `k_sol_pool_lifecycle_events` | Montants x/y/bin/liquidity fiables ; sinon skip reason. |
| fees | `claim_fee*`, `withdraw_protocol_fee`, `zap_protocol_fee`, `ClaimFee*`, `CompositionFee` | fee | `k_sol_fee_events` + `k_sol_fee_event_amounts` | Utiliser le socle fee parent+legs ; policy recovery explicite, non globale. |
| rewards | `initialize_reward`, `fund_reward`, `claim_reward*`, `withdraw_ineligible_reward`, reward events | reward | `k_sol_reward_events` | Montant/mint/récompense fiable uniquement. |
| admin/config | fee parameters, pair status, activation, operator, token badge, preset parameter | admin_config | `k_sol_pool_admin_events` ou decoded-only | Matérialiser si acteur/compte cible fiable. |
| limit/order events | place/cancel/close limit order events | orderbook/audit | `k_sol_orderbook_events` si modèle fiable | Pas de candle directe sans fill exact. |
| `swap` | `swap`, `swap2`, `swap_exact_out`, `swap_exact_out2`, `swap_with_price_impact`, `swap_with_price_impact2` | `materialized` | `k_sol_trade_events` + candles | Seules ces instructions produisent trade/candle direct quand montants/mints/pool sont fiables. |
| `swap_log` | `swap_event`, `swap2_evt` | `materialized` | `k_sol_pool_lifecycle_events` | Logs Anchor informatifs matérialisés sans double-count trade/candle. |
| `pool_create` | `create_pool`, `lb_pair_create_event`, `initialize_*_lb_pair*`, `initialize_permission_lb_pair` | `materialized` si observé, sinon `upstream_git_mapped_unverified` | `k_sol_pool_lifecycle_events` | Pool lifecycle ; pas de trade direct. |
| `liquidity_add` | `add_liquidity*`, `add_liquidity_event` | `materialized` | `k_sol_liquidity_events` | Montants/side effects liquidity ; aucun trade/candle. |
| `liquidity_remove` | `remove_liquidity*`, `remove_all_liquidity`, `remove_liquidity_event` | `materialized` | `k_sol_liquidity_events` | Retrait liquidity ; failed tx audit-only. |
| `liquidity_change` | `rebalance_liquidity`, `rebalancing_event` | `materialized` | `k_sol_liquidity_events` | Changement de liquidité/bin ; pas de trade. |
| `position_open` | `initialize_position*`, `position_create_event` | `materialized` | `k_sol_pool_lifecycle_events` | Position/bin lifecycle, pas liquidity artificielle quand l'opération est structurelle. |
| `position_close` | `close_position*`, `position_close_event` | `materialized` | `k_sol_pool_lifecycle_events` | Fermeture position lifecycle. |
| `position_update` | `increase_position_length*`, `decrease_position_length*`, `update_position_operator*`, position update events | `materialized` si observé | `k_sol_pool_lifecycle_events` | Mise à jour de position ; pas admin générique. |
| `bin/oracle lifecycle` | `initialize_bin_array*`, `close_bin_array`, `go_to_a_bin*`, `increase_oracle_length`, `migrate_bin_array` | `materialized` si observé | `k_sol_pool_lifecycle_events` | `close_bin_array` a `16/14` car `2` failed tx `Custom 6015`, comportement attendu. |
| `fee` | `claim_fee*`, `claim_fee*_event`, `composition_fee_event`, `withdraw_protocol_fee`, `zap_protocol_fee` | `materialized` | `k_sol_fee_events` + `k_sol_fee_event_amounts` | Recovery inner SPL transfer strictement allowlistée ; legs multi-mint conservés sans agrégation artificielle. |
| `reward` | `claim_reward*`, `claim_reward*_event`, `fund_reward*`, `initialize_reward*`, `withdraw_ineligible_reward*` | `materialized` si observé | `k_sol_reward_events` | Claims/funding avec amounts récupérés quand transfert réel ; `initialize_reward*` sans amount est normal. |
| `admin/config` | `update_base_fee_parameters`, `fee_parameter_update_event`, `set_pair_status*`, `set_activation_point`, `set_pre_activation*`, preset/token badge/operator/config, `initialize_preset_parameter_v2` | `materialized` si observé | `k_sol_pool_admin_events` | Admin/config non financier ; pas trade/candle. |
| `orderbook` | `place_limit_order*`, `cancel_limit_order*`, `close_limit_order*` | `materialized` | `k_sol_orderbook_events` | Limit/orderbook events sans trade/candle. |
| `account metadata` | `lb_pair`, `bin_array`, `position_v2`, `oracle`, `operator`, `token_badge`, etc. | `upstream_git_mapped_unverified` / non observé | `k_sol_dex_decoded_events_only` | Accounts IDL listés pour coverage, pas de matérialisation métier directe. |
| `instruction_audit` | résidu inconnu | `closed` | `k_sol_pool_admin_events` seulement si observé | Résidu final observé = `0`; `75c73e67068e1fcb` a été promu en `initialize_preset_parameter_v2`. |

View File

@@ -0,0 +1,73 @@
# Validation status — 0.7.57 Meteora DLMM final
## Build
```text
cargo test -p kb_lib -> 460 passed / 0 failed
cargo clippy -p kb_lib --all-targets -- -D warnings -> OK
```
## Replay
Recommended replay settings used:
```text
skipDexDecode=no
forceDexDecode=yes
deferInstructionObservations=yes
```
Final replay summary:
```text
769 replayed
0 decode skipped
769 ledger upserts
646 unsafe ledger rows
106 trades
664 liquidity
1107 lifecycle
0 tokenAccount
424 candle upserts
instructionObservations = 8062
resetDeleted = 9898
catalog = 169 tokens / 218 pools / 218 pairs
```
## Final SQL gates
| Gate | Result |
|---|---:|
| Upstream fallback for local DLMM coverage | empty |
| Local `instruction_audit` observed | `0` |
| Decoded DLMM without coverage | empty |
| Successful non-materialized without explicit skip/policy | empty |
| Failed transaction business materialization | empty |
| Multi-target materialization | empty |
| Non-swap trade/candle safety | empty |
| Fee parent scalar without amount leg | empty |
| Orphan fee amount legs | empty |
| Reward/fee collision | clean separation |
| Limit/orderbook trade/candle double-count | empty |
| Logical duplicate coverage rows | empty |
## Final materialization counters
```text
trade events = 106
liquidity events = 664
lifecycle events = 1107
candles = 424
```
## Important decisions
- `swap_event` and `swap2_evt` are materialized as lifecycle `swap_log`, not as trades.
- `initialize_preset_parameter_v2` was added from corpus evidence for discriminator `75c73e67068e1fcb`.
- `close_bin_array` has `16` observations but only `14` materializations because `2` transactions failed with `Custom 6015`.
- `initialize_reward` and `initialize_reward_event` remain without amounts because they are configuration/init events, not transfers.
- No observed useful DLMM event remains decoded-only.
## Closure decision
`0.7.57 meteora_dlmm` is considered closed for the validated corpus. Future changes require new corpus evidence.

View File

@@ -0,0 +1,245 @@
<!-- file: docs/prompts/prompt_name_0_7_58_demo4_program_surface_discovery.md -->
# Prompt — 0.7.58 Demo4 Program Surface Discovery
## Contexte
Nous reprenons le workspace Rust/Tauri `khadhroony-bobobot` après la clôture de `0.7.57 meteora_dlmm`.
État validé :
```text
0.7.57 meteora_dlmm clos
cargo test -p kb_lib -> 460 passed
cargo clippy -p kb_lib --all-targets -- -D warnings -> OK
replay -> 769 replayed, 106 trades, 664 liquidity, 1107 lifecycle, 424 candles
instructionObservations = 8062
catalogue = 169 tokens / 218 pools / 218 pairs
```
Contraintes projet à respecter :
- Rust 2024.
- Code async-first.
- Pas de `?`, `unwrap`, `expect` dans le code applicatif.
- Pas de `anyhow`, pas de `thiserror`.
- Pas de `mod.rs`.
- Pas de `pub mod` ; utiliser `mod` privé + `pub use`.
- Imports uniquement pour les traits quand cest possible.
- `#![deny(unreachable_pub)]` et `#![warn(missing_docs)]` doivent rester propres.
- Tests offline.
- Les nouvelles requêtes DB doivent mettre à jour les re-exports dans `kb_lib/src/db.rs` puis `kb_lib/src/lib.rs`.
- Les structs DB doivent aller dans `kb_lib/src/db/entities/*.rs` et `kb_lib/src/db/dtos/*.rs`, pas dans les fichiers de requêtes.
## Objectif
Ajouter `Demo4` dans `kb_demo_app` et les fonctions de lecture associées dans `kb_lib` pour afficher les surfaces de programmes non encore prises en compte par le système.
Cette fonctionnalité est strictement un cockpit de découverte et de revue.
Elle ne doit pas :
- matérialiser automatiquement des contenus inconnus ;
- promouvoir automatiquement des discriminators inconnus dans les décodeurs officiels ;
- marquer automatiquement un `program_id` comme supporté ;
- créer automatiquement des lignes `trade`, `candle`, `fee`, `liquidity`, `reward`, `admin` ou `orderbook` depuis un contenu inconnu.
Elle doit :
- afficher les surfaces inconnues ou non supportées ;
- les regrouper de manière exploitable ;
- montrer les preuves et signatures samples ;
- aider à produire des prompts/patchs futurs validés manuellement.
## Comportement attendu côté utilisateur
Créer une nouvelle page ou fenêtre, selon le pattern existant :
```text
kb_demo_app/src/demo4.html
kb_demo_app/src/demo4.ts
```
ou léquivalent si lapplication utilise un autre routage.
Demo4 doit proposer des vues pour :
1. discriminators inconnus sur des decoders connus ;
2. `program_id` connus contenant des instructions non mappées par le decoder spécialisé ;
3. `upstream_git.instruction_match` groupés par `upstreamDecoderCode`, `upstreamEntryName`, `upstreamDiscriminatorHex` ;
4. `program_id` observés dans les transactions mais absents de la matrice de support ;
5. logs Anchor `Program log: Instruction: ...` non mappés localement ;
6. events Anchor `Program data:` non mappés localement ;
7. layouts de comptes récurrents sur instructions inconnues ;
8. répartition success/failed pour chaque surface candidate.
Filtres souhaités :
```text
program_id
candidate_decoder_code
discriminator_hex
instruction_name / nom log Anchor
upstream decoder
upstream entry name
success only / failed only / both
minimum observation count
minimum tx count
from slot / to slot
signature contains
show only unknown
show only upstream fallback
show only high-confidence candidates
```
Colonnes souhaitées :
```text
candidate_kind
program_id
candidate_decoder
known/unknown status
discriminator_hex
log_instruction_name
anchor_event_discriminator
account_count
layout_hash
observed_count
tx_count
success_count
failed_count
first_slot
last_slot
sample_signature
confidence_score
confidence_reason
status
```
Le panneau de détail doit afficher :
```text
sample signatures
accounts_json
data_json / data prefix
logs de transaction
inner instructions
parsed_json si disponible
decoded_payload_json si disponible
entrées upstream registry correspondantes
preuve de hash Anchor si un nom dinstruction est disponible
```
## Design `kb_lib`
Ajouter des requêtes read-only et des DTOs. Fichiers suggérés :
```text
kb_lib/src/program_surface_discovery.rs
kb_lib/src/db/dtos/program_surface_candidate_summary.rs
kb_lib/src/db/dtos/program_surface_candidate_sample.rs
kb_lib/src/db/queries/program_surface_discovery.rs
```
Si un statut persistant est nécessaire, ajouter :
```text
kb_lib/src/db/entities/program_surface_candidate.rs
kb_lib/src/db/queries/program_surface_candidates.rs
```
Ne pas placer les DTO/entities dans les fichiers de requêtes.
Statuts candidats suggérés :
```text
new
reviewed
accepted
rejected
promoted
ignored
```
Si une table persistante est ajoutée, la migration doit être explicite, idempotente et testée.
## Scoring de découverte
Le scoring est indicatif uniquement. Il ne doit jamais déclencher une matérialisation.
Signaux de confiance possibles :
| Signal | Effet |
|---|---:|
| `program_id` connu, discriminator inconnu | +20 |
| log Anchor `Instruction: X` trouvé | +30 |
| `sha256("global:x")` correspond au discriminator | +50 |
| observations success répétées | +10 |
| account count/layout stable | +10 |
| inner instruction family cohérente avec laction | +10 |
| uniquement des transactions failed | -20 |
| nom très générique comme `swap`, `claim`, `initialize` sans autre preuve | -15 |
| `program_id` inconnu et observation unique | -25 |
## Helper Anchor
Ajouter un helper qui normalise les noms dinstructions Anchor depuis les logs :
```text
Program log: Instruction: InitializePresetParameterV2
-> initialize_preset_parameter_v2
-> sha256("global:initialize_preset_parameter_v2")[0..8]
```
Ce helper doit seulement produire une preuve/candidate record. Il ne doit pas modifier les mappings de decoder.
## Export Markdown
Demo4 doit permettre dexporter un groupe candidat en Markdown pour une future session dimplémentation.
Lexport doit inclure :
```text
candidate decoder
program_id
discriminator_hex
candidate name
confidence score
preuves/evidence
sample signatures
account layout
logs
inner instruction summary
proposed target table éventuelle
warning explicite : non implémenté, non matérialisé
```
## Tests
Ajouter des tests offline pour :
- normalisation des noms Anchor depuis logs ;
- calcul de discriminators Anchor pour des noms samples ;
- groupement par program/discriminator/layout ;
- ordre de score ;
- sérialisation/désérialisation des DTOs si utilisés ;
- validation des paramètres de commandes UI.
Aucun test ne doit dépendre de RPC ou du réseau.
## Validation
```bash
cargo fmt
cargo test -p kb_lib program_surface
cargo test -p kb_lib
cargo clippy -p kb_lib --all-targets -- -D warnings
```
Pour Tauri/frontend, lancer la commande de build/test existante du projet si elle existe.
## Résultat attendu
Lutilisateur peut ouvrir Demo4 et voir immédiatement les surfaces unsupported/upstream/unknown présentes dans la base SQLite courante, sans rescanner la blockchain.
Demo4 est un cockpit de découverte uniquement. Il ne change pas la matérialisation métier.

View File

@@ -0,0 +1,245 @@
<!-- file: docs/prompts/PROMPT_0_7_58_demo4_program_surface_discovery.md -->
# Prompt — 0.7.58 Demo4 Program Surface Discovery
## Contexte
Nous reprenons le workspace Rust/Tauri `khadhroony-bobobot` après la clôture de `0.7.57 meteora_dlmm`.
État validé :
```text
0.7.57 meteora_dlmm clos
cargo test -p kb_lib -> 460 passed
cargo clippy -p kb_lib --all-targets -- -D warnings -> OK
replay -> 769 replayed, 106 trades, 664 liquidity, 1107 lifecycle, 424 candles
instructionObservations = 8062
catalogue = 169 tokens / 218 pools / 218 pairs
```
Contraintes projet à respecter :
- Rust 2024.
- Code async-first.
- Pas de `?`, `unwrap`, `expect` dans le code applicatif.
- Pas de `anyhow`, pas de `thiserror`.
- Pas de `mod.rs`.
- Pas de `pub mod` ; utiliser `mod` privé + `pub use`.
- Imports uniquement pour les traits quand cest possible.
- `#![deny(unreachable_pub)]` et `#![warn(missing_docs)]` doivent rester propres.
- Tests offline.
- Les nouvelles requêtes DB doivent mettre à jour les re-exports dans `kb_lib/src/db.rs` puis `kb_lib/src/lib.rs`.
- Les structs DB doivent aller dans `kb_lib/src/db/entities/*.rs` et `kb_lib/src/db/dtos/*.rs`, pas dans les fichiers de requêtes.
## Objectif
Ajouter `Demo4` dans `kb_demo_app` et les fonctions de lecture associées dans `kb_lib` pour afficher les surfaces de programmes non encore prises en compte par le système.
Cette fonctionnalité est strictement un cockpit de découverte et de revue.
Elle ne doit pas :
- matérialiser automatiquement des contenus inconnus ;
- promouvoir automatiquement des discriminators inconnus dans les décodeurs officiels ;
- marquer automatiquement un `program_id` comme supporté ;
- créer automatiquement des lignes `trade`, `candle`, `fee`, `liquidity`, `reward`, `admin` ou `orderbook` depuis un contenu inconnu.
Elle doit :
- afficher les surfaces inconnues ou non supportées ;
- les regrouper de manière exploitable ;
- montrer les preuves et signatures samples ;
- aider à produire des prompts/patchs futurs validés manuellement.
## Comportement attendu côté utilisateur
Créer une nouvelle page ou fenêtre, selon le pattern existant :
```text
kb_demo_app/src/demo4.html
kb_demo_app/src/demo4.ts
```
ou léquivalent si lapplication utilise un autre routage.
Demo4 doit proposer des vues pour :
1. discriminators inconnus sur des decoders connus ;
2. `program_id` connus contenant des instructions non mappées par le decoder spécialisé ;
3. `upstream_git.instruction_match` groupés par `upstreamDecoderCode`, `upstreamEntryName`, `upstreamDiscriminatorHex` ;
4. `program_id` observés dans les transactions mais absents de la matrice de support ;
5. logs Anchor `Program log: Instruction: ...` non mappés localement ;
6. events Anchor `Program data:` non mappés localement ;
7. layouts de comptes récurrents sur instructions inconnues ;
8. répartition success/failed pour chaque surface candidate.
Filtres souhaités :
```text
program_id
candidate_decoder_code
discriminator_hex
instruction_name / nom log Anchor
upstream decoder
upstream entry name
success only / failed only / both
minimum observation count
minimum tx count
from slot / to slot
signature contains
show only unknown
show only upstream fallback
show only high-confidence candidates
```
Colonnes souhaitées :
```text
candidate_kind
program_id
candidate_decoder
known/unknown status
discriminator_hex
log_instruction_name
anchor_event_discriminator
account_count
layout_hash
observed_count
tx_count
success_count
failed_count
first_slot
last_slot
sample_signature
confidence_score
confidence_reason
status
```
Le panneau de détail doit afficher :
```text
sample signatures
accounts_json
data_json / data prefix
logs de transaction
inner instructions
parsed_json si disponible
decoded_payload_json si disponible
entrées upstream registry correspondantes
preuve de hash Anchor si un nom dinstruction est disponible
```
## Design `kb_lib`
Ajouter des requêtes read-only et des DTOs. Fichiers suggérés :
```text
kb_lib/src/program_surface_discovery.rs
kb_lib/src/db/dtos/program_surface_candidate_summary.rs
kb_lib/src/db/dtos/program_surface_candidate_sample.rs
kb_lib/src/db/queries/program_surface_discovery.rs
```
Si un statut persistant est nécessaire, ajouter :
```text
kb_lib/src/db/entities/program_surface_candidate.rs
kb_lib/src/db/queries/program_surface_candidates.rs
```
Ne pas placer les DTO/entities dans les fichiers de requêtes.
Statuts candidats suggérés :
```text
new
reviewed
accepted
rejected
promoted
ignored
```
Si une table persistante est ajoutée, la migration doit être explicite, idempotente et testée.
## Scoring de découverte
Le scoring est indicatif uniquement. Il ne doit jamais déclencher une matérialisation.
Signaux de confiance possibles :
| Signal | Effet |
|---|---:|
| `program_id` connu, discriminator inconnu | +20 |
| log Anchor `Instruction: X` trouvé | +30 |
| `sha256("global:x")` correspond au discriminator | +50 |
| observations success répétées | +10 |
| account count/layout stable | +10 |
| inner instruction family cohérente avec laction | +10 |
| uniquement des transactions failed | -20 |
| nom très générique comme `swap`, `claim`, `initialize` sans autre preuve | -15 |
| `program_id` inconnu et observation unique | -25 |
## Helper Anchor
Ajouter un helper qui normalise les noms dinstructions Anchor depuis les logs :
```text
Program log: Instruction: InitializePresetParameterV2
-> initialize_preset_parameter_v2
-> sha256("global:initialize_preset_parameter_v2")[0..8]
```
Ce helper doit seulement produire une preuve/candidate record. Il ne doit pas modifier les mappings de decoder.
## Export Markdown
Demo4 doit permettre dexporter un groupe candidat en Markdown pour une future session dimplémentation.
Lexport doit inclure :
```text
candidate decoder
program_id
discriminator_hex
candidate name
confidence score
preuves/evidence
sample signatures
account layout
logs
inner instruction summary
proposed target table éventuelle
warning explicite : non implémenté, non matérialisé
```
## Tests
Ajouter des tests offline pour :
- normalisation des noms Anchor depuis logs ;
- calcul de discriminators Anchor pour des noms samples ;
- groupement par program/discriminator/layout ;
- ordre de score ;
- sérialisation/désérialisation des DTOs si utilisés ;
- validation des paramètres de commandes UI.
Aucun test ne doit dépendre de RPC ou du réseau.
## Validation
```bash
cargo fmt
cargo test -p kb_lib program_surface
cargo test -p kb_lib
cargo clippy -p kb_lib --all-targets -- -D warnings
```
Pour Tauri/frontend, lancer la commande de build/test existante du projet si elle existe.
## Résultat attendu
Lutilisateur peut ouvrir Demo4 et voir immédiatement les surfaces unsupported/upstream/unknown présentes dans la base SQLite courante, sans rescanner la blockchain.
Demo4 est un cockpit de découverte uniquement. Il ne change pas la matérialisation métier.

View File

@@ -0,0 +1,249 @@
<!-- file: docs/prompts/prompt_name_0_7_59_sqlite_db_transaction_merger_binary.md -->
# Prompt — 0.7.59 Binaire de fusion de bases SQLite transactionnelles
## Contexte
Nous reprenons le workspace Rust `khadhroony-bobobot` après la clôture de `0.7.57 meteora_dlmm` et après/ou en parallèle de `0.7.58 demo4_program_surface_discovery`.
Lutilisateur possède plusieurs bases SQLite dédiées construites pendant les tranches Raydium, Pump et Meteora. Lobjectif est déviter de rescanner/backfiller des signatures déjà présentes dans ces bases.
## Objectif
Ajouter un module binaire qui utilise `kb_lib` pour fusionner des données de corpus transactionnel depuis plusieurs fichiers SQLite `.db` vers une base SQLite de sortie unique.
Le merger doit copier suffisamment de données brutes transaction/instruction pour permettre un replay local dans la base consolidée, sans refaire les appels RPC.
Ce binaire est un outil de consolidation de corpus. Ce nest pas un scanner blockchain.
## Forme recommandée
Créer un nouveau package workspace :
```text
kb_tools/
Cargo.toml
src/bin/kb_db_merge.rs
```
Le binaire doit dépendre de `kb_lib` et réutiliser autant que possible les fonctions de schéma/setup/query existantes.
Alternative acceptable si le workspace préfère ce pattern :
```text
kb_lib/src/bin/kb_db_merge.rs
```
Préférer `kb_tools` si cela évite de mélanger du code CLI-only dans `kb_lib`.
## Interface CLI
Commande suggérée :
```bash
cargo run -p kb_tools --bin kb_db_merge -- \
--output ./merged_corpus.db \
--input ./raydium.db \
--input ./pump.db \
--input ./meteora.db \
--mode raw-corpus \
--dry-run
```
Options requises ou utiles :
```text
--output <path>
--input <path> répétable
--mode <mode>
--dry-run optionnel
--replace-output optionnel ; sinon refuser si output existe
--source-label optionnel ou inféré depuis le nom de fichier
--limit optionnel pour tests
```
Modes initiaux :
```text
raw-corpus
full-copy-safe
signatures-only
```
## Mode `raw-corpus`
Mode par défaut recommandé.
Copier les données brutes canonique nécessaires au replay local sans RPC :
```text
k_sol_chain_transactions
k_sol_chain_instructions
```
Si le schéma contient dautres tables brutes/contextuelles strictement nécessaires, les inspecter avant de les ajouter. Ne copier que les tables sûres, sans duplication sémantique.
La base output doit ensuite pouvoir exécuter le replay/décodage local depuis les transactions persistées.
## Mode `full-copy-safe`
Mode optionnel pour plus tard.
Copier aussi des lignes décodées/matérialisées seulement si les foreign keys, versions de decoder et versions de schéma sont cohérentes.
Ne pas limplémenter comme mode par défaut. Il est plus dangereux car les lignes matérialisées dépendent de la version du code.
## Mode `signatures-only`
Copier uniquement les signatures/slots dans une table de staging afin quun outil futur décide quoi importer/rejouer.
## Politique de déduplication
Identité primaire :
```text
signature
```
Règles :
- Une même signature dans plusieurs inputs doit produire une seule transaction dans loutput.
- Si `meta_json`, `transaction_json`, `slot` ou `err_json` diffèrent pour une même signature, enregistrer un conflit ; ne pas écraser silencieusement.
- Préférer la ligne brute la plus complète uniquement si le conflit est explicable et journalisé.
- Conserver la provenance dans des tables daudit de merge.
Tables suggérées :
```text
k_sol_db_merge_sources
k_sol_db_merge_transactions
k_sol_db_merge_conflicts
```
Champs source suggérés :
```text
source_id
source_path
source_label
source_schema_version
source_created_at
input_transaction_count
copied_transaction_count
skipped_duplicate_count
conflict_count
```
Pour chaque signature copiée :
```text
signature
slot
source_id
source_transaction_id
copied_at
copy_status
conflict_status
```
## Règles de sécurité
- Ne pas appeler RPC.
- Ne pas backfiller.
- Ne pas décoder DEX pendant le merge.
- Ne pas matérialiser trades/candles pendant le merge.
- Ne pas supposer une compatibilité de schéma sans inspection.
- Ne pas utiliser `ATTACH` avec des chemins non validés/échappés.
- Pas de `?`, `unwrap`, `expect` dans le code applicatif.
- Les erreurs doivent être explicites, typées projet, et lisibles.
- Le mode dry-run doit indiquer exactement ce qui serait copié, ignoré ou marqué conflictuel.
## Compatibilité de schéma
Le binaire doit inspecter `sqlite_master` et `PRAGMA table_info(...)` dans chaque DB input.
Tables requises pour `raw-corpus` :
```text
k_sol_chain_transactions
k_sol_chain_instructions
```
Vérifier les colonnes requises par nom. Si une colonne optionnelle manque, lindiquer clairement et continuer seulement si la copie reste suffisante pour un replay local fiable.
Si le schéma est incompatible, échouer proprement avec un résumé court.
## Stratégie de copie
Algorithme recommandé :
1. Ouvrir/créer la base output et initialiser le schéma courant via `kb_lib`.
2. Pour chaque input DB :
- inspecter le schéma ;
- enregistrer la source ;
- itérer les transactions par slot/signature ;
- si la signature est absente de loutput, insérer la transaction et ses instructions enfants ;
- si la signature existe, comparer les champs canoniques et ignorer ou enregistrer un conflit ;
- préserver le mapping `source_transaction_id -> output_transaction_id` pour les instructions.
3. Commit par batches.
4. Imprimer un résumé final.
La taille de batch doit être configurable ou conservatrice.
## SQL de validation
Ajouter :
```text
validation_sql/SQL_VALIDATION_DB_MERGE_0_7_59.sql
```
Checks minimaux :
```sql
-- duplicate signatures in output should be empty
SELECT signature, COUNT(*)
FROM k_sol_chain_transactions
GROUP BY signature
HAVING COUNT(*) > 1;
-- orphan instructions should be empty
SELECT ins.id
FROM k_sol_chain_instructions ins
LEFT JOIN k_sol_chain_transactions tx ON tx.id = ins.transaction_id
WHERE tx.id IS NULL;
-- conflicts summary
SELECT *
FROM k_sol_db_merge_conflicts
ORDER BY id DESC
LIMIT 100;
```
## Tests
Ajouter des tests offline avec bases SQLite temporaires :
1. merge dune DB vers un output vide ;
2. merge de deux DBs avec signatures disjointes ;
3. merge de deux DBs avec signature identique et contenu identique ;
4. signature dupliquée avec conflit slot/meta et ligne conflict enregistrée ;
5. instructions recopiées avec le nouveau `transaction_id` output ;
6. dry-run sans écriture des lignes output ;
7. table requise manquante -> erreur propre.
## Documentation
Mettre à jour :
```text
README.md
ROADMAP.md
CHANGELOG.md
validation_sql/SQL_VALIDATION_DB_MERGE_0_7_59.sql
docs/reports/SQLITE_DB_TRANSACTION_MERGER_0_7_59.md
```
## Résultat attendu
Lutilisateur peut consolider ses anciennes bases Raydium/Pump/Meteora dans une base output et relancer un replay local depuis les lignes brutes existantes, sans refaire les backfills RPC de signatures.

View File

@@ -0,0 +1,249 @@
<!-- file: docs/prompts/PROMPT_0_7_59_sqlite_db_transaction_merger_binary.md -->
# Prompt — 0.7.59 Binaire de fusion de bases SQLite transactionnelles
## Contexte
Nous reprenons le workspace Rust `khadhroony-bobobot` après la clôture de `0.7.57 meteora_dlmm` et après/ou en parallèle de `0.7.58 demo4_program_surface_discovery`.
Lutilisateur possède plusieurs bases SQLite dédiées construites pendant les tranches Raydium, Pump et Meteora. Lobjectif est déviter de rescanner/backfiller des signatures déjà présentes dans ces bases.
## Objectif
Ajouter un module binaire qui utilise `kb_lib` pour fusionner des données de corpus transactionnel depuis plusieurs fichiers SQLite `.db` vers une base SQLite de sortie unique.
Le merger doit copier suffisamment de données brutes transaction/instruction pour permettre un replay local dans la base consolidée, sans refaire les appels RPC.
Ce binaire est un outil de consolidation de corpus. Ce nest pas un scanner blockchain.
## Forme recommandée
Créer un nouveau package workspace :
```text
kb_tools/
Cargo.toml
src/bin/kb_db_merge.rs
```
Le binaire doit dépendre de `kb_lib` et réutiliser autant que possible les fonctions de schéma/setup/query existantes.
Alternative acceptable si le workspace préfère ce pattern :
```text
kb_lib/src/bin/kb_db_merge.rs
```
Préférer `kb_tools` si cela évite de mélanger du code CLI-only dans `kb_lib`.
## Interface CLI
Commande suggérée :
```bash
cargo run -p kb_tools --bin kb_db_merge -- \
--output ./merged_corpus.db \
--input ./raydium.db \
--input ./pump.db \
--input ./meteora.db \
--mode raw-corpus \
--dry-run
```
Options requises ou utiles :
```text
--output <path>
--input <path> répétable
--mode <mode>
--dry-run optionnel
--replace-output optionnel ; sinon refuser si output existe
--source-label optionnel ou inféré depuis le nom de fichier
--limit optionnel pour tests
```
Modes initiaux :
```text
raw-corpus
full-copy-safe
signatures-only
```
## Mode `raw-corpus`
Mode par défaut recommandé.
Copier les données brutes canonique nécessaires au replay local sans RPC :
```text
k_sol_chain_transactions
k_sol_chain_instructions
```
Si le schéma contient dautres tables brutes/contextuelles strictement nécessaires, les inspecter avant de les ajouter. Ne copier que les tables sûres, sans duplication sémantique.
La base output doit ensuite pouvoir exécuter le replay/décodage local depuis les transactions persistées.
## Mode `full-copy-safe`
Mode optionnel pour plus tard.
Copier aussi des lignes décodées/matérialisées seulement si les foreign keys, versions de decoder et versions de schéma sont cohérentes.
Ne pas limplémenter comme mode par défaut. Il est plus dangereux car les lignes matérialisées dépendent de la version du code.
## Mode `signatures-only`
Copier uniquement les signatures/slots dans une table de staging afin quun outil futur décide quoi importer/rejouer.
## Politique de déduplication
Identité primaire :
```text
signature
```
Règles :
- Une même signature dans plusieurs inputs doit produire une seule transaction dans loutput.
- Si `meta_json`, `transaction_json`, `slot` ou `err_json` diffèrent pour une même signature, enregistrer un conflit ; ne pas écraser silencieusement.
- Préférer la ligne brute la plus complète uniquement si le conflit est explicable et journalisé.
- Conserver la provenance dans des tables daudit de merge.
Tables suggérées :
```text
k_sol_db_merge_sources
k_sol_db_merge_transactions
k_sol_db_merge_conflicts
```
Champs source suggérés :
```text
source_id
source_path
source_label
source_schema_version
source_created_at
input_transaction_count
copied_transaction_count
skipped_duplicate_count
conflict_count
```
Pour chaque signature copiée :
```text
signature
slot
source_id
source_transaction_id
copied_at
copy_status
conflict_status
```
## Règles de sécurité
- Ne pas appeler RPC.
- Ne pas backfiller.
- Ne pas décoder DEX pendant le merge.
- Ne pas matérialiser trades/candles pendant le merge.
- Ne pas supposer une compatibilité de schéma sans inspection.
- Ne pas utiliser `ATTACH` avec des chemins non validés/échappés.
- Pas de `?`, `unwrap`, `expect` dans le code applicatif.
- Les erreurs doivent être explicites, typées projet, et lisibles.
- Le mode dry-run doit indiquer exactement ce qui serait copié, ignoré ou marqué conflictuel.
## Compatibilité de schéma
Le binaire doit inspecter `sqlite_master` et `PRAGMA table_info(...)` dans chaque DB input.
Tables requises pour `raw-corpus` :
```text
k_sol_chain_transactions
k_sol_chain_instructions
```
Vérifier les colonnes requises par nom. Si une colonne optionnelle manque, lindiquer clairement et continuer seulement si la copie reste suffisante pour un replay local fiable.
Si le schéma est incompatible, échouer proprement avec un résumé court.
## Stratégie de copie
Algorithme recommandé :
1. Ouvrir/créer la base output et initialiser le schéma courant via `kb_lib`.
2. Pour chaque input DB :
- inspecter le schéma ;
- enregistrer la source ;
- itérer les transactions par slot/signature ;
- si la signature est absente de loutput, insérer la transaction et ses instructions enfants ;
- si la signature existe, comparer les champs canoniques et ignorer ou enregistrer un conflit ;
- préserver le mapping `source_transaction_id -> output_transaction_id` pour les instructions.
3. Commit par batches.
4. Imprimer un résumé final.
La taille de batch doit être configurable ou conservatrice.
## SQL de validation
Ajouter :
```text
validation_sql/SQL_VALIDATION_DB_MERGE_0_7_59.sql
```
Checks minimaux :
```sql
-- duplicate signatures in output should be empty
SELECT signature, COUNT(*)
FROM k_sol_chain_transactions
GROUP BY signature
HAVING COUNT(*) > 1;
-- orphan instructions should be empty
SELECT ins.id
FROM k_sol_chain_instructions ins
LEFT JOIN k_sol_chain_transactions tx ON tx.id = ins.transaction_id
WHERE tx.id IS NULL;
-- conflicts summary
SELECT *
FROM k_sol_db_merge_conflicts
ORDER BY id DESC
LIMIT 100;
```
## Tests
Ajouter des tests offline avec bases SQLite temporaires :
1. merge dune DB vers un output vide ;
2. merge de deux DBs avec signatures disjointes ;
3. merge de deux DBs avec signature identique et contenu identique ;
4. signature dupliquée avec conflit slot/meta et ligne conflict enregistrée ;
5. instructions recopiées avec le nouveau `transaction_id` output ;
6. dry-run sans écriture des lignes output ;
7. table requise manquante -> erreur propre.
## Documentation
Mettre à jour :
```text
README.md
ROADMAP.md
CHANGELOG.md
validation_sql/SQL_VALIDATION_DB_MERGE_0_7_59.sql
docs/reports/SQLITE_DB_TRANSACTION_MERGER_0_7_59.md
```
## Résultat attendu
Lutilisateur peut consolider ses anciennes bases Raydium/Pump/Meteora dans une base output et relancer un replay local depuis les lignes brutes existantes, sans refaire les backfills RPC de signatures.

View File

@@ -0,0 +1,198 @@
<!-- file: docs/prompts/prompt_name_0_7_60_meteora_damm_next_dex.md -->
# Prompt — 0.7.60 Meteora DAMM v1 puis DAMM v2
## Décision
Ne pas fusionner Meteora DAMM v1 et Meteora DAMM v2 dans une seule tranche dimplémentation.
Utiliser des versions séparées :
```text
0.7.60 -> meteora_damm_v1
0.7.61 -> meteora_damm_v2
```
Raison :
- `program_id` différents ;
- surfaces IDL/discriminators différentes ;
- corpus historiques et besoins de validation différents ;
- clôture SQL plus lisible ;
- risque réduit de faux positifs cross-version ;
- rollback plus simple si une version contient une hypothèse incorrecte.
Partage autorisé :
- helpers communs privés ;
- patterns communs de récupération fee/reward amounts ;
- conventions communes de coverage/tests ;
- structure commune de rapport ;
- template SQL commun.
Ne pas partager la classification de decoder dune manière qui masque les discriminators version-spécifiques ou les layouts propres à chaque programme.
## Contexte
`0.7.57 meteora_dlmm` est clos. Les tranches intermédiaires planifiées sont :
```text
0.7.58 -> demo4_program_surface_discovery
0.7.59 -> sqlite_db_transaction_merger
```
La prochaine tranche DEX doit reprendre la famille Meteora après DLMM/DBC, en commençant par DAMM v1.
Surfaces Meteora connues :
```text
meteora_dbc -> clos 0.7.56
meteora_dlmm -> clos 0.7.57
meteora_damm_v1 -> 0.7.60
meteora_damm_v2 -> 0.7.61
meteora_vault -> plus tard, surface séparée
```
## Cible 0.7.60 — meteora_damm_v1
Program id depuis la roadmap :
```text
Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB
```
Objectif principal :
```text
Full decode + full materialization pour toutes les instructions/events DAMM v1 disponibles depuis les IDL locales et les sources upstream.
```
Familles attendues :
```text
swap
pool_create
add_liquidity
remove_liquidity
lock/unlock liquidity si présent
fee/admin/config
lifecycle/migration si présent
```
Règles :
- Pas de decoded-only pour une entrée utile observée si elle peut être matérialisée sûrement.
- Ne pas créer de trade/candle depuis des non-swaps.
- Ne pas matérialiser les transactions failed.
- Ne pas agréger artificiellement les fees multi-mint.
- Utiliser `k_sol_fee_event_amounts` pour les legs fee fiables.
- Utiliser la récupération inner SPL transfer seulement avec allowlist explicite et tests.
- Conserver toutes les entrées IDL/upstream non observées dans la coverage avec `0/0` et proof status clair.
## Sources à vérifier
Inspecter dabord le répertoire local :
```text
idls/
```
Puis comparer avec :
```text
Carbon decoders
Pinax/substreams-solana-idls
0xfnzero sol-parser-sdk / solana-streamer
ancien code local et rapports historiques du projet
samples Solscan / backfills Demo3
```
Ne pas considérer les anciens résultats `0.7.36` ou `0.7.46` comme clôture finale. Revalider depuis le schéma courant et les règles actuelles de matérialisation.
## Plan de travail
1. Créer ou rafraîchir les entrées coverage `meteora_damm_v1`.
2. Vérifier le `program_id` et la surface IDL locale.
3. Étendre lenum/local classifier des discriminators.
4. Ajouter le naming dans `instruction_observation_index`.
5. Décoder toutes les instructions et tous les events Anchor disponibles.
6. Matérialiser swaps, liquidity, lifecycle, fee, reward/admin/orderbook si applicable.
7. Ajouter des tests synthétiques pour chaque instruction/event IDL, y compris non observé.
8. Ajouter le SQL de validation.
9. Rejouer sur base fraîche avec :
```text
skipDexDecode=no
forceDexDecode=yes
deferInstructionObservations=yes
```
10. Clore seulement si les gates SQL sont propres.
## Gates SQL obligatoires
Reprendre le pattern DLMM :
```text
fallback upstream pour entrées localement couvertes -> vide
instruction_name null/blank -> vide
decoded sans coverage -> vide
successful non-materialized without skip/policy -> vide
failed tx materialization -> vide
multi-target materialization -> vide
non-swap trade/candle -> vide
fee scalar parent without leg -> vide
orphan fee legs -> vide
coverage logical duplicates -> vide
watchlist sans backlog meteora_damm_v1
```
## Cible 0.7.61 — meteora_damm_v2
Program id depuis la roadmap :
```text
cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG
```
Nouvrir cette tranche quaprès clôture DAMM v1.
La tranche v2 peut réutiliser le template et des helpers privés, mais doit conserver ses propres éléments :
```text
decoder code
coverage entries
instruction enum
event mapping
synthetic tests
SQL validation
rapport
```
## Livrables attendus pour 0.7.60
Fichiers probables :
```text
kb_lib/src/dex/meteora_damm_v1.rs
kb_lib/src/dex_event_coverage.rs
kb_lib/src/dex_event_classification.rs
kb_lib/src/instruction_observation_index.rs
kb_lib/src/non_trade_event_materialization.rs
validation_sql/SQL_VALIDATION_METEORA_DAMM_V1_0_7_60.sql
docs/reports/METEORA_DAMM_V1_EVENT_COVERAGE_REPORT.md
```
Mettre à jour les re-exports si des modules ou requêtes sont ajoutés :
```text
kb_lib/src/dex.rs
kb_lib/src/lib.rs
kb_lib/src/db.rs
```
## Note finale
Si la découverte corpus montre que DAMM v1 et v2 partagent une logique basse-niveau précise, créer des helpers privés communs.
Ne pas fusionner les deux protocoles dans un seul decoder, une seule coverage ou un seul rapport de clôture.

View File

@@ -0,0 +1,198 @@
<!-- file: docs/prompts/PROMPT_0_7_60_meteora_damm_next_dex.md -->
# Prompt — 0.7.60 Meteora DAMM v1 puis DAMM v2
## Décision
Ne pas fusionner Meteora DAMM v1 et Meteora DAMM v2 dans une seule tranche dimplémentation.
Utiliser des versions séparées :
```text
0.7.60 -> meteora_damm_v1
0.7.61 -> meteora_damm_v2
```
Raison :
- `program_id` différents ;
- surfaces IDL/discriminators différentes ;
- corpus historiques et besoins de validation différents ;
- clôture SQL plus lisible ;
- risque réduit de faux positifs cross-version ;
- rollback plus simple si une version contient une hypothèse incorrecte.
Partage autorisé :
- helpers communs privés ;
- patterns communs de récupération fee/reward amounts ;
- conventions communes de coverage/tests ;
- structure commune de rapport ;
- template SQL commun.
Ne pas partager la classification de decoder dune manière qui masque les discriminators version-spécifiques ou les layouts propres à chaque programme.
## Contexte
`0.7.57 meteora_dlmm` est clos. Les tranches intermédiaires planifiées sont :
```text
0.7.58 -> demo4_program_surface_discovery
0.7.59 -> sqlite_db_transaction_merger
```
La prochaine tranche DEX doit reprendre la famille Meteora après DLMM/DBC, en commençant par DAMM v1.
Surfaces Meteora connues :
```text
meteora_dbc -> clos 0.7.56
meteora_dlmm -> clos 0.7.57
meteora_damm_v1 -> 0.7.60
meteora_damm_v2 -> 0.7.61
meteora_vault -> plus tard, surface séparée
```
## Cible 0.7.60 — meteora_damm_v1
Program id depuis la roadmap :
```text
Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB
```
Objectif principal :
```text
Full decode + full materialization pour toutes les instructions/events DAMM v1 disponibles depuis les IDL locales et les sources upstream.
```
Familles attendues :
```text
swap
pool_create
add_liquidity
remove_liquidity
lock/unlock liquidity si présent
fee/admin/config
lifecycle/migration si présent
```
Règles :
- Pas de decoded-only pour une entrée utile observée si elle peut être matérialisée sûrement.
- Ne pas créer de trade/candle depuis des non-swaps.
- Ne pas matérialiser les transactions failed.
- Ne pas agréger artificiellement les fees multi-mint.
- Utiliser `k_sol_fee_event_amounts` pour les legs fee fiables.
- Utiliser la récupération inner SPL transfer seulement avec allowlist explicite et tests.
- Conserver toutes les entrées IDL/upstream non observées dans la coverage avec `0/0` et proof status clair.
## Sources à vérifier
Inspecter dabord le répertoire local :
```text
idls/
```
Puis comparer avec :
```text
Carbon decoders
Pinax/substreams-solana-idls
0xfnzero sol-parser-sdk / solana-streamer
ancien code local et rapports historiques du projet
samples Solscan / backfills Demo3
```
Ne pas considérer les anciens résultats `0.7.36` ou `0.7.46` comme clôture finale. Revalider depuis le schéma courant et les règles actuelles de matérialisation.
## Plan de travail
1. Créer ou rafraîchir les entrées coverage `meteora_damm_v1`.
2. Vérifier le `program_id` et la surface IDL locale.
3. Étendre lenum/local classifier des discriminators.
4. Ajouter le naming dans `instruction_observation_index`.
5. Décoder toutes les instructions et tous les events Anchor disponibles.
6. Matérialiser swaps, liquidity, lifecycle, fee, reward/admin/orderbook si applicable.
7. Ajouter des tests synthétiques pour chaque instruction/event IDL, y compris non observé.
8. Ajouter le SQL de validation.
9. Rejouer sur base fraîche avec :
```text
skipDexDecode=no
forceDexDecode=yes
deferInstructionObservations=yes
```
10. Clore seulement si les gates SQL sont propres.
## Gates SQL obligatoires
Reprendre le pattern DLMM :
```text
fallback upstream pour entrées localement couvertes -> vide
instruction_name null/blank -> vide
decoded sans coverage -> vide
successful non-materialized without skip/policy -> vide
failed tx materialization -> vide
multi-target materialization -> vide
non-swap trade/candle -> vide
fee scalar parent without leg -> vide
orphan fee legs -> vide
coverage logical duplicates -> vide
watchlist sans backlog meteora_damm_v1
```
## Cible 0.7.61 — meteora_damm_v2
Program id depuis la roadmap :
```text
cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG
```
Nouvrir cette tranche quaprès clôture DAMM v1.
La tranche v2 peut réutiliser le template et des helpers privés, mais doit conserver ses propres éléments :
```text
decoder code
coverage entries
instruction enum
event mapping
synthetic tests
SQL validation
rapport
```
## Livrables attendus pour 0.7.60
Fichiers probables :
```text
kb_lib/src/dex/meteora_damm_v1.rs
kb_lib/src/dex_event_coverage.rs
kb_lib/src/dex_event_classification.rs
kb_lib/src/instruction_observation_index.rs
kb_lib/src/non_trade_event_materialization.rs
validation_sql/SQL_VALIDATION_METEORA_DAMM_V1_0_7_60.sql
docs/reports/METEORA_DAMM_V1_EVENT_COVERAGE_REPORT.md
```
Mettre à jour les re-exports si des modules ou requêtes sont ajoutés :
```text
kb_lib/src/dex.rs
kb_lib/src/lib.rs
kb_lib/src/db.rs
```
## Note finale
Si la découverte corpus montre que DAMM v1 et v2 partagent une logique basse-niveau précise, créer des helpers privés communs.
Ne pas fusionner les deux protocoles dans un seul decoder, une seule coverage ou un seul rapport de clôture.

View File

@@ -0,0 +1,182 @@
# Meteora DLMM event coverage report — 0.7.57 final
## Scope
Version `0.7.57` closes `meteora_dlmm` from the local IDL and the dedicated local corpus.
Target program:
```text
LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo
```
Local IDL:
```text
idls/meteora_dlmm.LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo.json
```
Final inventoried surface:
```text
76 IDL instructions
30 Anchor events
12 accounts
```
The local corpus additionally identified discriminator `75c73e67068e1fcb` as `initialize_preset_parameter_v2`. This discriminator was not present in the local IDL under that spelling, but the transaction logs contain `Instruction: InitializePresetParameterV2`, the account layout is stable, and the instruction creates a 36-byte DLMM-owned preset parameter account through the system program.
## Final validation summary
```text
cargo test -p kb_lib -> 460 passed / 0 failed
cargo clippy -p kb_lib --all-targets -- -D warnings -> OK
769 replayed
0 decode skipped
769 ledger upserts
646 unsafe ledger rows
106 trades
664 liquidity
1107 lifecycle
0 tokenAccount
424 candle upserts
instructionObservations = 8062
resetDeleted = 9898
catalog = 169 tokens / 218 pools / 218 pairs
```
## Closure checks
All blocking checks are clean:
```text
upstream_git fallback for locally covered meteora_dlmm entries -> empty
local instruction_audit observed -> 0
DLMM decoded events without coverage -> empty
successful non-materialized DLMM without explicit skip/policy -> empty
failed transaction business materialization -> empty
multi-target materialization -> empty
non-swap trade/candle safety -> empty
fee parent scalar without fee amount leg -> empty
orphan fee amount legs -> empty
limit/orderbook trade/candle double-count -> empty
logical duplicate coverage rows -> empty
```
The only coverage difference left is explained and non-blocking:
```text
close_bin_array observed 16 / materialized 14
14 successful transactions -> lifecycle materialized
2 failed transactions Custom 6015 -> decoded/audit only, no business materialization
```
## Materialization policy
### Trades and candles
Only instruction-level DLMM swaps can produce trades/candles:
```text
meteora_dlmm.swap
meteora_dlmm.swap2
meteora_dlmm.swap_exact_out
meteora_dlmm.swap_exact_out2
meteora_dlmm.swap_with_price_impact
meteora_dlmm.swap_with_price_impact2
```
Anchor `swap_event` and `swap2_evt` are materialized as lifecycle `swap_log` rows and never as trades/candles. This prevents double-counting when an instruction swap and an Anchor log describe the same user-visible swap.
### Liquidity and lifecycle
The following families are materialized when transactions are successful and context is reliable:
```text
add_liquidity*
remove_liquidity*
remove_all_liquidity
rebalance_liquidity
initialize_bin_array*
close_bin_array
go_to_a_bin*
initialize_position*
close_position*
increase_position_length*
decrease_position_length*
update_position_operator*
lb_pair_create_event
position_create_event
position_close_event
```
Position and bin lifecycle events are routed to `k_sol_pool_lifecycle_events` when the operation is structural rather than a direct liquidity amount delta.
### Fees
Fee parents are written to `k_sol_fee_events`. Amount legs are written to `k_sol_fee_event_amounts`.
Final observed amount-leg summary:
```text
claim_fee 64 parents / 64 legs
claim_fee2 63 parents / 88 legs
claim_fee_event 127 parents / 187 legs
claim_fee2_event 78 parents / 118 legs
composition_fee_event 51 parents / 63 legs
withdraw_protocol_fee 14 parents / 20 legs
zap_protocol_fee 13 parents / 13 legs
```
The inner SPL transfer recovery is explicitly allowlisted for DLMM fee event kinds. It is not inherited globally by future decoders.
### Rewards
Reward parents are written to `k_sol_reward_events`. Amounts are recovered only when a reliable inner SPL transfer or decoded amount is present.
Final observed scalar amount summary:
```text
claim_reward 15 parents / 1 scalar amount
claim_reward2 19 parents / 10 scalar amounts
claim_reward_event 34 parents / 25 scalar amounts
claim_reward2_event 19 parents / 10 scalar amounts
fund_reward 10 parents / 10 scalar amounts
fund_reward_event 10 parents / 10 scalar amounts
initialize_reward 9 parents / 0 amount
initialize_reward_event 9 parents / 0 amount
```
`initialize_reward` and `initialize_reward_event` remain without amount because they are configuration/initialization events, not executed reward transfers. No amount is fabricated from limits, bounds or configuration fields.
### Admin/config and orderbook
Admin/config events materialize to `k_sol_pool_admin_events`. Limit-order operations materialize to `k_sol_orderbook_events` and never to trade/candle tables.
Important promoted local corpus entry:
```text
75c73e67068e1fcb -> meteora_dlmm.initialize_preset_parameter_v2 -> k_sol_pool_admin_events
```
## Remaining non-observed surfaces
Non-observed IDL/account rows remain in coverage with `observed_count = 0` and `materialized_count = 0`. They are not blockers.
Examples:
```text
update_reward_duration
update_reward_funder
withdraw_ineligible_reward
migrate_position
account metadata rows
for_idl_type_generation_do_not_call
anchor_self_cpi_log registry row
```
## Decision
`0.7.57 meteora_dlmm` is closed. Do not add further DLMM Rust patches unless a new corpus proves a successful transaction that is decoded but not materialized and lacks an explicit skip/policy reason.
Next recommended work is not another DLMM patch: implement `0.7.58 demo4_program_surface_discovery` to display unknown or unsupported program surfaces without automatic materialization or automatic decoder promotion.