Sasedev/khadhroony-bobobot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f81e0f3bea820ff5ae0c95a730d3beb3edff5deb
khadhroony-bobobot/README.md
SinuS Von SifriduS f81e0f3bea 0.7.49
2026-06-05 14:53:16 +02:00

34 KiB
Raw Blame History

khadhroony-bobobot

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 et l’état de consolidation atteint après 0.7.45 pour meteora_dlmm. La version Cargo a évolué ensuite à 0.7.46 côté workspace. 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.

État courant finalisé 0.7.49

La branche de travail 0.7.49 clôture la tranche raydium_clmm après la clôture fonctionnelle de 0.7.48 raydium_cpmm. Le code Rust de kb_lib est considéré finalisé pour cette tranche, sous réserve des validations locales habituelles (cargo fmt, cargo test -p kb_lib, cargo clippy -p kb_lib --all-targets -- -D warnings).

État CLMM validé sur corpus local après replay forcé :

listed_entry_count        = 45
decoded_entry_count       = 33
observed_entry_count      = 33
materialized_entry_count  = 25
total_observed_count      = 2560
total_materialized_count  = 1367
trade_count               = 1186
raydium_clmm.instruction_audit résiduel = 0
upstream_git.instruction_match localement couvert = 0
failed tx matérialisées = 0
non-swap CLMM avec trade_count > 0 = 0

Les 11 Anchor / Program data events CLMM restent listés en upstream_git_unverified car aucun corpus local ne les observe encore. Le code est préparé pour les accueillir en audit-only lorsqu’ils apparaîtront dans un corpus local, sans créer de trade/candle par défaut.

La prochaine tranche fonctionnelle est 0.7.50 raydium_launchpad, avant 0.7.51 raydium_amm_v4 et 0.7.52 raydium_stable.

Organisation documentaire

La racine conserve uniquement les documents de pilotage principaux :

  • README.md ;
  • ROADMAP.md ;
  • CHANGELOG.md.

Les documents spécialisés sont rangés dans :

  • docs/ pour les matrices et revues de modèle ;
  • docs/reports/ pour les rapports de couverture DEX/version ;
  • docs/prompts/ pour les prompts de reprise ;
  • validation_sql/ pour les scripts SQL de validation.

Voir aussi :

  • docs/DEX_DECODER_MATRIX.md pour la matrice DEX détaillée ;
  • docs/DEX_EVENT_COVERAGE_MATRIX.md pour la matrice de familles d’events ;
  • docs/DB_EVENT_MODEL_REVIEW.md pour la revue du modèle DB ;
  • docs/reports/RAYDIUM_CPMM_EVENT_COVERAGE_REPORT.md et validation_sql/SQL_VALIDATION_RAYDIUM_CPMM_0_7_48.sql pour la clôture CPMM ;
  • docs/reports/RAYDIUM_CLMM_EVENT_COVERAGE_REPORT.md et validation_sql/SQL_VALIDATION_RAYDIUM_CLMM_0_7_49.sql pour la clôture CLMM ;
  • docs/prompts/PROMPT_REPRISE_khadhroony-bobobot_0.7.50-raydium-launchpad.md pour reprendre en 0.7.50.

Sources upstream Git / IDL à utiliser en 0.7.47+

Les sources externes ci-dessous sont des indices de décodage, pas des preuves métier. Elles servent à extraire des program_id, discriminants, IDL, layouts et noms d’instructions/events, mais toute promotion locale doit rester conditionnée à :

  1. observation Demo3 ;
  2. backfill Demo2 ;
  3. replay local sur la base de travail ;
  4. requêtes SQL de validation ;
  5. invariants : aucun faux trade, aucune fausse candle, aucun program_id promu sans corpus.

Sources prioritaires :

