khadhroony-solana-project/docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md

Acquisition RAW Transaction

1. Rôle

Ce document est l'owner durable de la taxonomie d'acquisition RawTransaction de KSP. Il sépare volontairement :

• les invariants durables de convergence vers Store ;
• les rôles/capabilities d'acquisition ;
• les audits datés de protocoles/providers ;
• les gaps à transmettre aux releases d'implémentation.

Il ne définit ni un endpoint secret, ni un quota provider figé, ni une configuration utilisateur. Les disponibilités et limites externes sont réauditées à la date indiquée dans chaque section d'audit.

2. Invariants durables

La convergence RAW reste indépendante de la source :

identité canonique transaction = (network, signature)
contenu canonique               = source-independent
acquisition utile               = RawTransactionObservation distincte
provider/protocole/endpoint     = provenance, jamais identité transactionnelle
même identité + même contenu    = idempotence
même identité + contenu divergent = conflit explicite

Une source n'est admise pour persister un RawTransaction que si KSP peut reconstruire le payload canonique complet attendu par Store. Un signal incomplet reste une discovery et doit être hydraté par une autre capability.

3. Taxonomie de rôles

Rôle	Responsabilité	Exemple standard actuel
live_direct_full	transaction/bloc complet reçu directement	WS blockSubscribe aujourd’hui ; autres sources en pre.005
live_discovery	référence/signature reçue puis hydration séparée	WS logsSubscribe
targeted_confirmation	signature déjà connue surveillée jusqu’au commitment	WS signatureSubscribe
history_discovery	énumération de références historiques	HTTP getSignaturesForAddress ; HTTP getBlocks/getBlocksWithLimit
hydration	récupération de transaction complète depuis une référence	HTTP getTransaction
gap_boundary	détermination d’une fenêtre ou d’une limite de rétention	getSlot/getFirstAvailableBlock/minimumLedgerSlot
gap_repair	réacquisition explicite après perte de continuité	HTTP bloc ou adresse selon le scope disponible

Ces rôles sont orthogonaux au protocole. Une stratégie concrète peut combiner plusieurs rôles et plusieurs transports ; la configuration future ne doit pas réduire le modèle à Http | WebSocket | Grpc.

4. Audit daté A — Solana standard

Audit effectué le 4 septembre 2026 à partir de la documentation RPC Solana courante et de la surface KSP 0.3.9-pre.3.

4.1 Matrice fonctionnelle

Voie	Capability	RAW complet	Temporalité utile	Décision	État KSP
HTTP getSignaturesForAddress + getTransaction	discovery adresse + hydration	non / oui	historique, catch-up, repair ciblé	ADMIS	déjà utilisé par Backfill ; getTransaction observé conserve provider + endpoint
HTTP getBlocks / getBlocksWithLimit + getBlock	discovery slots/blocs + extraction	non / oui	catch-up global, gap repair, historique	ADMIS SOUS GAP	getBlock typé existe mais pas de variante observée
HTTP getSlot	borne haute selon commitment	non	pilotage catch-up / gap	AUXILIAIRE	surface typée KSP disponible
HTTP getFirstAvailableBlock	borne basse des blocs conservés	non	admission historique / diagnostic	AUXILIAIRE	surface typée KSP disponible
HTTP minimumLedgerSlot	borne basse ledger du nœud	non	diagnostic de rétention/provider	AUXILIAIRE	surface typée KSP disponible
WS logsSubscribe	discovery live par logs	non	live + signal de gap	ADMIS	hydration getTransaction obligatoire pour RAW complet
WS signatureSubscribe	suivi d’une signature déjà connue	non	confirmation/repair ciblé	SECONDAIRE	one-shot ; ne découvre pas un flux de transactions
WS blockSubscribe	bloc live contenant transactions	oui si transactionDetails=full	live / catch-up très court	ADMIS SOUS CONTRAINTES	méthode Solana instable + activation validator requise
WS slotSubscribe	signal slot/parent/root	non	détection/pilotage de gap	AUXILIAIRE	stable mais ne transporte aucune transaction
WS slotsUpdatesSubscribe	lifecycle détaillé de slot	non	diagnostic de continuité	OPTIONNEL	méthode Solana instable ; pas une source RAW directe

4.2 HTTP adresse : discovery + hydration

getSignaturesForAddress retourne des signatures confirmées associées à une adresse, ordonnées du plus récent au plus ancien, avec before, until, limit, commitment et minContextSlot. La discovery est donc naturellement adressée : elle ne constitue pas une discovery globale de toutes les transactions du réseau.

getTransaction retourne ensuite la transaction confirmée complète ou null. Pour KSP, cette combinaison est la référence actuelle du Backfill et reste admise pour :

historique adressé
catch-up adressé
repair ciblé
hydration d'un signal WS qui connaît déjà la signature

Elle n'est pas retenue comme source live globale par polling.

4.3 HTTP bloc : scan global par slots

getBlocks et getBlocksWithLimit énumèrent des slots confirmés ; la documentation courante borne leurs ranges/limits à 500 000. getBlock peut retourner les transactions complètes du bloc avec confirmed ou finalized et les options de détail/encodage.

Cette famille est admise comme stratégie potentielle de :

catch-up global par slots
gap repair global
historique lorsque le provider conserve la plage demandée

Elle n'est pas équivalente à getSignaturesForAddress : la discovery est par slot/bloc et l'hydration est un conteneur de plusieurs transactions. Le worker doit extraire chaque transaction, reconstruire son identité (network, signature) et produire une observation propre à chaque acquisition durable.

4.4 Bornes de continuité HTTP

getSlot, getFirstAvailableBlock et minimumLedgerSlot ne produisent aucune transaction. Ils servent à décider si un gap est encore réparable sur un endpoint et à borner un scan :

getSlot                -> borne haute selon commitment
getFirstAvailableBlock -> premier bloc confirmé encore disponible
minimumLedgerSlot      -> plus ancien slot encore présent dans le ledger du nœud

Ces méthodes ne prouvent pas à elles seules qu'une transaction précise est disponible ; elles sont des primitives d'admission/diagnostic.

4.5 WS logsSubscribe : discovery live

logsSubscribe peut écouter all, allWithVotes ou les transactions mentionnant un seul pubkey par appel. La notification KSP contient le contexte de slot, la signature, l'erreur nullable et les logs ordonnés.

Cette notification n'est pas un RawTransaction complet. Elle est admise comme live discovery :

logsSubscribe notification
        -> signature + slot
        -> getTransaction observed
        -> normalisation RAW
        -> persistence transaction + observation

Le filtre mentions limité à une adresse par subscription implique que la surveillance de nombreux programmes/comptes consomme plusieurs subscriptions, sauf utilisation de all/allWithVotes avec filtrage côté consumer.

4.6 WS signatureSubscribe : confirmation ciblée

signatureSubscribe surveille une signature déjà connue et s'arrête automatiquement après la notification terminale au commitment demandé. Il ne découvre donc aucune nouvelle transaction.

Décision : capability secondaire pour confirmation/repair ciblé, jamais source principale d'ingestion. Une hydration reste nécessaire pour persister le RAW complet.

4.7 WS blockSubscribe : direct full sous contraintes

blockSubscribe peut fournir les blocs confirmed/finalized, filtrés par all ou par mentionsAccountOrProgram. Avec transactionDetails=full, il peut transporter directement les transactions nécessaires à la normalisation RAW.

La méthode reste toutefois documentée comme instable par Solana et n'est disponible que si le validator active explicitement la block subscription ainsi que l'historique transactionnel requis. KSP doit donc la traiter comme capability annoncée/testée par endpoint, pas comme propriété universelle de tout endpoint WS standard.

4.8 slotSubscribe et slotsUpdatesSubscribe

slotSubscribe fournit slot/parent/root et peut aider le worker à détecter que la chaîne avance. slotsUpdatesSubscribe fournit un lifecycle de slot plus détaillé, mais reste officiellement instable.

Aucune de ces voies ne transporte une transaction. Elles restent auxiliaires pour continuité/diagnostic et ne justifient jamais une observation Store RawTransaction seules.

4.9 Reconnect, ordering et gaps

Le protocole standard ne transforme pas une reconnexion en replay des notifications perdues. KSP Transport sait resouscrire les subscriptions logiques après reconnexion et expose un compteur de gaps de continuité, mais cela ne prouve pas quels slots/transactions ont été manqués.

Invariants de composition retenus :

reconnect WS != replay
duplicate notification = acceptable et dédupliquée par identité/contenu/observation
gap détecté = déclenche une stratégie de repair distincte
repair = HTTP slot/block ou HTTP adresse selon le scope connu

5. Inventaire KSP existant

5.1 Transport

