Sasedev/khadhroony-bobobot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.7.36

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-05-14 12:49:50 +02:00
parent 348ae7f153
commit edc8da02a3
12 changed files with 823 additions and 120 deletions
Download Patch File Download Diff File Expand all files Collapse all files

89
README.md
View File

@@ -4,7 +4,7 @@
`khadhroony-bobobot` est un workspace Rust destiné à la détection, au décodage, à l’analyse et, à terme, au trading semi-automatisé de tokens Solana.
Le README précédent décrivait surtout l’état `0.3.1`. Ce fichier reflète l’état de reprise autour de `0.7.34` : le socle transport HTTP/WS, la résolution transactionnelle, le modèle SQLite, plusieurs connecteurs DEX, les candles, les signaux analytiques, la validation locale et une matrice DEX commune existent déjà.
Le README précédent décrivait surtout l’état `0.3.1`. Ce fichier reflète l’état de reprise autour de `0.7.36` et ouvre le travail `0.7.37` : le socle transport HTTP/WS, la résolution transactionnelle, le modèle SQLite, plusieurs connecteurs DEX, les candles, les signaux analytiques, la validation locale et une matrice DEX commune existent déjà.
## 1. Objectif
@@ -31,7 +31,7 @@ Le workspace contient deux crates principales.
La logique métier doit rester dans `kb_lib`. `kb_demo_app` doit rester une façade UI/Tauri et ne doit pas récupérer de logique Solana ou DEX profonde.
## 3. État actuel autour de `0.7.34`
## 3. État actuel autour de `0.7.36`
### 3.1. Socle stabilisé à ne pas refactorer maintenant
@@ -61,29 +61,44 @@ Le pipeline `0.7.x` couvre déjà les étapes suivantes :
9. signaux analytiques simples ;
10. inspection via l’application de démonstration.
### 3.3. Connecteurs validés manuellement via l’application de démo
### 3.3. Connecteurs validés ou observés via l’application de démo
Les connecteurs suivants sont les surfaces prioritaires à verrouiller avant extension massive :
Les connecteurs suivants sont les surfaces actuellement les plus importantes pour la validation locale :
- `pump_fun` comme surface de launch / mint initial ;
- `pump_swap` pour les swaps post-migration Pump ;
- `raydium_cpmm` ;
- `raydium_clmm` ;
- `meteora_dlmm` ;
- `meteora_damm_v1`, actuellement partiel pour les swaps sans payload montant/prix exploitable.
- `meteora_damm_v1`, partiel : les swaps sans payload montant/prix exploitable restent conservés mais non actionnables ;
- `meteora_damm_v2`, observé dans le corpus `0.7.36`, mais les swaps sans payload montant/prix exploitable sont maintenant `non_actionable_trade` ;
- `meteora_dbc`, observé dans le corpus `0.7.36`, mais les swaps sans payload montant/prix exploitable sont maintenant `non_actionable_trade`.
### 3.4. Connecteurs déjà présents mais à consolider par corpus
Les modules suivants existent ou sont partiellement représentés dans le code, mais doivent être consolidés par corpus local, invariants et documentation :
Les modules suivants existent ou sont partiellement représentés dans le code, mais doivent encore être consolidés par corpus local, invariants et documentation :
- `meteora_dbc` ;
- `meteora_damm_v1` ;
- `meteora_damm_v2` ;
- `orca_whirlpools` ;
- `fluxbeam` ;
- `dexlab` ;
- `raydium_amm_v4` legacy ;
- launch origins déjà amorcées : `meteora_fun_launch`, `bags`, `moonit`.
- launch origins déjà amorcées : `meteora_fun_launch`, `bags`, `moonit` ;
- launch surfaces à venir : `raydium_launchlab`, `raydium_launchpad`, `letsbonk` / `bonk`, `boop_fun`, `moonshot`, `believe`, `heaven`.
### 3.5. Validation acquise en `0.7.36`
La validation `0.7.36_meteora_family_consolidation` est considérée comme réalisée lorsque les invariants suivants restent vrais après replay local :
- `validationPassed = true` ;
- `diagnosticsClean = true` ;
- `blockingIssueCount = 0` ;
- `decodedTradeCandidateWithoutTradeEventCount = 0` ;
- `decodedTradeCandidateWithoutAmountPayloadCount = 0` ;
- `missingTradeEventCount = 0` ;
- `pairWithoutTradeCount = 0` pour les paires actionnables ;
- `pairWithoutCandleCount = 0` pour les paires actionnables.
Point important : `meteora_damm_v2` et `meteora_dbc` peuvent produire beaucoup d’événements `swap` décodés sans produire de `trade_events` lorsque les montants ou prix ne sont pas fiables. Ces événements doivent rester `non_actionable_trade` et ne doivent pas être comptés comme `tradeCandidate` ou `candleCandidate`.
## 4. Matrice DEX et launch surfaces
@@ -97,7 +112,11 @@ La distinction importante est la suivante :
Depuis `0.7.29`, la matrice de support DEX est portée par `kb_lib/src/dex_support_matrix.rs`. Elle centralise le code interne, la famille, la version, le type de surface, les program ids vérifiés localement, le statut de support, les capacités actuelles et les raisons de skip.
Depuis `0.7.30`, les événements décodés reçoivent aussi une classification plus fine : `eventLifecycleKind`, `eventActionability` et `nonTradeUseful`. Depuis `0.7.34`, cette classification commence à alimenter les tables non-trade utiles, sans alimenter directement les trades/candles. Le backfill ciblé token/pool appelle aussi cette matérialisation afin que les compteurs `liquidityEventCount` et `poolLifecycleEventCount` soient cohérents sans devoir lancer un replay local séparé.
Depuis `0.7.30`, les événements décodés reçoivent aussi une classification plus fine : `eventLifecycleKind`, `eventActionability` et `nonTradeUseful`. Cette classification sert aux diagnostics et prépare la matérialisation future des événements non-trade sans alimenter directement les trades/candles.
Depuis `0.7.32`, les diagnostics distinguent explicitement les gaps littéraux de catalogue (`literalPairWithoutTradeCount`, `literalPairWithoutCandleCount`) des gaps bloquants/actionnables (`blockingPairWithoutTradeCount`, `blockingPairWithoutCandleCount`). Les anciens champs `pairWithoutTradeCount` et `pairWithoutCandleCount` restent exposés comme alias de compatibilité pour les gaps bloquants/actionnables.
Depuis `0.7.33`, les diagnostics ajoutent une classification `pairTradingReadiness` au niveau des paires et des résumés agrégés `pairTradingReadinessSummaries`. Cette classification sépare les paires directement lisibles/tradables contre WSOL ou stable, les paires inversées avec WSOL/stable en base, les paires cross-quote nécessitant un routeur/aggregator, les paires non matérialisées en trade et les cas de quote inconnue. Elle reste purement diagnostique : elle ne modifie ni le replay, ni les `trade_events`, ni les candles.
| Code cible | Type | Statut `0.7.29` | Prochaine action |
|---|---:|---|---|
@@ -109,9 +128,9 @@ Depuis `0.7.30`, les événements décodés reçoivent aussi une classification
| `raydium_launchpad` | Launch surface | à vérifier | ne pas inventer de program id |
| `raydium_amm_v4` | AMM legacy | partiel | traiter après les autres Raydium avec corpus dédié |
| `meteora_dlmm` | DLMM | supporté | verrouiller corpus et non-régression |
| `meteora_damm_v1` | AMM legacy | partiel | conserver le skip explicite des swaps sans montants exploitables |
| `meteora_damm_v2` | AMM | partiel | corpus et séparation swaps/liquidité/events |
| `meteora_dbc` | Launch / bonding curve | partiel | lifecycle, migration et swaps exploitables |
| `meteora_damm_v1` | AMM legacy | partiel validé | conserver le skip explicite des swaps sans montants exploitables |
| `meteora_damm_v2` | AMM | partiel validé `0.7.36` | conserver les swaps sans amounts en `non_actionable_trade`; ajouter extraction de montants seulement avec preuve |
| `meteora_dbc` | Launch / bonding curve | partiel validé `0.7.36` | conserver les swaps sans amounts en `non_actionable_trade`; étudier migration / launch origin |
| `meteora_dlc` | À vérifier | à vérifier | confirmer surface/program id avant intégration |
| `orca_whirlpools` | CLMM | partiel | corpus fiable et validation des instructions utiles |
| `fluxbeam` | AMM | partiel | corpus fiable avant validation |
@@ -171,24 +190,6 @@ Avant d’étendre trop agressivement les DEX, ces tables doivent être stabilis
`k_sol_liquidity_events` existe déjà et doit être stabilisée/étendue plutôt que recréée sans nécessité.
### 5.3. État `0.7.34` des événements non-trade
Le profil `0.7.34_non_trade_liquidity_lifecycle` valide deux choses distinctes :
- les tables et diagnostics non-trade existent pour compter `liquidityEventCount` et `poolLifecycleEventCount` ;
- les décodeurs doivent maintenant émettre les événements utiles, au lieu de les classer comme inconnus ou de les ignorer.
Première tranche couverte : Meteora DLMM. Les discriminants et hints suivants sont pris en charge comme événements non-trade utiles :
| Event kind | Catégorie | Effet attendu |
|---|---|---|
| `meteora_dlmm.add_liquidity` | liquidity | persistance dans `k_sol_liquidity_events` quand le replay matérialise les decoded events |
| `meteora_dlmm.remove_liquidity` | liquidity | persistance dans `k_sol_liquidity_events` |
| `meteora_dlmm.initialize_position` | liquidity / position open | persistance dans `k_sol_liquidity_events` avec `LiquidityEventKind::PositionOpen`, sans génération de trade/candle |
| `meteora_dlmm.initialize_bin_array` | pool lifecycle | persistance dans `k_sol_pool_lifecycle_events` |
Invariant maintenu : ces événements peuvent améliorer le scoring, le contexte de pool et le diagnostic, mais ne doivent jamais créer directement de `trade_events`, pair metrics ou candles.
## 6. Politique de refactor actuelle
Le code et la documentation sont vivants. Les refactors agressifs sont acceptables lorsque cela rend le pipeline plus propre et plus durable, à condition de respecter ces limites :
@@ -231,18 +232,20 @@ Les tests peuvent rester plus souples lorsque cela clarifie le test.
## 8. Priorité immédiate
La reprise doit suivre cet ordre :
La prochaine étape est `0.7.37_token_metadata_catalog_enrichment`.
1. conserver la non-régression `0.7.31` : transactions failed traçables mais exclues des `trade_events`, metrics et candles ;
2. utiliser la matrice `0.7.29` comme source commune pour le catalogue, la classification et les protocol candidates ;
3. relier progressivement les événements non-trade aux tables existantes : lifecycle, liquidité, fees, rewards, admin ;
4. consolider Meteora, surtout `meteora_dlmm` et le cas partiel `meteora_damm_v1` ;
5. ajouter les launch surfaces manquantes comme origines de mint : LaunchLab/Launchpad, LetsBonk/Bonk.fun, Boop.fun, Moonshot/Moonit, Believe, Bags ;
6. traiter Heaven ;
7. consolider Orca/FluxBeam/DexLab ;
8. isoler Raydium AMM v4 legacy ;
9. effectuer une validation DEX v1 consolidée ;
10. reprendre ensuite l’UI analytique et les vues token/pair/pool.
Objectif : rendre le catalogue local exploitable visuellement et analytiquement sans toucher aux invariants de décodage/trade validés en `0.7.36`.
À faire en priorité :
1. ajouter ou compléter un registre local des mints connus : `SOL`, `WSOL`, `USDC`, `USDT`, puis autres mints fréquents si vérifiés ;
2. améliorer le service de backfill metadata pour traiter les tokens déjà présents en base ;
3. exposer un résumé de metadata manquantes par asset class, protocole d’origine, DEX et quote asset ;
4. rafraîchir automatiquement ou explicitement les `pair_symbol` après mise à jour des tokens ;
5. ajouter une commande UI ou clarifier la commande existante pour relancer le metadata backfill ;
6. vérifier l’idempotence : relancer le backfill metadata ne doit pas recréer tokens/pools/pairs/trades ;
7. conserver les compteurs DEX propres : `blockingIssueCount = 0`, `actionableMissingTradeEventCount = 0`, `missingTradeEventCount = 0` ;
8. préparer ensuite les launch surfaces, qui deviennent l’étape suivante de la roadmap.
## 9. Fichiers utiles pour reprendre dans une nouvelle session