Source Usage attendu
https://github.com/sevenlabs-hq/carbon/tree/main/decoders Source principale de discriminants, instructions et events multi-protocoles.
https://github.com/0xfnzero/solana-streamer Source complémentaire pour PumpFun, PumpSwap, Bonk et Raydium CPMM.
https://github.com/0xfnzero/sol-parser-sdk/tree/main/idl IDL complémentaires pour programmes Solana supportés par parser SDK.
https://github.com/pinax-network/substreams-solana-idls/tree/main/src IDL et layouts additionnels à comparer au registre local.
https://github.com/hodlwarden/solana-tx-parser/tree/main/src Décodage transactionnel complémentaire et conventions de mapping.
https://github.com/openbook-dex/openbook-v2 Source officielle OpenBook v2 : programme, IDL et logs.
https://github.com/all-in-one-blockchain/phoenix-onchain-mm Source Phoenix/MM complémentaire pour corpus et intégration.
https://docs.vybenetwork.com/docs/available-dexs-amms Source de découverte de DEX/AMM supportés par Vybe, à traiter comme index externe non vérifié localement.

1. Objectif

L’objectif opérationnel est de construire progressivement une application capable de :

  • détecter l’apparition de nouveaux tokens, pools, paires et listings sur Solana ;
  • identifier en priorité les DEX effectifs sur lesquels les swaps, liquidités et événements de marché sont réellement exécutés ;
  • décoder les transactions pertinentes des DEX ciblés, puis seulement ensuite les launch surfaces et origines de mint/lancement ;
  • séparer strictement les swaps/candles des événements utiles seulement à l’analyse : liquidité, cycle de vie de pool, fees, rewards, administration, wallet activity, mint/burn, migration ;
  • produire des métriques exploitables : prix, volume, candles/OHLCV, activité, bursts, déséquilibres buy/sell, signaux analytiques ;
  • préparer ensuite des règles déterministes de filtrage, d’achat, de vente, de stop-loss et de trailing stop ;
  • conserver une traçabilité locale suffisante pour rejouer, diagnostiquer et améliorer les décodeurs sans retraiter inutilement toute la base.

Le but court terme n’est pas encore le live trading. Le but court terme est de fiabiliser le décodage multi-DEX, la matérialisation des objets métier nécessaires au trading et le mécanisme de replay incrémental.

2. Workspace

Le workspace contient deux crates principales.

Crate Rôle
kb_lib Bibliothèque métier : configuration, tracing, clients réseau, pool HTTP, manager WS, résolution transactionnelle, décodage DEX, détection métier, persistance SQLite, backfill, metadata, candles, signaux analytiques, validation et diagnostics.
kb_demo_app Application Tauri V2 de démonstration et d’inspection : fenêtres Demo Ws, Demo Ws Manager, Demo Http, Demo Pipeline, Demo Pipeline 2, Demo3, graphiques candles et commandes de backfill/replay.

La logique métier doit rester dans kb_lib. kb_demo_app doit rester une façade UI/Tauri utilisée pour inspecter, backfiller et constituer du corpus on-chain ; elle ne doit pas récupérer de logique DEX profonde.

3. État actuel au point de reprise 0.7.43-E5C

3.1. Socle stabilisé à ne pas refactorer maintenant

Ces éléments fonctionnent et ne sont pas bloquants pour les DEX. Ils ne doivent pas être remaniés dans la phase immédiate :

  • ws_client.rs ;
  • ws_manager.rs ;
  • http_client.rs ;
  • http_pool.rs ;
  • couches JSON-RPC WS/HTTP déjà stabilisées ;
  • orchestration réseau utilisée par les fenêtres de démonstration.

Ils pourront être améliorés plus tard, mais la priorité actuelle est le décodage DEX, les événements métier, les tables d’analyse et le replay incrémental.

3.2. Pipeline métier existant

Le pipeline 0.7.x couvre déjà les étapes suivantes :

  1. réception d’observations via RPC WS ou backfill HTTP ;
  2. résolution des transactions via HTTP RPC ;
  3. projection transactionnelle normalisée en base ;
  4. décodage DEX dans k_sol_dex_decoded_events ;
  5. détection métier vers tokens, pools, paires, listings, origins et wallets observés ;
  6. matérialisation des trades exploitables ;
  7. matérialisation partielle des événements non-trade prouvés ;
  8. agrégation pair metrics ;
  9. génération candles/OHLCV ;
  10. signaux analytiques simples ;
  11. inspection via l’application de démonstration.