Surface KSP	Disponible	Filtres / entrée	Provenance / remarque
get_signatures_for_address	oui	adresse + before/until/limit/commitment	aucune observation durable nécessaire pour la discovery
get_transaction_observed	oui	signature + config	provider + endpoint gagnant sûrs
get_blocks / get_blocks_with_limit	oui	range/limit + commitment	discovery de slots uniquement
get_block	oui	slot + config	GAP : pas de provider/endpoint gagnant observé
get_slot / get_first_available_block / minimum_ledger_slot	oui	bornes de continuité	auxiliaires, sans payload RAW
logs_subscribe	oui	all / allWithVotes / mentions(1 pubkey)	session snapshot fournit endpoint/provider/cluster/protocole
signature_subscribe	oui	signature connue + commitment	one-shot, terminal côté serveur
block_subscribe	oui, instable	all / mentionsAccountOrProgram + config	session snapshot fournit provenance de session
slot_subscribe / slots_updates_subscribe	oui	aucun filtre	signaux de continuité uniquement

Le runtime WS possède déjà des queues bornées. Une overflow d'une subscription lente est terminale pour cette subscription plutôt que de créer un backlog non borné. Le worker devra traiter cette terminaison comme une cause potentielle de gap et réparer avant de déclarer la continuité retrouvée.

5.2 Store

Store possède déjà les invariants nécessaires à la convergence multi-source :

RawTransactionReference = network + signature
RawTransaction          = reference + slot + block_time + payload canonique
RawTransactionObservation
RawAcquisitionProvenance
RawTransactionWrite::persist_raw_transaction_acquisition
RawTransactionObservationWrite::record_raw_transaction_observation

RawAcquisitionProvenance sait déjà conserver de manière sûre : provider, protocole, méthode, origin, endpoint logique, commitment, filter id, capture session id, timestamps et hash/taille du payload source. Aucun DTO Transport ne doit être persistant directement.

5.3 Normalisation RAW actuelle

Le premier canonicalizer RAW v1 est actuellement implémenté dans ksp-job-backfill-lib::conversion autour de getTransaction observé. Cette implémentation a démontré le format, le hash canonique, la provenance et la persistence du vertical slice Backfill, mais son ownership Job n'est pas réutilisable comme dépendance du futur Worker.

Décision de cette tranche : ne pas copier cette logique dans 0.3.10. Le handoff final devra choisir une ownership commune ou une extraction compatible avec les frontières de dépendances.

5.4 Config et réseaux

Profil	Cluster Transport	Surfaces standard	État
devnet_public	devnet	HTTP + WS standard	déjà présent
mainnet_public	mainnet-beta	HTTP + WS standard	déjà présent
mainnet_backfill_pool	mainnet-beta	HTTP pool + WS standard	déjà présent ; rôles backfill HTTP
publicnode_mainnet	mainnet-beta	HTTP + WS standard + gRPC	gRPC traité en pre.005
publicnode_testnet	testnet	HTTP + WS standard + gRPC	gRPC traité en pre.005

Les URLs et secrets restent exclusivement Config-owned. 0.3.9 n'ajoute aucun endpoint ni secret.

Canonicalisation Mainnet

L'audit interne montre une distinction existante :

profile/composite id : mainnet
network / cluster    : mainnet-beta

std.store.json et std.transport.json utilisent déjà mainnet-beta comme identité réseau/cluster. Quelques exemples/tests de Backfill utilisent encore RawNetworkId("mainnet") comme valeur synthétique. Pour l'ingestion durable, la direction retenue est de conserver mainnet-beta comme identité réseau canonique et de réserver mainnet aux identifiants de profil/UI lorsque nécessaire. Aucune migration n'est effectuée en pre.004.

5.5 Interface passive

ksp-interface-lib possède TransactionExecutionEvent et SlotLifecycleEvent, utiles lorsque plusieurs producers/consumers partagent exactement ces faits passifs. Ils ne remplacent ni les DTOs Transport riches ni RawTransaction/RawTransactionObservation et ne doivent pas être utilisés comme conteneurs d'acquisition génériques.

6. Gaps préparatoires identifiés en pre.004

ID	Owner futur	Gap / décision à matérialiser	Release cible	Motif
TR-A	Transport	ajouter une voie observée pour getBlock si le scan bloc est admis en V1	0.3.10	nécessaire pour provider/endpoint exacts dans RawTransactionObservation avec pool multi-endpoint
TR-B	Transport/ingest	définir l’extraction déterministe transaction-par-transaction depuis SolanaConfirmedBlock	0.3.10	le DTO bloc existe, la conversion RAW transactionnelle commune n’existe pas encore
RAW-A	Architecture/code owner	sortir la normalisation RAW v1 de l’enfermement Backfill sans duplication	0.3.10	la logique canonique actuelle vit dans ksp-job-backfill-lib::conversion
REC-A	Worker ingest	associer reconnect WS à une stratégie explicite de gap repair	0.3.10	resubscribe != replay ; continuity_gap_count n’identifie pas les transactions manquées
CFG-A	Config/composition	exprimer des rôles/capabilities d’acquisition, pas un simple enum HTTP/WS/gRPC	0.3.10	les profils existent déjà mais le rôle ingest multi-source n’est pas matérialisé
NET-A	Naming	retenir mainnet-beta comme identité réseau durable/configurée et mainnet seulement comme profile/UI alias	0.3.10 / 0.3.12	Store + Transport Config utilisent déjà mainnet-beta; quelques exemples/tests Backfill utilisent encore mainnet

Ces gaps sont des entrées de handoff. pre.004 ne les implémente pas.

7. Sources externes de l'audit daté

Consultées le 4 septembre 2026 :

Source Solana	URL
getSignaturesForAddress	https://solana.com/docs/rpc/http/getsignaturesforaddress
getTransaction	https://solana.com/docs/rpc/http/gettransaction
getBlocks	https://solana.com/docs/rpc/http/getblocks
getBlocksWithLimit	https://solana.com/docs/rpc/http/getblockswithlimit
getBlock	https://solana.com/docs/rpc/http/getblock
getSlot	https://solana.com/docs/rpc/http/getslot
getFirstAvailableBlock	https://solana.com/docs/rpc/http/getfirstavailableblock
minimumLedgerSlot	https://solana.com/docs/rpc/http/minimumledgerslot
logsSubscribe	https://solana.com/docs/rpc/websocket/logssubscribe
signatureSubscribe	https://solana.com/docs/rpc/websocket/signaturesubscribe
blockSubscribe	https://solana.com/docs/rpc/websocket/blocksubscribe
slotSubscribe	https://solana.com/docs/rpc/websocket/slotsubscribe
slotsUpdatesSubscribe	https://solana.com/docs/rpc/websocket/slotsupdatessubscribe

Les quotas, tiers provider et capacités Helius/Yellowstone ne sont volontairement pas documentés ici ; ils appartiennent à l'audit pre.005.

8. État après pre.004

Décisions fermées pour le standard Solana :

HTTP address discovery + hydration = admis historique/catch-up/repair
HTTP block scan                   = admis sous gap de provenance observée
WS logsSubscribe                  = admis comme live discovery + hydration
WS signatureSubscribe             = secondaire, signature déjà connue
WS blockSubscribe                 = admis sous capability explicite et instabilité
slot/ledger methods               = auxiliaires de continuité
reconnect WS                      = jamais considéré comme replay
mainnet-beta                      = identité réseau canonique à préserver

Restent ouverts pour pre.005/pre.006 : Helius, Yellowstone, autres providers, replay provider-specific, quotas/tier, stratégie multi-source V1 exacte et décision finale d'ownership du canonicalizer RAW.

9. Audit daté B — Helius, Yellowstone/providers et kbot3 historique

Audit effectué le 4 septembre 2026. Cette tranche réaudite les capacités providers et le protocole Yellowstone avec sources primaires courantes. L'archive kbot3 fournie par l'opérateur est utilisée exclusivement comme référence fonctionnelle historique ; aucun code, DTO, URL d'endpoint, Config, secret, dependency ou convention de version n'est transféré.

9.1 Helius — surfaces et tiers courants

Depuis le 31 mars 2026, Helius indique que ses WebSockets standard et enhanced sont servis par l'infrastructure LaserStream. Cela améliore l'ingestion multi-nœuds, le failover et l'ordering côté provider, mais ne change pas le contrat filaire consommé par KSP : les méthodes WSS standard/enhanced n'exposent toujours pas de from_slot adressable comme Yellowstone gRPC.

