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

v0.3.9-pre.006

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-05 00:10:15 +02:00
parent e85d6f6963
commit e6c2649410
5 changed files with 568 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
Cargo.toml
View File

@@ -1,12 +1,12 @@
# file: Cargo.toml # file: Cargo.toml
# version: 482 # version: 483
[workspace] [workspace]
resolver = "3" resolver = "3"
members = ["crates/ksp-app-backfill-desk", "crates/ksp-app-config-desk", "crates/ksp-app-solprices-desk", "crates/ksp-app-store-desk", "crates/ksp-app-wallet-desk", "crates/ksp-config-lib", "crates/ksp-core-lib", "crates/ksp-interface-lib", "crates/ksp-job-api", "crates/ksp-job-backfill-lib", "crates/ksp-logging-lib", "crates/ksp-offchain-transport-lib", "crates/ksp-onchain-transport-lib", "crates/ksp-program-api", "crates/ksp-store-api", "crates/ksp-store-lib", "crates/ksp-store-postgres-lib", "crates/ksp-wallet-lib", "crates/ksp-worker-api"] members = ["crates/ksp-app-backfill-desk", "crates/ksp-app-config-desk", "crates/ksp-app-solprices-desk", "crates/ksp-app-store-desk", "crates/ksp-app-wallet-desk", "crates/ksp-config-lib", "crates/ksp-core-lib", "crates/ksp-interface-lib", "crates/ksp-job-api", "crates/ksp-job-backfill-lib", "crates/ksp-logging-lib", "crates/ksp-offchain-transport-lib", "crates/ksp-onchain-transport-lib", "crates/ksp-program-api", "crates/ksp-store-api", "crates/ksp-store-lib", "crates/ksp-store-postgres-lib", "crates/ksp-wallet-lib", "crates/ksp-worker-api"]
[workspace.package] [workspace.package]
version = "0.3.9-pre.5" version = "0.3.9-pre.6"
edition = "2024" edition = "2024"
license = "MIT" license = "MIT"
repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project" repository = "https://git.sasedev.com/Sasedev/khadhroony-solana-project"

114
deltas/0.3.9/pre.006.md Normal file
View File