3.3. Résultat local observé avant normalisation

Un corpus local de reprise contient notamment :

Indicateur Valeur observée
transactions chain 2956
decoded events 7159
trade events 2738
liquidity events 0
pool lifecycle events 1
fee events 0
reward events 0
admin events 0

Cette distribution montre que les swaps sont déjà fortement présents, mais que la matérialisation non-trade n’est pas encore homogène sur le corpus courant. Les nombreux instruction_audit, surtout côté Meteora, doivent devenir un axe de travail DEX par DEX.

3.4. Connecteurs validés ou observés via l’application de démo

Les surfaces suivantes existent dans le code, dans la matrice ou dans le corpus local. Leur niveau de preuve doit rester explicite.

Code Statut de travail Commentaire
pump_fun launch surface Surface de launch / mint initial. À traiter après les DEX effectifs sauf besoin de migration.
pump_swap DEX effectif Swaps buy / sell observés. Non-trade à étendre plus tard.
raydium_cpmm DEX effectif consolidé partiellement Swaps et premiers events non-trade prouvés sur corpus antérieur.
raydium_clmm DEX effectif consolidé partiellement Swaps v2/legacy, positions et liquidity events prouvés sur corpus antérieur.
raydium_amm_v4 DEX effectif legacy Swaps AMM v4 legacy matérialisés ; non-swaps legacy conservés en audit tant que le corpus ne permet pas une promotion fiable.
meteora_dlmm DEX effectif 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 en consolidation 0.7.46 Swaps présents ; decoder étendu aux create_pool, liquidity, claim_fee et lock events DAMM v1 mappés upstream Git/corpus local. Validation DB à rejouer sur base dédiée.
meteora_damm_v2 DEX effectif à reprendre séparément Swaps et create_pool observés ; nombreux audits à traiter.
meteora_dbc launch/bonding + DEX effectif partiel à reprendre séparément Gros volume d’audits ; séparer bonding/launch, swap effectif et migration.
orca_whirlpools DEX effectif à vérifier À revalider par corpus dédié avant promotion.
fluxbeam DEX effectif à vérifier Program id, corpus et events à vérifier.
dexlab DEX effectif à vérifier Program id, corpus et events à vérifier.
metaDAO candidat à vérifier Aucun program_id ne doit être déclaré vérifié sans preuve/corpus.
printr candidat à vérifier Aucun program_id ne doit être déclaré vérifié sans preuve/corpus.

3.5. Statuts de preuve obligatoires

Aucun program_id, DEX ou event ne doit être documenté comme vérifié sans preuve reproductible.

Statut Sens
known Connu/listé dans le code, une doc, une source externe ou la matrice.
observed Vu dans une transaction, une instruction, une base locale ou un corpus on-chain.
decoded Un decoder produit un event structuré ou un instruction_audit classé.
materialized L’event alimente une table métier dédiée : trade, liquidity, lifecycle, fee, reward, admin, mint/burn, etc.
verified_by_corpus Validé par requêtes SQL, signatures/corpus reproductibles et invariants de validation.

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 upstream Git/IDL suffisamment fiable n’a été confirmé. Ils ne bloquent pas la clôture de 0.7.45.

3.7. État de travail de meteora_damm_v1 en 0.7.46

La tranche 0.7.46 étend meteora_damm_v1 à partir du mapping upstream Git decoder source meteora-pools-decoder et des discriminants observés dans le corpus local. Les events ajoutés couvrent create_pool, add_liquidity, remove_liquidity, claim_fee, create_lock_escrow et lock_liquidity.

La version logique du replay local devient dex_decode.v0.7.46.damm_v1_events1, ce qui force le redécodage des transactions certifiées sous la version 0.7.45 pour vérifier les nouveaux events DAMM v1.

Meteora Vault est traité prudemment : le programme associé peut apparaître comme compte dans les instructions DAMM v1, mais aucun decoder meteora_vault ni statut verified_by_corpus n’est ajouté sans corpus direct séparé.