Surface	Réseau	Accès courant	Rôle RAW	Replay / continuité	Limites utiles auditées	Décision KSP
RPC HTTP standard	Mainnet + Devnet	Free+	history_discovery + hydration + gap_repair	aucun replay stream ; archive standard	RPC RPS 10 / 50 / 200 / 500 selon Free / Developer / Business / Professional	ADMIS ; réutilise les wrappers standard KSP
WSS standard LaserStream	Mainnet + Devnet	Free+	rôles WS standard de pre.004	failover/replay annoncés côté service ; pas de curseur replay KSP	5 / 150 / 250 / 1 000 connexions ; 1 000 subscriptions/connexion	ADMIS ; gap repair explicite KSP conservé
WSS transactionSubscribe	Mainnet + Devnet	Developer+	live_direct_full si transactionDetails=full	continuité provider-managed ; pas de from_slot WSS KSP	filtres include/exclude/required jusqu’à 50 000 adresses ; Developer annoncé jusqu’à 100 tx subscriptions/connexion	ADMIS spécialisé ; surface KSP déjà typée
LaserStream gRPC Yellowstone	Devnet Developer+ ; Mainnet Business+	Developer+/Business+	live_direct_full + gap_repair court	from_slot + replay explicite jusqu’à 24 h	10 M pubkeys ; 10 connexions Business, 100 Professional	PRIORITAIRE pour V1 multi-source si Config l’active
getTransactionsForAddress	archive adressée	Developer+	history_discovery + hydration combinées	pagination historique, pas stream	100 crédits/appel ; 1 000 signatures ou 100 transactions full/page	SPÉCIALISÉ backfill 0.3.12 ; option 0.3.10 non nécessaire
Preconfirmations	signal leader partiel	Professional+	signal ultra-précoce spécialisé	couverture partielle ; confirmation downstream obligatoire	10 crédits/transaction ; filtres server-side	HORS RAW canonique V1 comme source autoritative
Parsed Streams	live confirmed décodé	plans payants, beta	flux sémantique provider-decoded	beta ; pas owner RAW	décodage provider de 3 600+ programmes annoncé	HORS RAW canonique V1 ; utile plus tard côté decode

Les tarifs généraux Helius consultés affichent actuellement Free / Developer / Business / Professional à $0 / $49 / $499 / $999 par mois, avec 10 / 50 / 200 / 500 RPC RPS. Le trafic WSS et LaserStream est unifié à 20 crédits/MB. Ces valeurs sont des données d'audit datées et ne deviennent jamais des constantes KSP.

Replay WSS Helius : distinction provider/KSP

Helius annonce un replay de 24 heures et des reconnexions automatiques pour l'infrastructure LaserStream qui sous-tend désormais les WSS. KSP ne doit toutefois pas transformer cette annonce en garantie de protocole native :

provider Helius WSS : continuité/failover/replay gérés par le service
protocole WSS KSP   : aucun curseur from_slot ni fenêtre de replay explicitement demandable
conclusion KSP      : conserver gap detection + repair explicite tant que le client ne peut pas adresser la plage manquée

Cette distinction empêche de déclarer une continuité vérifiable seulement parce qu'un provider annonce une infrastructure gapless.

transactionSubscribe

transactionSubscribe est une extension Helius et non une méthode Solana standard. Avec transactionDetails=full, la notification transporte un contenu transactionnel suffisamment riche pour être candidate live_direct_full, sans hydration HTTP obligatoire. Les filtres accountInclude, accountExclude et accountRequired acceptent jusqu'à 50 000 adresses selon la documentation Helius courante.

La surface KSP correspondante existe déjà dans ksp-onchain-transport-lib avec types/filtres dédiés et HeliusLaserStreamWsSession::transaction_subscribe. Aucune nouvelle API Transport n'est requise pour la recevoir en 0.3.10; restent à définir la conversion RAW commune, la provenance ingest et la composition Config.

LaserStream gRPC

LaserStream gRPC est Yellowstone-compatible et documente explicitement fromSlot avec une rétention de replay jusqu'à 24 heures. C'est la première voie auditée qui combine :

live transaction full
filters server-side
reconnect/replay adressable par slot
gap repair court sur le même protocole
provenance provider explicite

Le tier courant est Devnet à partir de Developer et Mainnet à partir de Business. KSP possède déjà le moteur Yellowstone générique ; 0.3.10 devra donc préférer une composition provider/capability plutôt qu'une deuxième implémentation Helius gRPC. Aucun endpoint Helius gRPC n'est ajouté en 0.3.9.

getTransactionsForAddress

Helius propose aussi getTransactionsForAddress, qui combine discovery adressée et hydration avec tri ascendant/descendant, filtres temporels/slot/statut et pagination. La documentation annonce jusqu'à 1 000 signatures ou 100 transactions complètes par page, pour 100 crédits/appel, sur les plans payants.

Cette voie est principalement un candidat Backfill 0.3.12. Elle ne doit pas remplacer la primitive standard getSignaturesForAddress + getTransaction dans l'architecture générique, mais peut devenir une stratégie provider spécialisée lorsque son coût/capability est explicitement sélectionné.

Signaux Helius non retenus comme RAW canonique V1

Deux surfaces actuelles sont enregistrées sans les promouvoir comme sources RAW autoritatives :

• Preconfirmations : signal après exécution locale du leader mais avant propagation/finalité ; couverture partielle et confirmation downstream obligatoire. Le flux transporte la transaction et le statut mais ne prouve pas que le bloc deviendra canonique. Il est complémentaire aux sources on-chain normales, pas leur remplacement.
• Parsed Streams : flux confirmed déjà décodé côté provider, en beta. Il est utile pour des couches de decode/analytics futures mais ne doit pas devenir la vérité RAW canonique, précisément parce que la sémantique est transformée par le provider.

9.2 Yellowstone upstream — sémantique du protocole

Le protobuf upstream courant expose dans SubscribeRequest les maps transactions, transactions_status, blocks, blocks_meta, accounts, slots, entry, ainsi qu'un commitment, un ping et un from_slot optionnel. La présence de from_slot prouve une primitive de protocole ; elle ne prouve pas la profondeur réelle de rétention d'un provider.

Surface Yellowstone	Contenu	RAW complet	Filtres principaux	Rôle	Décision
transactions	transaction + meta/execution	oui	vote/failed/signature/account include/exclude/required + extensions proto courantes	live_direct_full	source générique V1 privilégiée
transactions_status	signature + statut/erreur/index	non	mêmes familles de filtres transactionnels	live_discovery / targeted status	hydration requise si utilisée pour RAW
blocks	bloc assemblé + transactions optionnelles	oui si include_transactions	account_include + include_transactions/accounts/entries	live_direct_full par conteneur	utile pour couverture globale ; coût/volume supérieurs
blocks_meta	métadonnées de bloc	non	tous les blocs	gap_boundary / continuity	aucune persistence RawTransaction seule
from_slot	curseur de reprise	n/a	champ SubscribeRequest	gap_repair / catch-up court	capability à qualifier par provider et rétention réelle
SubscribeReplayInfo	first_available	n/a	unary	gap_boundary	permet de borner une rétention si le provider l’implémente
SubscribeDeshred	transaction pré-exécution sans TransactionStatusMeta	partiel	vote + accounts include/exclude/required	signal précoce spécialisé	proto/client exposés ; serveur OSS standard UNIMPLEMENTED, extension Triton seulement

Les limites de filtres Yellowstone ne sont pas des constantes universelles du protocole : le serveur upstream permet de configurer des limites différentes, voire de ne pas appliquer certaines contraintes lorsque la section correspondante est absente. KSP doit donc découvrir/documenter les limites provider et garder ses propres bornes défensives.

Le changelog upstream du 22 juillet 2026 est également une alerte de conception : une régression avait accepté from_slot avec un filtre blocks tout en ne rejouant aucun bloc. La présence syntaxique du replay ne suffit donc jamais ; KSP doit caractériser la version/service provider et vérifier la reprise observée.

9.3 Replay provider par provider

Provider / voie	Réseaux prouvés	Protocole	Replay explicite audité	Applicabilité	Conclusion
Helius LaserStream gRPC	Mainnet + Devnet selon tier	Yellowstone compatible	PROUVÉ : 24 h	live_direct_full + gap_repair	provider spécialisé du standard Yellowstone ; candidat V1 prioritaire
PublicNode Yellowstone	Mainnet + Testnet	Yellowstone gRPC	NON PROUVÉ par source officielle consultée	live_direct_full	alternative générique ; KSP possède déjà profils/smokes live, replay à caractériser
OrbitFlare Yellowstone	Devnet gratuit/Developer ; accès payant au-delà	Yellowstone gRPC	NON PROUVÉ explicitement dans docs Yellowstone consultées	live_direct_full	alternative générique ; archive HTTP complète comme complément repair/history
OrbitFlare archive HTTP	historique depuis genesis annoncé	Solana HTTP standard	n/a	history + gap_repair	complément historique fort, pas remplacement du live