@@ -0,0 +1,114 @@
<!-- file: deltas/0.3.9/pre.006.md -->
<!-- version: 1 -->
# Delta `0.3.9-pre.006`
## 1. Objet
Fermer l'audit RAW Transaction de `0.3.9` par une synthèse **exhaustive des possibilités d'acquisition**, sans limiter l'architecture aux providers/tiers actuellement accessibles à l'opérateur. La tranche distingue possibilité connue, support KSP et preuve live, classe les sources par réseau/coût/temporalité/complétude/replay et produit le handoff exact vers le Worker live `0.3.10` et l'extension Backfill `0.3.12`.
Aucun runtime d'acquisition n'est modifié dans cette tranche.
## 2. Baseline
Entrée : `0.3.9-pre.005` appliquée après la freeze Worker API `pre.003` et les audits RAW standard/providers `pre.004`/`pre.005`.
Dernier gate opérateur explicitement fourni avant cette tranche pour l'état documentaire `pre.004` :
```text
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
KSP workspace Rust rule audit: clean
Markdown table audit: clean (327 table(s), 738 file(s))
```
`pre.005` a ensuite été poursuivi sur demande de l'opérateur ; aucun gate Cargo `pre.005` n'est inventé par ce delta.
## 3. Version
```text
workspace.package.version = 0.3.9-pre.6
```
Cette livraison est une prerelease non-fix ; la synchronisation Cargo suit `VER-ID-009` même si la tranche reste documentaire côté runtime.
## 4. Synthèse fermée
`docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md` ajoute :
- une légende d'admission/support/preuve ;
- la matrice exhaustive des familles HTTP, WS, Yellowstone, archive, self-hosted et pre-execution ;
- une matrice providers/réseaux/prix/tier/proof status datée au 4 septembre 2026 ;
- Helius, PublicNode, OrbitFlare, QuickNode, Alchemy, Chainstack, Shyft, Triton One, dRPC, Ankr, GetBlock et les providers Yellowstone génériques ;
- les feeds EARLY : Helius Shred Delivery, OrbitFlare Jetstream, Shyft RabbitStream, Triton Deshred/Shreds, bloXroute, DoubleZero et Jito sunset ;
- la stratégie réseau Mainnet/Devnet/Testnet/local ;
- le modèle Worker V1 par capabilities ;
- la déduplication de contenu séparée des observations de provenance ;
- l'échelle de gap repair replay -> redondance -> block scan -> hydration -> archive ;
- les adaptations Transport/Config requises pour `0.3.10` ;
- l'ownership commun de canonicalisation via `ksp-raw-transaction-lib` ;
- la matrice des stratégies Backfill destinées à `0.3.12` ;
- un ordre d'implémentation qui ne supprime aucune capability admise faute de compte payant.
## 5. Décisions d'architecture
```text
NON PROUVÉ != REJETÉ
PAYANT/BLOQUÉ != NON SUPPORTÉ
IMPLÉMENTÉ != PROUVÉ LIVE
```
`ksp-worker-raw-transaction-ingest-lib` sera multi-source par rôles/capabilities et pourra combiner sources directes full, discovery+hydration, replay, gap repair et signaux EARLY.
La canonicalisation RAW v1 commune ne reste pas dans `ksp-job-backfill-lib` et n'est pas copiée dans le Worker. `0.3.10` doit extraire la logique source-neutral dans `ksp-raw-transaction-lib`, avec golden bytes/hash inchangés.
## 6. Preuves et comptes disponibles
La synthèse sépare le support de la preuve afin de permettre :
```text
Mainnet standard HTTP/WS : smokes multi-provider gratuits quand accessibles
Mainnet Yellowstone : PublicNode disponible actuellement
Devnet : Solana public + providers gratuits, dont OrbitFlare gRPC
Testnet : Solana public + PublicNode
branches payantes : tests déterministes + smokes live ignored jusqu'à accès
local/custom : fixtures/Agave/Yellowstone auto-hébergé si nécessaire
```
Aucune clé, URL d'endpoint runtime ou donnée de compte n'est ajoutée au dépôt par cette tranche.
## 7. Fichiers
Modifiés :
```text
Cargo.toml
docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md
docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md
docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md
```
Ajouté :
```text
deltas/0.3.9/pre.006.md
```
Aucun fichier Rust, Config, schema, endpoint provider, secret ou Store n'est modifié.
## 8. Validation d'assemblage
Assemblage local :
```text
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
KSP workspace Rust rule audit: clean
Markdown table audit: clean (343 table(s), 740 file(s))
```
Le sandbox d'assemblage ne fournit pas Cargo ; aucun `cargo check`, Clippy ou test Rust `pre.006` n'est déclaré PASS localement. Les gates Cargo opérateur restent séparés et ne sont jamais inventés.
## 9. Handoff
Après `pre.006`, l'audit RAW est fonctionnellement fermé. `pre.007` doit être un **gate technique final** sans nouvelle fonctionnalité ; `pre.008` réconcilie les documents durables ; `pre.009` prépare le prompt `0.3.10` et la publication.