Demo3 dispose ensuite d’une correction ciblée pour la découverte meteora_damm_v1 : les discriminants DAMM v1 connus sont classés directement côté recherche on-chain, le filtrage target_event est strict sur les surfaces explicites, et les transactions mixtes ne sont plus éliminées globalement quand une cible précise est demandée. Cela sert à alimenter les backfills par signature ou par pool dans Demo Pipeline 2 sans déplacer de logique métier profonde dans kb_demo_app.

4. Matrice DEX : priorité révisée

À partir du point de reprise 0.7.43-E5C, la priorité est :

  1. DEX effectifs actuels : programmes où les swaps, pools, liquidités, positions, fees, rewards, admin/config, burns/mints ou migrations sont réellement exécutés ;
  2. launch surfaces : surfaces de mint, bonding, launchpad, migration ou origine ;
  3. DEX historiques / legacy / faibles priorités : programmes anciens, peu observés, ou uniquement utiles à la compatibilité/replay historique.

Chaque DEX ou variante de DEX doit avoir sa propre étape de validation. Les familles larges restent utiles pour la navigation, mais le travail de décodage doit être fait par version/protocole : raydium_cpmm, raydium_clmm, raydium_amm_v4, meteora_dlmm, meteora_damm_v1, meteora_damm_v2, meteora_dbc, etc.

4.1. Ordre de travail DEX effectifs

Priorité Code cible Rôle Action prochaine
1 pump_swap AMM / swap Maintenir les invariants swaps et chercher les non-trade prouvés.
2 raydium_cpmm AMM Garder consolidé ; ne rouvrir que sur nouveaux discriminators/corpus.
3 raydium_clmm CLMM Garder consolidé ; ne rouvrir que sur nouveaux discriminators/corpus.
4 raydium_amm_v4 AMM legacy actif Garder swaps ; ne promouvoir les non-swaps qu’avec corpus.
5 meteora_dlmm DLMM Reprendre séparément : swaps, liquidity, positions, lifecycle, fees/rewards/admin.
6 meteora_damm_v1 AMM Reprendre séparément : swaps exploitables, pools, liquidity, fees/admin.
7 meteora_damm_v2 AMM Reprendre séparément : create_pool, swaps exploitables, configs dynamiques, non-trade.
8 meteora_dbc bonding / DEX effectif partiel Reprendre séparément : swap effectif, bonding curve, migration, launch attribution.
9 orca_whirlpools CLMM Revalider par corpus dédié.
10 fluxbeam AMM Vérifier program id, events et corpus.
11 dexlab AMM Vérifier program id, events et corpus.
12 metaDAO candidat DEX Vérifier par corpus avant toute promotion.
13 printr candidat DEX Vérifier par corpus avant toute promotion.

4.2. Launch surfaces reportées

À reprendre après les DEX effectifs, sauf si une surface est indispensable pour comprendre une migration vers un pool tradable :

  • pump_fun ;
  • raydium_launchlab ;
  • letsbonk / bonk_fun ;
  • bags ;
  • moonshot ;
  • moonit ;
  • boop_fun ;
  • believe ;
  • heaven ;
  • autres launch origins découvertes par corpus.

4.3. DEX historiques ou faibles priorités

À garder dans la matrice mais sans bloquer les versions immédiates :

  • raydium_stable_swap tant que son usage réel n’est pas démontré par corpus local ;
  • vieux programmes legacy uniquement utiles pour compatibilité ou replay historique ;
  • agrégateurs/routeurs comme okx_dex tant qu’ils ne correspondent pas à un DEX direct matérialisable ;
  • entrées ambiguës comme zora tant qu’aucun programme Solana pertinent n’est prouvé.

5. Base de données et replay incrémental

SQLite reste le stockage local initial. Le fichier config.json peut pointer vers une base différente pour travailler par corpus, par DEX ou sur base vierge. Le schéma est créé au lancement via les CREATE TABLE IF NOT EXISTS existants.