Pour PublicNode, la page Solana officielle du provider expose Mainnet/Testnet avec RPC, WS RPC, Yellowstone gRPC et archive disponible. Aucune source officielle consultée pendant cette tranche ne donne une profondeur from_slot, des limites de filtres ou une fenêtre de replay contractualisable. Les smokes KSP historiques prouvent le streaming live, pas le replay.

Pour OrbitFlare, la documentation Yellowstone expose transactions/slots/blocks/accounts/entries, filtres et keepalive. Le pricing courant donne gRPC Devnet sur Free/Developer, puis accès payant sur les tiers supérieurs. Les docs consultées ne matérialisent pas fromSlot dans le request de base et ne donnent pas de profondeur de replay ; cette capability reste donc NON PROUVÉE pour le provider. En revanche, OrbitFlare annonce une archive Solana complète depuis genesis via les méthodes HTTP standard, ce qui constitue un complément de repair/history indépendant du flux live.

9.4 État KSP face aux providers

L'inventaire ksp-onchain-transport-lib montre que les deux familles les plus importantes sont déjà présentes :

Helius LaserStream WSS + transactionSubscribe -> surface provider-specific déjà typée
Yellowstone gRPC standard                    -> transactions/status/blocks/meta + from_slot + replay info

Le runtime Yellowstone KSP sait conserver la dernière requête, avancer from_slot à partir du plus haut slot observé, consulter/clamp la reprise au first_available et compter gaps/duplicates/replay. Cette mécanique est générique ; elle ne doit pas être transformée en garantie de lossless/exactly-once.

La conséquence architecturale pour 0.3.10 est de réutiliser le moteur Yellowstone existant pour Helius/PublicNode/OrbitFlare lorsque leur configuration le permet, avec des descriptors/capabilities provider-specific. Le Worker ingest ne doit pas brancher directement sur des SDK providers.

9.5 Audit fonctionnel historique de kbot3

L'archive kbot3 fournie a été inspectée uniquement pour identifier des comportements déjà utiles historiquement. Les constats pertinents sont :

Domaine historique	Comportement observé	Propriété	Leçon KSP
Historique HTTP	BackfillSource::ExplicitSignatures ou AddressHistory before/after	discovery + hydration getTransaction	concept déjà refondé dans ksp-job-backfill-lib ; ne rien recopier
Pagination/reprise	page_size/max_pages + resume_before_signature + frontier contigu	reprise historique bornée	confirme l’intérêt d’un checkpoint de job, pas d’un Worker API commun
Hydration	client getTransaction sélectionné puis retries bornés	payload transaction canonique	faible failover dynamique : 0.3.10 doit préférer routing/capability multi-source explicite
Live WS	session persistante + standard subscriptions dont logsSubscribe	reconnect/resubscribe bornés	resubscribe sans replay explicite ; repair externe requis
Provenance	provider/endpoint/protocol/method/commitment/capture/filter	observation par acquisition	principe conservé par Store KSP ; aucun DTO historique repris
Fallback	pools HTTP/WS round-robin par rôle/capability	sélection initiale	utile comme référence fonctionnelle, insuffisant seul pour continuité multi-source V1

L'audit ne trouve pas de voie Yellowstone ou transactionSubscribe servant de fondation générique dans le chemin fonctionnel historique principal de kbot3. Il ne doit donc pas limiter les capabilities plus récentes déjà présentes dans KSP.

La leçon conservée est fonctionnelle seulement : séparer discovery/hydration, borner retries/concurrency, conserver une frontier de reprise contiguë pour les jobs historiques, maintenir une session live persistante, et enregistrer une provenance par acquisition. Les noms de types, structures, endpoints, secrets et implémentations de kbot3 ne sont pas réutilisés.

9.6 Relations entre les voies auditées

Les premières relations sont désormais suffisamment claires pour préparer la synthèse pre.006 :

Yellowstone transactions <-> Helius LaserStream gRPC : même famille protocolaire ; provider specialization
PublicNode Yellowstone <-> OrbitFlare Yellowstone     : alternatives provider pour live direct full
Helius transactionSubscribe <-> Yellowstone tx         : alternatives de transport, JSON spécialisé vs gRPC générique
standard logsSubscribe + getTransaction                : alternative live discovery+hydration, plus coûteuse mais très portable
Yellowstone blocks / blockSubscribe                    : alternatives par conteneur bloc pour couverture globale
Helius gTFA / OrbitFlare archive / standard HTTP       : stratégies historiques complémentaires ou alternatives pour Backfill
preconfirmations / deshred / parsed streams            : spécialisations précoces ou sémantiques, pas vérité RAW V1

La sélection V1 exacte, les priorités/fallbacks et les règles de combinaison restent volontairement ouvertes jusqu'à pre.006.

9.7 Gaps supplémentaires ouverts en pre.005

ID	Owner futur	Gap / décision	Cible	Motif
TR-C	Transport/ingest	caractériser une observation RAW commune pour transactionSubscribe et Yellowstone transaction	0.3.10	les DTOs live diffèrent mais doivent converger vers le même contenu canonique
GRPC-A	Config/composition	déclarer provider/network/capabilities Yellowstone sans SDK ni protocole provider parallèle	0.3.10	le moteur gRPC KSP est déjà générique ; seule la composition doit sélectionner le provider
GRPC-B	Ingest	ne considérer from_slot comme gap repair que si replay + first_available sont réellement supportés/observés	0.3.10	capability protocolaire != garantie de rétention provider
WS-A	Ingest	conserver un repair externe pour WSS même chez Helius tant que le replay n’est pas adressable par le client KSP	0.3.10	continuité provider-managed non équivalente à reprise déterministe KSP
CFG-B	Config	réutiliser exclusivement KSP_SECRET_HELIUS_API_KEY pour toutes les surfaces Helius sélectionnées	0.3.10	aucun second secret Helius ne doit être créé
BF-A	Backfill	évaluer gTFA/archives provider comme stratégies spécialisées derrière capabilities historiques	0.3.12	optimiser le backfill sans contaminer le Worker live

Aucun de ces gaps n'est implémenté en pre.005.

9.8 Sources externes de l'audit providers

Consultées le 4 septembre 2026 :

Source	URL
Helius — LaserStream WebSockets	https://www.helius.dev/blog/laserstream-websockets
Helius — RPC quickstart	https://www.helius.dev/docs/quickstart
Helius — WebSocket quickstart	https://www.helius.dev/docs/rpc/websocket/quickstart
Helius — pricing	https://www.helius.dev/pricing
Helius — rate limits	https://www.helius.dev/docs/billing/rate-limits
Helius — LaserStream gRPC	https://www.helius.dev/blog/introducing-laserstream
Helius — getTransactionsForAddress	https://www.helius.dev/blog/introducing-gettransactionsforaddress
Helius — Enhanced WebSockets	https://www.helius.dev/blog/introducing-next-generation-enhanced-websockets
Helius — Preconfirmations	https://www.helius.dev/blog/solana-preconfirmations
Helius — Parsed Streams	https://www.helius.dev/blog/parsed-events-and-streams
Yellowstone — protobuf	https://github.com/rpcpool/yellowstone-grpc/blob/master/yellowstone-grpc-proto/proto/geyser.proto
Yellowstone — README	https://github.com/rpcpool/yellowstone-grpc/blob/master/README.md
Yellowstone — changelog	https://github.com/rpcpool/yellowstone-grpc/blob/master/CHANGELOG.md
PublicNode — Solana	https://solana.publicnode.com/
OrbitFlare — Yellowstone docs	https://docs.orbitflare.com/data-streaming/yellowstone
OrbitFlare — pricing	https://orbitflare.com/pricing
OrbitFlare — archive	https://orbitflare.com/products/historical-data
OrbitFlare — gRPC	https://orbitflare.com/products/solana-grpc

Les URLs ci-dessus sont des sources documentaires. Aucun endpoint runtime provider n'est ajouté ou modifié dans KSP par cette tranche.

10. État après pre.005

Décisions fermées par l'audit B :

Helius standard WSS              = admis, continuité provider-managed mais repair KSP conservé
Helius transactionSubscribe      = admis comme live_direct_full spécialisé
Helius LaserStream gRPC          = admis comme Yellowstone provider + replay 24 h prouvé
Yellowstone transactions         = source générique live_direct_full prioritaire
Yellowstone transaction_status   = signal/status incomplet ; hydration requise pour RAW
Yellowstone blocks               = direct full si transactions incluses
Yellowstone blocks_meta          = continuité seulement
from_slot                        = capability à qualifier provider par provider
PublicNode replay                = non prouvé par docs officielles consultées
OrbitFlare replay gRPC           = non prouvé ; archive HTTP depuis genesis prouvée
kbot3                            = référence fonctionnelle seulement, aucune source de code/Config