436
docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md --> <!-- file: docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md -->
<!-- version: 2 --> <!-- version: 3 -->
# Acquisition RAW Transaction # Acquisition RAW Transaction
@@ -470,3 +470,437 @@ kbot3 = référence fonctionnelle seulement, aucune s
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`. 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 :
```text
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 :
```text
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 :
```text
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 :
```text
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 :
```text
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 :
```text
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 :
```text
RawTransaction identity = (network, signature)
```
La source, le provider, le protocole et l'endpoint ne font jamais partie de cette identité.
Règle multi-source :
```text
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 :
```text
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 :
```text
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` :
```text
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 :
```text
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 :
```text
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é :
```text
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 :
```text
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`.

6
docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md --> <!-- file: docs/plans/030-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT_PLAN.md -->
<!-- version: 9 --> <!-- version: 10 -->
# Plan v0.3.9 — Worker API générique + audit RAW Transaction # Plan v0.3.9 — Worker API générique + audit RAW Transaction
@@ -593,9 +593,9 @@ Budget cible : **15-20 min**. `docs/architecture/011-RAW_TRANSACTION_ACQUISITION
### `pre.006` — synthèse RAW multi-source + handoff `0.3.10` / `0.3.12` ### `pre.006` — synthèse RAW multi-source + handoff `0.3.10` / `0.3.12`
**Statut : prévu.** **Statut : réalisé ; synthèse exhaustive des possibilités, y compris non prouvées/non testables actuellement, sans changement runtime.**
Budget cible : **15-20 min**. Consolider la matrice multi-source, les combinaisons de méthodes, les gaps Transport/Config et la stratégie réseau, puis produire le handoff vers l’ingest `0.3.10` et le backfill `0.3.12`. Budget cible : **15-20 min**. `docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md` ferme la matrice par familles de sources, providers, réseaux, prix/tier datés, temporalité, complétude, replay, destination Worker/Backfill et statut de preuve. La synthèse sépare explicitement possibilité connue, support KSP et preuve live afin qu'un tier payant ou un compte indisponible n'exclue jamais une branche de l'architecture. Le handoff `0.3.10` retient un Worker multi-source par capabilities, les adapters standard/Yellowstone/Helius déjà auditables, les hooks EARLY, la stratégie de gap repair et l'extraction de la canonicalisation dans `ksp-raw-transaction-lib`; `0.3.12` reçoit les stratégies block scan, replay Yellowstone, archives/provider history et Old Faithful. Aucun endpoint, secret ou client provider n'est ajouté ici.
### `pre.007` — gate technique final ### `pre.007` — gate technique final

