Stratégie des sources de transactions

Décision actuelle

Les sources temps réel payantes ne sont plus l’axe actif de 0.3.x.

La priorité est :

backfills HTTP sur comptes gratuits
  -> transaction canonique
    -> extraction core
      -> décodeurs Core/Pump/Meteora/Raydium/Orca/Jupiter

Helius Developer, Triton, Chainstack, Shyft ou un autre provider seront testés seulement lorsque le pipeline pourra décoder et matérialiser immédiatement les transactions reçues.

Sources futures

HTTP JSON-RPC

Usage :

backfill historique ;
hydratation de signatures ;
réparation ;
validation ponctuelle.

Méthodes principales :

getSignaturesForAddress
getTransaction
getSignatureStatuses
getSlot

Helius WebSocket enrichi

transactionSubscribe est une extension Helius, pas une méthode Solana standard.

Elle sera implémentée dans des modules internes de kb_onchain_transport, sans créer de crate séparée, puis convertie vers le modèle canonique commun.

Yellowstone gRPC

Yellowstone fournit l’équivalent fonctionnel d’un flux de transactions complètes filtrées. Les endpoints Triton, Chainstack, Shyft ou compatibles doivent être supportés par configuration dans kb_onchain_transport.

Solana WebSocket standard

logsSubscribe par mention ou avec filtre "all" reste une solution de probe, de fallback ou de comparaison. Une notification de logs ne devient durable qu’après hydratation de la transaction ou enregistrement d’une observation technique légère.

Stockage commun

Toutes les sources convergent vers :

kb_sol_raw_transactions
kb_sol_obs_transaction_observations

Les décodeurs ne connaissent ni le fournisseur, ni le protocole, ni la méthode d’acquisition.

Ordre de mise en œuvre

0.3.x  transaction canonique, observations, backfill gratuit, extraction core
0.4.x  décodeurs Core/SPL
0.5.x  Pump
0.6.x  Meteora
0.7.x  Raydium
0.8.x  Orca
0.9.x  Jupiter et routeurs
0.10.x Helius transactionSubscribe, Yellowstone gRPC et comparaison

Sécurité de reprise

Pendant toute perte du flux principal :

trading = disabled

Le replay ou le backfill après reconnexion sert à remettre la base en cohérence. Un événement replayed, backfilled ou repaired ne doit pas déclencher rétroactivement un ordre.

Critères de choix futur

La décision provider devra comparer :

couverture par programme et CPI ;
latence par signature ;
coût par Go, crédit ou forfait ;
nombre de filtres et streams ;
régions ;
reconnexion et fenêtre de replay ;
pertes et backpressure ;
portabilité du protocole ;
qualité du support.

Les timings seront mesurés dans kb_sol_obs_transaction_observations.

2.8 KiB Raw Blame History Unescape Escape