La synthèse pre.006 doit maintenant convertir ces faits en matrice complète, stratégie multi-source V1, priorités/fallbacks et handoff exact 0.3.10 / 0.3.12.

11. Synthèse multi-source exhaustive — pre.006

Synthèse effectuée le 4 septembre 2026. Cette section transforme les audits A/B en contrat de handoff. Son principe directeur est volontairement plus large que le périmètre actuellement testable : une possibilité documentée n'est pas exclue parce que KSP ne dispose pas encore du tier, du compte ou de l'endpoint permettant de la prouver en live.

Trois axes doivent toujours rester séparés :

possibilité connue = le protocole, le provider ou une infrastructure opérateur peut fournir la voie
support KSP        = KSP possède déjà ou prévoit explicitement l'adapter/capability correspondant
preuve KSP         = cette voie a effectivement été exercée avec un endpoint accessible et un résultat attendu

En particulier :

NON PROUVÉ != REJETÉ
PAYANT/BLOQUÉ != NON SUPPORTÉ
IMPLÉMENTÉ != PROUVÉ LIVE
PROUVÉ CHEZ UN PROVIDER != GARANTI CHEZ TOUS LES PROVIDERS DU MÊME PROTOCOLE

11.1 Légende de décision et de preuve

Code	Sens
ADMIS	voie à représenter dans le socle KSP ; l'activation dépend ensuite des capabilities/configurations réelles
SPÉCIALISÉ	voie utile mais non nécessaire au socle générique ; adapter provider/source autorisé sans contaminer les contrats communs
BACKFILL	voie principalement destinée au Job historique/catch-up
EARLY	signal précoce ou corps transactionnel incomplet ; jamais vérité RAW v1 complète sans hydration/confirmation
SUNSET	voie historique à documenter mais sur laquelle aucune nouvelle implémentation KSP ne doit être engagée
EXISTANT	surface KSP nécessaire déjà présente
PLANIFIÉ	surface/adaptation à réaliser dans la release indiquée
PROUVÉ	comportement exercé par KSP ou preuve provider/protocole suffisamment directe pour la propriété considérée
TESTABLE	accès actuel disponible permettant un smoke live, mais preuve KSP encore à produire
NON PROUVÉ	possibilité admise mais propriété provider/non-régression non démontrée
BLOQUÉ TIER	branche architecturale admise mais live test impossible avec les comptes actuels
À REVALIDER	documentation provider incohérente, évolutive ou insuffisante ; ne pas encoder la valeur comme garantie

11.2 Matrice exhaustive des familles de sources RAW

Cette matrice est source-family first : un provider peut remplir plusieurs lignes, et une ligne peut être fournie par plusieurs providers. C'est cette séparation qui interdit un enum simpliste Http | WebSocket | Grpc comme modèle de configuration du worker.

Famille / méthode	Réseaux possibles	Temporalité	Découverte / contenu reçu	RAW v1 complet ?	Replay / repair	Worker 0.3.10	Backfill 0.3.12	Décision
HTTP getTransaction(signature)	tout cluster RPC	hydration / repair / historique	signature connue -> transaction	oui si réponse disponible	dépend de la rétention/archive RPC	oui	oui	ADMIS
HTTP getSignaturesForAddress + getTransaction	tout cluster RPC	catch-up / historique ciblé	discovery adresse puis hydration	oui après hydration	pagination par signatures	repair ciblé	oui	ADMIS
HTTP getBlocks / getBlocksWithLimit + getBlock	tout cluster RPC	catch-up / gap / historique	discovery slots puis blocs	oui avec transactionDetails=full	fenêtre ledger/archive provider	oui	oui	ADMIS
HTTP getBlock(slot)	tout cluster RPC	repair / historique ciblé	slot connu -> bloc	oui avec transactionDetails=full	fenêtre ledger/archive provider	oui	oui	ADMIS
HTTP bornes getSlot / getFirstAvailableBlock / minimumLedgerSlot	tout cluster RPC	continuité	aucune transaction	non	borne seulement	auxiliaire	auxiliaire	ADMIS
API historique provider getTransactionsForAddress ou équivalent	provider-dependent	historique ciblé	discovery + éventuellement transaction full	provider-dependent	archive provider	optionnel	oui	SPÉCIALISÉ
WS standard logsSubscribe + hydration HTTP	Mainnet/Devnet/Testnet si exposé	live	signature/logs	non ; hydration requise	resubscribe sans replay adressable	oui	non principal	ADMIS
WS standard signatureSubscribe + hydration	Mainnet/Devnet/Testnet si exposé	live ciblé	statut d'une signature déjà connue	non ; hydration requise	one-shot	ciblé	non principal	ADMIS
WS standard blockSubscribe full	provider/validator-dependent	live global/filtré	bloc + transactions	oui si full	reconnect ; repair externe	oui	non principal	ADMIS
WS provider transactionSubscribe full	provider-dependent	live filtré/global selon offre	transaction + meta	oui	provider-managed ou repair externe	oui	non principal	SPÉCIALISÉ
Yellowstone transactions	tout réseau exposé par endpoint	live	transaction exécutée + meta	oui	from_slot si provider le sert	oui	oui/replay	ADMIS
Yellowstone blocks + transactions	tout réseau exposé par endpoint	live / replay	bloc + transactions	oui	from_slot si provider le sert	oui	oui/replay	ADMIS
Yellowstone transactions_status + hydration	tout réseau exposé par endpoint	live	signature/status/error	non ; hydration requise	from_slot provider-dependent	oui	optionnel	ADMIS
Yellowstone blocks_meta / slots	tout réseau exposé par endpoint	continuité	slots/bloc meta sans tx full	non	aide à détecter/borner gaps	auxiliaire	auxiliaire	ADMIS
Yellowstone from_slot + SubscribeReplayInfo	provider-dependent	replay récent / catch-up	même stream depuis slot demandé	selon famille souscrite	profondeur provider-specific	oui	oui	ADMIS
stream persistant provider compatible Yellowstone	provider-dependent	live + reprise durable	transaction/account/entry selon produit	oui pour transaction full	provider-managed persistant	oui	oui/replay	SPÉCIALISÉ
shred/pre-exec -> transaction reconstruite + hydration	surtout Mainnet, provider-dependent	ultra-live	shreds ou transaction avant exécution	non : meta d'exécution absente	aucun replay canonique implicite	oui, phase 2	non principal	EARLY
transaction body extraite de shreds + hydration	surtout Mainnet, provider-dependent	ultra-live	signature/corps tx	non : meta d'exécution absente	source-dependent	oui, phase 2	non principal	EARLY
Agave RPC auto-hébergé	Mainnet/Devnet/Testnet/local/custom	live + ledger local	toutes méthodes activées	oui selon méthode	rétention opérateur	oui	oui	ADMIS
Agave + Yellowstone Geyser auto-hébergé	Mainnet/Devnet/Testnet/local/custom	live	mêmes familles Yellowstone	oui pour tx/blocks full	rétention/plugin opérateur	oui	oui	ADMIS
Old Faithful / yellowstone-faithful via JSON-RPC	Mainnet ; indexes Testnet/Devnet	archive historique	getBlock/getTransaction/GSFA/getBlocks	oui pour données archivées	historique par epochs	repair froid	oui	BACKFILL
archive provider exposée via RPC standard	provider/network-dependent	archive historique	mêmes RPC standard	oui	rétention provider	repair froid	oui	BACKFILL
substrat archive direct CAR/Filecoin/S3/Bigtable	source-dependent	archive historique	format stockage, pas API KSP standard	potentiellement	intégralité dépend du dataset	non V1 direct	futur possible	SPÉCIALISÉ

Les lignes EARLY sont volontairement incluses dans le socle de possibilités. Elles peuvent alimenter une file de discovery/hydration et fournir un avantage de latence, mais elles ne doivent pas créer un RawTransaction canonique complet tant que les métadonnées d'exécution nécessaires n'ont pas été observées ou hydratées.

11.3 Matrice providers / réseaux / prix / preuve

Les prix et tiers ci-dessous sont des données datées au 4 septembre 2026. Ils guident les tests et la composition ; ils ne deviennent ni constantes Rust ni règles de validation KSP. ? signifie que la source officielle consultée ne suffit pas à contractualiser la propriété.