28
docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md --> <!-- file: docs/validation/026-V0_3_9_WORKER_API_RAW_TRANSACTION_AUDIT.md -->
<!-- version: 8 --> <!-- version: 9 -->
# Validation v0.3.9 — Worker API + audit RAW Transaction # Validation v0.3.9 — Worker API + audit RAW Transaction
@@ -200,16 +200,16 @@ Aucun item ci-dessous n’est déclaré exécuté en `pre.001`.
### `pre.006` — synthèse et handoff ### `pre.006` — synthèse et handoff
- [ ] Matrice complète des dimensions imposées par le prompt 028. - [X] Matrice complète des dimensions imposées par le prompt 028, étendue aux possibilités connues même non prouvées/non testables avec les comptes actuels.
- [ ] Alternatives/complements/redundancy/specialization classifiés. - [X] Alternatives/complements/redundancy/specialization classifiés, avec sources full, discovery+hydration, replay/archive et EARLY.
- [ ] Discovery + hydration distingués des streams full transaction. - [X] Discovery + hydration distingués des streams full transaction et des signaux/shreds pré-exécution.
- [ ] Dedup content vs observations de provenance explicitée. - [X] Dedup content vs observations de provenance explicitée ; conflit canonique multi-source jamais résolu silencieusement par first-wins.
- [ ] Stratégie multi-source V1 `0.3.10` proposée sans enum protocole simpliste. - [X] Stratégie multi-source V1 `0.3.10` proposée par capabilities, sans enum protocole/provider fermé.
- [ ] Gaps Transport `0.3.10` listés, non implémentés en `0.3.9`. - [X] Gaps Transport `0.3.10` listés (`get_block_observed`, projection/provenance full commune, conservation moteur Yellowstone), non implémentés en `0.3.9`.
- [ ] Gaps Config `0.3.10` listés, aucun nouvel endpoint ajouté en `0.3.9`. - [X] Gaps Config `0.3.10` listés : sources multiples, rôles/capabilities, priorité/enablement et network binding ; aucun nouvel endpoint ajouté en `0.3.9`.
- [ ] Réutilisation unique `KSP_SECRET_HELIUS_API_KEY` confirmée. - [X] Réutilisation unique `KSP_SECRET_HELIUS_API_KEY` confirmée pour toutes les surfaces Helius concernées.
- [ ] Stratégie compatible `mainnet` / `mainnet-beta` conclue. - [X] Stratégie `mainnet` / `mainnet-beta` conclue : `mainnet-beta` reste l'identité réseau canonique ; `mainnet` peut rester alias de profil/UI.
- [ ] Applicability `0.3.12` Backfill indiquée par source/méthode. - [X] Applicability `0.3.12` Backfill indiquée par source/méthode : GSFA, block scan, explicit signatures, Yellowstone replay, provider history/archive et Old Faithful.
- [X] `docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md` créé dès `pre.004` comme owner durable, à enrichir en `pre.005`/`pre.006`. - [X] `docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md` créé dès `pre.004` comme owner durable, à enrichir en `pre.005`/`pre.006`.
## 7. Couloirs de fermeture ## 7. Couloirs de fermeture
@@ -253,10 +253,10 @@ Aucun item ci-dessous n’est déclaré exécuté en `pre.001`.
La livraison initiale `pre.001` avait conservé `workspace.package.version = 0.3.8` en suivant l’exception du prompt 028. Cette exception est supplantée par la règle normative `VER-ID-009`. La livraison initiale `pre.001` avait conservé `workspace.package.version = 0.3.8` en suivant l’exception du prompt 028. Cette exception est supplantée par la règle normative `VER-ID-009`.
Après l'audit providers `pre.005`, l'état courant est : Après la synthèse multi-source `pre.006`, l'état courant est :
```text ```text
workspace.package.version = 0.3.9-pre.5 workspace.package.version = 0.3.9-pre.6
``` ```
`pre.002` reste la tranche non-fix `0.3.9-pre.2`. Les correctifs de conformité/compilation portent successivement `0.3.9-pre.2.fix.1` puis `0.3.9-pre.2.fix.2` conformément à `VER-ID-007` et `VER-ID-010`. `pre.003` reprend ensuite la séquence prerelease normale avec `0.3.9-pre.3`; son gate opérateur est PASS et freeze Worker API. `pre.004` poursuit avec `0.3.9-pre.4` sans changement runtime, uniquement l'audit standard Solana/KSP et la création de l'owner durable d'acquisition. `pre.005` passe à `0.3.9-pre.5` et enrichit cet owner avec l'audit Helius/Yellowstone/providers/kbot3 sans modifier le runtime. L'état précédent `0.3.9-pre.1.fix.2` reste documenté dans `pre.001-fix.002`. `pre.002` reste la tranche non-fix `0.3.9-pre.2`. Les correctifs de conformité/compilation portent successivement `0.3.9-pre.2.fix.1` puis `0.3.9-pre.2.fix.2` conformément à `VER-ID-007` et `VER-ID-010`. `pre.003` reprend ensuite la séquence prerelease normale avec `0.3.9-pre.3`; son gate opérateur est PASS et freeze Worker API. `pre.004` poursuit avec `0.3.9-pre.4` sans changement runtime, uniquement l'audit standard Solana/KSP et la création de l'owner durable d'acquisition. `pre.005` passe à `0.3.9-pre.5` et enrichit cet owner avec l'audit Helius/Yellowstone/providers/kbot3 sans modifier le runtime. `pre.006` passe à `0.3.9-pre.6` et ferme la synthèse exhaustive possibilités/support/preuve ainsi que les handoffs `0.3.10`/`0.3.12`, toujours sans changement runtime. L'état précédent `0.3.9-pre.1.fix.2` reste documenté dans `pre.001-fix.002`.