Organisation actuelle à conserver :

  • kb_lib/src/db/schema.rs crée les tables et index ;
  • chaque table/index est créée dans une fonction dédiée ;
  • les requêtes sont sous kb_lib/src/db/queries/ ;
  • les entités persistées sont sous kb_lib/src/db/entities/ ;
  • les DTO applicatifs sont sous kb_lib/src/db/dtos/.

5.1. Tables existantes importantes

Le modèle actuel contient déjà notamment :

  • k_sol_chain_transactions ;
  • k_sol_chain_instructions ;
  • k_sol_dexes ;
  • k_sol_dex_decoded_events ;
  • k_sol_tokens ;
  • k_sol_pools ;
  • k_sol_pairs ;
  • k_sol_pool_tokens ;
  • k_sol_trade_events ;
  • k_sol_liquidity_events ;
  • k_sol_pool_lifecycle_events ;
  • k_sol_fee_events ;
  • k_sol_reward_events ;
  • k_sol_pool_admin_events ;
  • k_sol_token_mint_events ;
  • k_sol_token_burn_events ;
  • k_sol_transaction_classifications ;
  • k_sol_protocol_candidates.

5.2. Ledger de décodage/replay implémenté en 0.7.44

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 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 ;
  • associer le résultat au decoder_code et à une version logique de decoder ;
  • permettre un mode force qui ignore le ledger ;
  • permettre un mode de reprise ciblé lorsque le decoder change ;
  • ne pas skipper automatiquement les transactions multi-token, multi-pool ou multi-event ambiguës ;
  • conserver les failed transactions comme traçables mais non actionnables.

Table actuelle :

  • k_sol_dex_decode_replay_ledger.

Champs principaux :

Champ conceptuel Rôle
transaction_id / signature rattachement transactionnel stable
decoder_scope périmètre logique du decoder, actuellement dex_decode.local_pipeline
decoder_version version logique du decoder
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

Règles cibles :

  • par défaut, ne pas retraiter une instruction dont le ledger indique un décodage certain avec le même decoder/version et la même entrée ;
  • retraiter si force = true ;
  • retraiter si le decoder concerné change de version logique ;
  • retraiter si la transaction contient plusieurs tokens/pools/events et que le ledger la classe comme ambiguë ou partielle ;
  • retraiter si un event précédemment instruction_audit devient décodable par un nouveau decoder ;
  • ne jamais créer de faux trade/candle pour un event dont les montants ne sont pas fiables ;
  • conserver les audits utiles pour améliorer les decoders.

7. Contraintes de code

Contraintes maintenues :

  • Rust 2024 ;
  • pas de mod.rs ;
  • fichiers Rust avec entête // file: ... ;
  • fichiers .toml avec entête # file: ... ;
  • exposition centralisée via lib.rs ;
  • #![deny(unreachable_pub)] et #![warn(missing_docs)] dans les racines concernées ;
  • pas de anyhow ;
  • pas de thiserror ;
  • pas de ?, unwrap, expect dans le code applicatif de kb_lib ;
  • kb_demo_app peut rester plus souple tant qu’elle reste une application de démonstration ;
  • usage privilégié de match, if let Err, let Err = ... else dans kb_lib ;
  • imports externes limités, sauf traits lorsque nécessaire ;
  • tests unitaires et tests de replay maintenus.

Si une requête DB est ajoutée ou modifiée, mettre à jour les re-exports dans kb_lib/src/db.rs, puis dans kb_lib/src/lib.rs si la surface publique l’exige.

8. Priorité immédiate

La priorité immédiate après le point de reprise 0.7.43-E5C est :

  1. 0.7.48 : raydium_cpmm — clôturé côté event coverage ;
  2. 0.7.49 : raydium_clmm — clôturé côté instructions observées, matérialisation non-trade prouvée et nettoyage fallback ;
  3. 0.7.50 : raydium_launchpad ;
  4. 0.7.51 : raydium_amm_v4 ;
  5. 0.7.52 : raydium_stable ;
  6. 0.7.53 : pump_swap ;
  7. 0.7.54 : pump_fun ;
  8. 0.7.55+ : Meteora, Phoenix/OpenBook, Orca puis validation progressive des autres DEX/surfaces issus du registre upstream Git.

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.