Provider / infrastructure	Réseaux documentés utiles	Standard HTTP/WSS	Yellowstone / stream full	Historique / replay	Prix / tier utile au 04-09-2026	Accès KSP actuel	Preuve / décision KSP
Solana public RPC	Mainnet-beta, Devnet, Testnet	oui	non	ledger public borné	gratuit ; fortement rate-limité ; non destiné production	oui	PROUVÉ/TESTABLE standard ; baseline seulement
provider RPC standard générique	selon provider	oui si méthodes exposées	éventuel	selon provider	variable	oui selon compte	ADMIS par capabilities, jamais par nom de provider
Agave auto-hébergé	Mainnet/Devnet/Testnet/local/custom	oui	Yellowstone si plugin installé	ledger/rétention opérateur	coût infrastructure opérateur	non actuellement	ADMIS, NON PROUVÉ en environnement KSP actuel
Helius	Mainnet + Devnet	Free+	Devnet Developer+ ; Mainnet Business+	LaserStream 24 h ; history API	Free $0 ; Developer $49 ; Business $499 ; Professional $999	HTTP/WSS gratuit	standard TESTABLE; gRPC Mainnet BLOQUÉ TIER; 24 h provider PROUVÉ par docs
PublicNode	Mainnet + Testnet	gratuit	Yellowstone gRPC gratuit	archive accessible sur demande ; replay depth ?	gratuit pour endpoint public ; archive prix/conditions non publiés dans source auditée	Mainnet gRPC + RPC disponibles	gRPC Mainnet TESTABLE/PROUVÉ par smokes antérieurs ; profondeur replay NON PROUVÉE
OrbitFlare	Mainnet + Devnet	oui	Devnet Free/Developer ; Mainnet add-on/Pro	archival data incluse ; profondeur gRPC ?	Free $0 ; Developer $49 ; Growth $399 ; Scale $799 ; Pro $999 ; Mainnet gRPC +$500	Devnet gratuit possible	TESTABLE Devnet ; Mainnet payant ; replay gRPC NON PROUVÉ
QuickNode	Mainnet-beta, Testnet, Devnet	oui	Scale/Business ou add-on	fromSlot jusqu'à 3000 slots ; archive selon réseau	Scale $499 ; Business $999 ; add-on possible Build/Accelerate	pas de tier gRPC actuel	BLOQUÉ TIER; protocole ADMIS; replay provider documenté
Alchemy	Mainnet + Devnet	oui	Yellowstone gRPC PAYG/Enterprise	replay documenté mais pages contradictoires	$75/TB gRPC ; accès PAYG/Enterprise	standard gratuit possible	gRPC BLOQUÉ/À REVALIDER; 6000 vs ~432000 slots dans docs : ne rien figer
Chainstack	Mainnet + Devnet RPC ; gRPC Mainnet	Free Developer + plans payants	add-on Yellowstone Growth+	archive Growth+ ; replay gRPC ?	Developer $0 ; Growth $49 ; gRPC $49/2, $149/7, $449/25 streams	standard gratuit possible	standard TESTABLE; gRPC BLOQUÉ TIER; replay NON PROUVÉ
Shyft	Mainnet + Devnet RPC ; gRPC réseau à qualifier	Free RPC	Build/Grow/Accelerate Yellowstone	replay jusqu'à 150 slots	Free $0 ; Build $199 ; Grow $349 ; Accelerate $649	RPC gratuit possible	standard TESTABLE; gRPC BLOQUÉ TIER; replay 150 slots documenté
Triton One	Solana ; réseau par endpoint	oui / Whirligig	Dragon's Mouth/Riptide/Fumarole	Fumarole persistant ; Old Faithful full history	dépôt PAYG $125 ; streaming $0.08/GB ; RPC $0.08/GB + $10/M calls	pas de compte actuel	BLOQUÉ TIER; architecture ADMIS; historique Old Faithful également auto-hébergeable
dRPC	Solana ; réseau gRPC à qualifier	HTTP/WSS	Yellowstone gRPC Premium/Advanced	replay depth ?	Premium $399 : 25 streams/5 TB ; Advanced $599 : 50 streams/10 TB	standard éventuellement	gRPC BLOQUÉ TIER; replay NON PROUVÉ; docs récentes supplantent comparatifs anciens
Ankr	Mainnet + Devnet	Freemium/Premium HTTP + WSS	Solana Yellowstone non prouvé par docs chain-specific	ledger rolling ; archive générique annoncée	Solana RPC/WSS $0.00005 par request/subscription/notification	freemium possible	standard TESTABLE; ne pas inférer gRPC Solana depuis pricing gRPC générique
GetBlock	Mainnet-beta + Devnet	Free+ HTTP/WSS	Yellowstone sur dedicated/add-on	archive selon plan	Free $0 ; Starter $49 ; Advanced $199 ; Pro $499 ; Enterprise $999 ; dedicated +gRPC	standard gratuit possible	standard TESTABLE; gRPC paid NON PROUVÉ
autre Yellowstone-compatible	provider/network-dependent	variable	oui si protocole compatible	provider-dependent	inconnu	non	ADMIS via descriptor/capabilities ; aucun code provider requis si protocole standard

Cas Alchemy : documentation de replay contradictoire

Les sources Alchemy courantes ne sont pas cohérentes entre elles : certaines pages Yellowstone mentionnent environ 6000 slots, tandis que la page dédiée « Historical Replay » annonce from_slot dans les ~432 000 derniers slots (~48 h). KSP doit donc représenter la capability replay comme qualifiée au runtime/test, et non encoder une constante Alchemy dans Config ou le Worker.

11.4 Sources ultra-low-latency / pre-execution à garder dans le socle

Source	Transport	Réseau / accès courant	Contenu utile	Meta d'exécution ?	Prix / accès daté	Usage KSP proposé
Helius Shred Delivery UDP	UDP shreds	Mainnet, beta/qualified	shreds bruts	non	Professional+/accès qualifié ; prix non figé	EARLY discovery ; deshred + hydration
Helius preprocessed transactions	gRPC	Helius Shred Delivery	transaction décodée ~pré-processed	non	Professional+ ; 20 crédits/MB	EARLY body/signature -> hydration
OrbitFlare Jetstream	gRPC basé shreds	provider-dependent	transaction faible latence, sans full meta	non	gRPC depuis $500/mo selon offre	EARLY -> hydration ; Yellowstone reste voie full
Shyft RabbitStream	gRPC depuis shreds	provider-dependent, payant	transactions extraites des shreds	non/à confirmer	Build+ ($199+)	EARLY -> hydration
Triton Deshred	extension gRPC	shared/dedicated Triton	transaction reconstruite avant replay/exécution	non	inclus dans offre streaming PAYG	EARLY -> hydration ; extension spécialisée
Triton Shred Streaming	shred stream	Triton	shreds	non	$1500/mo/IP/datacenter	EARLY phase avancée
bloXroute Transaction Streamer	gRPC	Solana	signature + bytes transaction + slot	non	$500/mo	EARLY body -> hydration
bloXroute Shreds	UDP/gateway	Solana	shreds	non	$500/mo	EARLY phase avancée
DoubleZero Edge	UDP multicast	feed Solana shreds	shreds bruts	non	$450/$900/$1500 par machine/mo selon metro	successeur shred générique à prévoir ; deshred + hydration
Jito ShredStream	shreds/local decode	Solana	shreds -> transactions	non	sunset	SUNSET le 5 septembre 2026 ; aucune nouvelle implémentation KSP V1
Turbine/shred feed auto-opéré	UDP/local	cluster opéré	shreds bruts	non	coût infra	possibilité générique future, jamais provider hardcodé

Le lendemain de cet audit, 5 septembre 2026, Jito prévoit l'arrêt complet de ShredStream et recommande explicitement DoubleZero Edge. La ligne Jito est conservée pour exhaustivité/historique et migration, pas comme cible d'implémentation nouvelle.

11.5 Matrice réseau et stratégie de preuve

Le support KSP doit être network-neutral au niveau des stratégies. La preuve live, elle, est pragmatique et utilise les accès disponibles.

Réseau logique KSP	Preuves prioritaires avec accès actuel	Branches complémentaires possibles	Règle KSP
mainnet-beta	HTTP/WS standard multi-provider ; PublicNode Yellowstone gRPC ; Helius standard HTTP/WSS	Helius gRPC payant, QuickNode/Alchemy/Chainstack/Shyft/Triton/dRPC/GetBlock	réseau canonique Store/identité ; mainnet peut rester alias de profil/UI
devnet	Solana public HTTP/WS ; Helius standard ; OrbitFlare Yellowstone gratuit ; autres providers gratuits	Helius LaserStream Developer+, Alchemy gRPC, self-host	meilleur terrain pour canaries protocole sans coût Mainnet
testnet	Solana public HTTP/WS ; PublicNode RPC/WS/Yellowstone	self-host / providers qui exposent Testnet	utile pour caractériser comportements distincts sans supposer disponibilité chez tous les vendors
local/custom	Agave local + éventuellement Yellowstone plugin	fixtures et serveurs contrôlés	permet de prouver erreurs, replay, gaps et backpressure sans dépendance fournisseur

Le plan de preuve 0.3.10/0.3.12 doit donc avoir trois étages :

1. tests déterministes fixtures/mock pour chaque adapter admis
2. smokes live opt-in sur les combinaisons gratuites/accessibles
3. smokes live opt-in BLOQUÉS/IGNORÉS pour les branches payantes jusqu'à disponibilité du tier

Une branche peut être livrée comme support implémenté non prouvé live si ses contrats déterministes, son parsing, ses bornes, son redaction et ses erreurs sont testés, à condition que la documentation et les capabilities ne la présentent pas comme validée live.

11.6 Handoff 0.3.10 — modèle de sources du Worker live

ksp-worker-raw-transaction-ingest-lib doit être multi-source dès V1, mais ne doit pas exposer un enum protocol/provider fermé. La composition construit une collection de stratégies selon rôles/capabilities.

Capabilities minimales retenues :

live_direct_transaction      reçoit une transaction exécutée complète
live_direct_block            reçoit un bloc contenant les transactions complètes
live_transaction_discovery   reçoit signature/référence, nécessite hydration
live_early_transaction       reçoit shreds/corps pré-exécution, nécessite hydration/confirmation
transaction_hydration        résout une signature en transaction complète
block_hydration              résout un slot en bloc complet
gap_boundary                 observe slot/first_available/ledger bounds
gap_repair_scan              reconstruit une plage via slots/blocs/requêtes HTTP
replay_transaction_stream    reprend un stream full depuis un slot
replay_block_stream          reprend un stream block depuis un slot

Chaque stratégie déclare séparément :

network
role/capabilities
provider + endpoint identity safe
protocol + method/source code
commitment/finality support
filter capabilities and bounds
live/catch-up/history applicability
replay support: none | provider_managed | requested_from_slot
replay first-available observability
runtime admission limits
proof status (metadata/doc only, jamais secret)

Le Worker ne doit pas lire une valeur de prix pour décider du runtime. Prix/tier servent à la documentation et au choix de profil par l'opérateur ; Config sélectionne uniquement des endpoints/capabilities effectivement autorisés.

Ensemble V1 à implémenter autant que possible

Le socle V1 0.3.10 doit viser les adapters suivants, même si certains smokes live restent bloqués :

1. Yellowstone transactions full ;
2. Yellowstone blocks full ;
3. Yellowstone transactions_status + hydration ;
4. Yellowstone replay from_slot qualifié par SubscribeReplayInfo/provider ;
5. WS standard blockSubscribe full ;
6. WS standard logsSubscribe + HTTP getTransaction ;
7. Helius transactionSubscribe full via la surface Transport existante ;
8. HTTP block scan getBlocks/getBlock comme gap repair global ;
9. HTTP signature hydration observée getTransaction ;
10. au moins un hook/adaptor contract EARLY source-neutral, sans obliger l'implémentation UDP/shred de tous les vendors dans la première tranche.

Les sources EARLY vendor-specific peuvent être matérialisées progressivement derrière ce contrat commun. Elles ne doivent pas retarder la fermeture du socle full-transaction si leur accès payant/UDP demande une release dédiée.

11.7 Orchestration multi-source : complément, redondance et fallback

Les stratégies ne sont pas mutuellement exclusives. Le runtime doit accepter :

Yellowstone transactions --------------------+
Helius transactionSubscribe -----------------+--> normalisation commune --> Store
blockSubscribe full --------------------------+
logsSubscribe --+                             |
                +--> HTTP getTransaction -----+
EARLY source ----+--> hydration/confirmation -+

Une source directe full et une source discovery peuvent fonctionner simultanément. Une source de replay peut être inactive tant qu'aucun gap n'est détecté. Une source archive peut être réservée au Job mais réutilisée comme dernier recours de repair explicite si la politique du caller l'autorise.

Le fallback ne doit pas être codé comme « si gRPC échoue alors WS sinon HTTP ». Il doit sélectionner une autre stratégie offrant la capability manquante sur le même réseau, en tenant compte des limites et de la disponibilité runtime.

11.8 Déduplication de contenu vs observations de provenance

Identité canonique inchangée :

RawTransaction identity = (network, signature)

La source, le provider, le protocole et l'endpoint ne font jamais partie de cette identité.

Règle multi-source :

même (network, signature) + mêmes bytes canoniques
    -> une RawTransaction
    -> plusieurs RawTransactionObservation utiles/autonomes

même (network, signature) + bytes canoniques incompatibles
    -> conflit explicite
    -> jamais "le premier provider gagne" silencieusement

La déduplication de la transaction ne doit donc pas supprimer la provenance. Une observation provenant de PublicNode gRPC et une observation Helius WSS de la même transaction peuvent toutes deux être persistées si leurs clés d'observation sont distinctes et utiles.

Pour les signaux EARLY, aucun RawTransactionObservation complet ne doit être fabriqué si le contrat Store exige une acquisition complète. Le Worker peut conserver une référence interne bornée vers l'hydration, puis produire la provenance finale avec la chaîne de discovery/hydration requise par le futur contrat commun.

11.9 Stratégie de gap repair

Le Worker doit détecter la continuité à partir des slots/block meta/stream snapshots, mais ne jamais déduire « aucun gap » de la seule reconnexion d'un client.

Ordre fonctionnel proposé, piloté par capabilities et non par provider :

A. replay natif adressable depuis le dernier frontier si provider qualifié
   -> Yellowstone from_slot + first_available/replay info

B. source live redondante ayant déjà observé la plage
   -> dédup par Store/provenance

C. scan HTTP global par slots
   -> getBlocks/getBlocksWithLimit + getBlock observed

D. hydration ciblée des signatures déjà découvertes
   -> getTransaction observed

E. archive/historical source si la fenêtre live est perdue
   -> provider archive / Old Faithful / autre stratégie Backfill

Le niveau E peut être exécuté par le Worker pour un repair court seulement si le contrat final 0.3.10 reste simple ; sinon il délègue explicitement une campagne de Job. Aucune dépendance Worker -> Job n'est autorisée.

11.10 Handoff Transport 0.3.10

Gaps confirmés à traiter après cet audit :

ID	Adaptation Transport proposée	Pourquoi
TR-B	ajouter un get_block_observed symétrique de get_transaction_observed	provenance provider/endpoint exacte lors d'un scan bloc multi-endpoint
TR-C	fournir un chemin de projection source-neutral des transactions full issues de WS Helius et Yellowstone	éviter que Worker possède deux canonicalizers filaires concurrents
TR-D	exposer proprement les métadonnées sûres d'une acquisition live au moment de la conversion, sans URL/secret	produire RawTransactionObservation uniforme
TR-E	conserver from_slot, SubscribeReplayInfo, snapshot reconnect/gap et provider/cluster/endpoint déjà disponibles	ces primitives sont suffisantes ; ne pas créer un second moteur Yellowstone
TR-F	adapter les families EARLY seulement quand leur protocole est réellement implémenté ; ne pas forcer UDP/shred dans Transport V1	le socle doit réserver la capability sans introduire prématurément tous les clients vendor-specific

Aucun SDK provider n'est nécessaire pour HTTP/WS/Yellowstone lorsque les surfaces actuelles KSP suffisent. Les extensions non standard doivent rester derrière un adapter explicite et une capability, pas une branche globale dans le Worker.

11.11 Handoff Config 0.3.10

Config doit rester propriétaire des endpoints/secrets et permettre plusieurs sources simultanées. Le modèle cible doit exprimer des routes/capabilities par réseau, par exemple :

source id                 = identité de composition stable
network                   = mainnet-beta / devnet / testnet / custom
transport endpoint ref    = HTTP / WS / gRPC déjà enregistré dans Config
roles                     = live_direct, discovery, hydration, replay, gap_repair...
priority / enabled        = politique de composition
filters                   = références sûres/typed settings si nécessaires

Contraintes fermées :

• ne pas copier les prix/tiers provider dans Config comme logique runtime ;
• ne pas hardcoder une liste fermée de providers dans le Worker ;
• réutiliser uniquement KSP_SECRET_HELIUS_API_KEY pour toutes les surfaces Helius qui en ont besoin ;
• permettre plusieurs endpoints d'un même protocole/provider et plusieurs providers sur le même réseau ;
• conserver mainnet-beta comme identité réseau canonique de transaction ; mainnet reste un alias de profil/composition si nécessaire ;
• rejeter avant démarrage une source dont la capability demandée n'est pas réellement offerte par son endpoint/configuration.