9. Fichiers utiles pour reprendre dans une nouvelle session

Pour reprendre rapidement le codage dans une nouvelle session, fournir au minimum :

  • README.md ;
  • ROADMAP.md ;
  • CHANGELOG.md ;
  • Cargo.toml racine ;
  • clippy.toml ;
  • config.json ;
  • kb_lib/Cargo.toml ;
  • kb_lib/src/lib.rs ;
  • kb_lib/src/constants.rs ;
  • kb_lib/src/dex.rs ;
  • kb_lib/src/dex/*.rs ;
  • kb_lib/src/dex_decode.rs ;
  • kb_lib/src/dex_detect.rs ;
  • kb_lib/src/dex_support_matrix.rs ;
  • kb_lib/src/dex_event_classification.rs ;
  • kb_lib/src/non_trade_event_materialization.rs ;
  • kb_lib/src/trade_aggregation.rs ;
  • kb_lib/src/pair_candle_aggregation.rs ;
  • kb_lib/src/local_pipeline_replay.rs ;
  • kb_lib/src/local_pipeline_validation.rs ;
  • kb_lib/src/local_pipeline_diagnostics.rs ;
  • kb_lib/src/onchain_dex_pair_discovery.rs ;
  • kb_lib/src/db/schema.rs ;
  • kb_lib/src/db.rs ;
  • kb_lib/src/db/entities.rs et kb_lib/src/db/entities/* ;
  • kb_lib/src/db/dtos.rs et kb_lib/src/db/dtos/* ;
  • kb_lib/src/db/queries.rs et kb_lib/src/db/queries/*.

Ajouter kb_demo_app/src/demo_pipeline*.rs, kb_demo_app/src/demo3.rs, les fichiers frontend associés et les nouvelles démos seulement si la tâche concerne l’UI, la recherche de corpus, les diagnostics affichés ou le watcher temps réel.

Demo3 multi-target discovery

Demo3 can search several event surfaces in one on-chain scan by checking multiple target event boxes. Internally this uses the existing targetEvent field with comma-separated normalized values, preserving compatibility with older single-target calls.

Demo3 paged / multi-source discovery

Demo3 can now scan one or several source addresses in a single on-chain discovery run. Source addresses may be pools, vaults, positions, config accounts or mints; the program id remains an instruction filter and no discovered address is promoted as verified automatically.

The on-chain discovery form supports Solana getSignaturesForAddress pagination through beforeSignature, untilSignature, maxPages and scanOrder. newest_first preserves Solana RPC order. oldest_first reverses the fetched window after paging, which is useful when enough pages have been fetched to include the creation-side history of a pool. The JSON result includes nextBeforeByAddress cursor hints for subsequent manual windows.

Note 0.7.46 DAMM v1 upstream Git coverage

La couverture meteora_damm_v1 inclut désormais les surfaces upstream Git decoder source meteora-pools-decoder connues. Les surfaces non rencontrées dans le corpus local restent marquées upstream_git_mapped_unverified et doivent être validées par Demo3 + backfill + replay avant d’être considérées comme corpus-confirmed.

Sur le corpus local élargi, swap, add_balance_liquidity, remove_balance_liquidity, claim_fee, create_lock_escrow, lock, InitializePermissionlessConstantProductPoolWithConfig et InitializePermissionlessConstantProductPoolWithConfig2 sont marqués upstream_git_local_corpus_observed.

Note 0.7.47 Upstream Git Registry / DEX discovery preparation

La version 0.7.47 n’est plus dédiée à un seul DEX. Elle doit introduire un registre upstream Git générique pour les program_id, discriminants d’instructions, discriminants d’events, noms d’instructions et familles de programmes issus de dépôts Git externes de decoders Solana.

Les entrées de ce registre sont des indices de découverte, pas des preuves métier. Elles doivent être marquées upstream_git_unverified ou upstream_git_mapped_unverified tant qu’elles ne sont pas confirmées par Demo3, backfill, replay local et requêtes SQL.

Le registre sert à accélérer la constitution de corpus pour les DEX et surfaces suivantes : Meteora DAMM v2/DBC/Vault, Raydium Launchpad/Stable/Locking, Orca Whirlpools, FluxBeam, DexLab, Lifinity AMM v2, Phoenix/OpenBook, Stabble, BonkSwap, Boop, Moonshot, Heaven, Wavebreak, Vertigo, Virtuals, Pancake Swap, OKX DEX, Jupiter/Kamino/Drift et autres programmes utiles à la découverte.

Note 0.7.47-1FE5 — Event coverage et modèle DB

La matrice DEX/version doit être complétée par une matrice événementielle exhaustive. Le projet ne vise pas seulement les swaps : les events burn, mint, transfer, account_close, lock/unlock, vault_deposit/withdraw, admin/config, order_fill, settle_funds, launch et migration peuvent influencer une décision de trading.

Voir :

  • docs/DEX_DECODER_MATRIX.md pour le statut par DEX/version ;
  • docs/DEX_EVENT_COVERAGE_MATRIX.md pour les familles d'events à couvrir ;
  • docs/DB_EVENT_MODEL_REVIEW.md pour les ajouts DB à envisager avant 0.7.48+.

Note 0.7.48-pre — Event coverage DB checkpoint

La micro-tranche 0.7.48-pre introduit la persistance de couverture événementielle avant la reprise DEX par DEX.

Ajouts côté kb_lib :

  • table k_sol_dex_event_coverage_entries ;
  • entity, DTO et requêtes dédiées ;
  • service DexEventCoverageService pour synchroniser les entrées du registre upstream Git vers SQLite ;
  • refresh des compteurs locaux depuis k_sol_dex_decoded_events et les tables déjà existantes de matérialisation non-trade / trade ;
  • exposition des summaries de coverage dans les diagnostics locaux ;
  • ajout du profil de validation 0.7.48-pre_event_coverage_db_checkpoint, qui synchronise le registre upstream avant validation ;
  • le profil 0.7.48-pre garde les invariants globaux de non-régression, mais borne le contrôle bloquant des trade candidates non matérialisés aux DEX Raydium attendus pour éviter qu’un DEX partiel hors scope bloque le checkpoint DB ;
  • sélection du profil 0.7.48-pre dans Demo Pipeline 2.

Cette tranche ne modifie pas les decoders DEX, ne crée aucun trade/candle, et ne promeut aucun program_id comme vérifié. Elle sert uniquement à objectiver la couverture : listed, decoded/audit, observed, materialized, trade_count et statut de preuve.

La suite fonctionnelle reprend par Raydium avant Meteora :

  1. 0.7.48 — raydium_cpmm ;
  2. 0.7.49 — raydium_clmm ;
  3. 0.7.50 — raydium_launchpad ;
  4. 0.7.51 — raydium_amm_v4 ;
  5. 0.7.52 — raydium_stable ;
  6. 0.7.53+ — Pump, Meteora, Phoenix/OpenBook, Orca puis les autres DEX/surfaces.

Note 0.7.48 — Raydium CPMM event coverage

La tranche 0.7.48 reprend raydium_cpmm avant Meteora, en s'appuyant sur la table k_sol_dex_event_coverage_entries ajoutée en 0.7.48-pre.

Le scope CPMM couvre désormais les entrées Carbon/fnzero/IDL suivantes : close_permission_pda, collect_creator_fee, collect_fund_fee, collect_protocol_fee, create_amm_config, create_permission_pda, deposit, initialize, initialize_with_permission, lp_change_event, swap_base_input, swap_base_output, swap_event, update_amm_config, update_pool_status et withdraw.

Le decoder local spécialisé remplace le fallback upstream_git.instruction_match pour les instructions CPMM couvertes localement. Les events Anchor self-CPI lp_change_event et swap_event sont décodés comme preuve audit/coverage, mais ne produisent pas directement trade_events, metrics ou candles. Les swaps matérialisables restent les chemins instruction-scoped swap_base_input et swap_base_output lorsque les montants et le sens économique sont exploitables.

Aucune nouvelle table DB n'est ajoutée en 0.7.48. Les transfers, token account lifecycle, vaults, orderbook, launch/migration et locking restent documentés comme familles transversales futures, à promouvoir seulement après preuve multi-DEX.

Voir aussi :

  • docs/DEX_EVENT_COVERAGE_MATRIX.md pour la couverture par familles ;
  • docs/reports/RAYDIUM_CPMM_EVENT_COVERAGE_REPORT.md pour le rapport de tranche ;
  • validation_sql/SQL_VALIDATION_RAYDIUM_CPMM_0_7_48.sql pour les requêtes de validation.

Complément 0.7.48-raydium-cpmm-program-data : la coverage DB est maintenant synchronisée automatiquement quand un refresh de coverage est demandé sur une base neuve et qu'aucune ligne n'existe encore. Les backfills token/pool/signature déclenchent aussi un refresh best-effort de la coverage afin d'éviter un état incohérent où k_sol_dex_decoded_events est rempli mais k_sol_dex_event_coverage_entries reste vide.

Le decoder CPMM lit désormais les events Program data: émis par le programme Raydium CPMM. Les layouts lp_change_event et swap_event sont décodés depuis le payload event direct, en plus du chemin Anchor self-CPI e445a52e51cb9a1d + event_discriminator. swap_event reste tradeCandidate=false / candleCandidate=false : les seuls trades CPMM matérialisables restent swap_base_input et swap_base_output. lp_change_event peut alimenter la matérialisation liquidity si le corpus fournit un pool/pair fiable et si changeType distingue dépôt/retrait.

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 clôturable

La tranche 0.7.48 clôture la couverture Raydium CPMM sur corpus local. Les entrées deposit, withdraw et lp_change_event matérialisent k_sol_liquidity_events sans créer de trade/candle ; initialize et initialize_with_permission matérialisent seulement k_sol_pool_lifecycle_events ; les fees matérialisent k_sol_fee_events ; les entrées admin/config observées matérialisent k_sol_pool_admin_events.

La table technique k_sol_instruction_observations est ajoutée pour indexer localement les instructions observées par decoder_code, instruction_name et discriminator_hex. Demo3 peut rechercher par instruction/discriminant, ce qui reproduit localement l’usage pratique du filtre Solscan instruction=<discriminator>.

État final CPMM observé : 561 trades, 50 liquidity events, 9 lifecycle events, 25/25 lp_change_event matérialisés, swap_event audit-only à 0 trade, et deux entrées connues mais non observées (close_permission_pda, update_pool_status) conservées en upstream_git_mapped_unverified.

Note 0.7.49 — Raydium CLMM event coverage final

La tranche 0.7.49 clôture raydium_clmm comme deuxième tranche Raydium après CPMM. Elle ajoute la couverture complète des instructions CLMM observées depuis Carbon, IDL Raydium, Pinax, fnzero et corpus Solscan/backfill, ainsi que la table transversale k_sol_orderbook_events pour les instructions limit-order.

Points finalisés :

  • 45 entrées listées dans k_sol_dex_event_coverage_entries ;
  • 33 instructions CLMM avec local_event_kind spécialisé ;
  • 33 instructions observées dans le corpus local ;
  • 25 entrées matérialisées ;
  • swaps matérialisés uniquement via swap / swap_v2 ;
  • limit orders open, increase, decrease, close, settle décodés et matérialisés en k_sol_orderbook_events quand la transaction réussit ;
  • non-trades CLMM vers liquidity, fee, reward, admin, lifecycle et orderbook sans trade/candle ;
  • transactions échouées conservées audit-only ;
  • raydium_clmm.instruction_audit résiduel à zéro ;
  • upstream_git.instruction_match localement couvert à zéro après replay ;
  • 11 Anchor / Program data events CLMM préparés mais conservés upstream_git_unverified faute d’observation locale.

La validation finale est dans validation_sql/SQL_VALIDATION_RAYDIUM_CLMM_0_7_49.sql.

Reference in New Issue View Git Blame Copy Permalink