11.12 Ownership commun de la normalisation RAW

Le besoin Worker + Backfill ferme RAW-A : la canonicalisation RAW v1 ne doit rester ni enfermée dans le Job ni être copiée dans le Worker.

Le handoff retient une petite crate commune à créer en 0.3.10 :

ksp-raw-transaction-lib
    -> ksp-core-lib
    -> ksp-store-lib       # default-features = false ; aucun backend imposé
    -> serde_json / sha2 si le format v1 actuel les exige

Responsabilités :

format id/version RAW Transaction KSP
entrée source-neutral transaction complète
canonical payload bytes + content hash
construction RawTransaction
construction/projection de provenance et observation à partir de métadonnées sûres fournies par le caller
validation réseau/signature/slot/meta/version/index commune
aucun runtime
aucun réseau
aucune Config
aucun scheduler/job/worker
aucun backend Store physique

Les adapters Worker/Backfill restent responsables de transformer les DTOs Transport/provider en matériau source-neutral. Ainsi ksp-raw-transaction-lib n'a pas besoin de dépendre de ksp-onchain-transport-lib, et aucune dépendance inverse Transport -> Store n'est créée.

Graphe cible :

ksp-job-backfill-lib ------------------+
                                      +--> ksp-raw-transaction-lib --> ksp-store-lib
ksp-worker-raw-transaction-ingest-lib -+

les deux consumers dépendent aussi de ksp-onchain-transport-lib pour leurs adapters respectifs

La migration de la conversion déjà prouvée dans ksp-job-backfill-lib vers cette crate doit être faite avec golden bytes/hash inchangés et tests de non-régression. Aucun nouveau format RAW v2 n'est justifié.

11.13 Handoff 0.3.12 — stratégies Backfill à ajouter

ksp-job-backfill-lib doit conserver son premier vertical HTTP adressé, puis devenir multi-stratégie sans changer ksp-job-api pour des notions Solana.

Stratégie historique	Réseaux	Direct/full ou hydration	Source typique	Admission 0.3.12
GSFA + getTransaction	tout RPC	discovery + hydration	Solana standard / tous providers	déjà existante
getBlocks/getBlocksWithLimit + getBlock	tout RPC	full par bloc	standard/archive RPC	oui
liste de signatures explicites + getTransaction	tout RPC	hydration	tout provider	déjà existante
Yellowstone from_slot transactions	provider replay-capable	direct full	Helius/QuickNode/Shyft/etc selon tier	oui
Yellowstone from_slot blocks	provider replay-capable	direct full bloc	provider-compatible	oui
Helius getTransactionsForAddress	Helius networks	full ou signatures selon mode	Helius history API	oui spécialisé
provider archive via RPC standard	provider-dependent	standard	OrbitFlare/QuickNode/Chainstack/Triton/etc	oui
Old Faithful / yellowstone-faithful	surtout Mainnet	standard historical RPC	self-host/Filecoin/Triton	oui expérimental
substrat archive direct	dataset-dependent	adapter spécifique	CAR/Filecoin/S3/Bigtable	futur, non V1

Le Job doit pouvoir déclarer la stratégie choisie et son checkpoint spécifique, mais ne doit jamais devenir un « Worker arrêté après N éléments ». Ses campagnes restent bornées et terminables.

11.14 Priorité d'implémentation vs exhaustivité du socle

L'exhaustivité de la matrice ne signifie pas que toutes les intégrations vendor-specific doivent être codées simultanément dans la première prerelease de 0.3.10.

Ordre recommandé :

P0 : normalisation RAW commune + observed getBlock + adapters standard
P0 : Yellowstone transactions/blocks + replay qualifié
P0 : WS logsSubscribe + hydration + blockSubscribe full
P0 : Helius transactionSubscribe déjà supporté par Transport
P1 : multi-source concurrency/dedup/provenance/gap repair
P1 : smokes Mainnet/Devnet/Testnet accessibles gratuitement
P2 : provider-specific history/replay adapters payants
P2 : EARLY transaction-body/deshred abstraction + premiers adapters disponibles
P3 : UDP/raw-shred direct et archives de substrat lorsque besoin/accès justifiés

Cette priorité est une stratégie de réalisation ; toutes les lignes ADMIS restent dans le modèle de capabilities afin de ne pas enfermer l'architecture dans les seuls comptes gratuits disponibles en septembre 2026.

11.15 Sources externes complémentaires de la synthèse

Consultées le 4 septembre 2026, en complément des sources des sections 7 et 9.8 :

Source	URL
Solana — clusters/public RPC	https://solana.com/docs/references/clusters
QuickNode — Yellowstone guide	https://www.quicknode.com/guides/solana-development/tooling/solana-grpc/solana-grpc
QuickNode — gRPC plans	https://www.quicknode.com/blog/solana-grpc-is-now-included-with-scale-and-business-plans
Alchemy — Solana gRPC	https://www.alchemy.com/solana-grpc
Alchemy — Yellowstone quickstart	https://www.alchemy.com/docs/reference/yellowstone-grpc-quickstart
Alchemy — historical replay	https://www.alchemy.com/docs/reference/yellowstone-grpc-historical-replay
Alchemy — compute/bandwidth costs	https://www.alchemy.com/docs/reference/compute-unit-costs
Chainstack — Yellowstone add-on	https://chainstack.com/yellowstone-grpc-more-streams-same-price/
Shyft — Yellowstone gRPC	https://shyft.to/solana-yellowstone-grpc
Shyft — pricing	https://shyft.to/solana-rpc-grpc-pricing
Shyft — RabbitStream	https://shyft.to/solana-shreds-rabbitstream
Triton — pricing	https://triton.one/pricing
Triton — Yellowstone overview	https://blog.triton.one/complete-guide-to-solana-streaming-and-yellowstone-grpc/
Triton — Fumarole	https://blog.triton.one/introducing-yellowstone-fumarole/
Triton — Deshred	https://blog.triton.one/deshred-transactions-the-fastest-path-to-solana-data/
dRPC — Solana Yellowstone	https://drpc.org/docs/solana-yellowstone-geyser-grpc
Ankr — Solana support	https://www.ankr.com/docs/rpc-service/chains/chains-list/s-t/
Ankr — pricing	https://www.ankr.com/docs/rpc-service/pricing/
GetBlock — pricing	https://getblock.io/pricing-new/
bloXroute — pricing	https://bloxroute.com/pricing/
Helius — data streaming	https://www.helius.dev/docs/data-streaming
Helius — preprocessed transactions	https://www.helius.dev/docs/shred-delivery/preprocessed-transactions
Jito — ShredStream sunset	https://docs.jito.wtf/lowlatencytxnfeed/
DoubleZero Edge — shreds	https://docs.malbeclabs.com/Edge%20Subscriber%20Connection/
Yellowstone Old Faithful	https://github.com/rpcpool/yellowstone-faithful
PublicNode — Solana	https://solana.publicnode.com/
OrbitFlare — RPC plans	https://orbitflare.com/products/rpc-nodes
OrbitFlare — gRPC	https://orbitflare.com/products/solana-grpc

Les URLs sont documentaires. Aucun endpoint runtime, token, secret ou identifiant de compte n'est introduit dans KSP par pre.006.

12. État après pre.006

La synthèse ferme les décisions architecturales suivantes :

catalogue de possibilités       = exhaustif par familles ; non limité aux preuves gratuites actuelles
support vs preuve               = axes distincts ; NON PROUVÉ n'implique jamais REJETÉ
Worker V1                       = multi-source par capabilities, pas enum protocole/provider
full live                       = Yellowstone tx/blocks, blockSubscribe full, Helius transactionSubscribe
portable live                   = logsSubscribe + getTransaction observed
repair                          = replay qualifié -> redondance -> block scan observed -> hydration -> archive
EARLY                           = admis comme discovery/body, jamais RAW v1 complet sans meta d'exécution
canonicalisation                = nouvelle crate commune ksp-raw-transaction-lib en 0.3.10
Transport                       = get_block_observed + projection/provenance commune à adapter en 0.3.10
Config                          = plusieurs sources/endpoints/capabilities par réseau ; prix hors runtime
Helius secret                   = réutilisation unique de KSP_SECRET_HELIUS_API_KEY
network identity                = mainnet-beta canonique ; mainnet alias de composition seulement
Backfill 0.3.12                 = block scan + replay Yellowstone + archives/provider history + Old Faithful
preuves                         = fixtures déterministes + smokes gratuits + smokes payants ignorés jusqu'à accès

0.3.9 n'implémente aucune de ces adaptations. La release a maintenant fourni l'audit nécessaire ; les changements de code commencent en 0.3.10 après le gate final, la réconciliation documentaire et la publication de 0.3.9.