khadhroony-solana-project/ROADMAP.md

Roadmap KSP

Le roadmap décrit les objectifs à atteindre et les grandes étapes prévues. Une série X.Y.x regroupe une famille fonctionnelle ; chaque release concrète reste une unité de développement/session distincte.

Légende

• [ ] — prévu / non commencé ;
• [/] — en cours ;
• [X] — réalisé et validé ;
• [C] — annulé ;
• [R] — reporté.

Discipline de livraison

• Une prerelease vise environ 15 à 20 minutes de travail effectif.
• Une release concrète doit être dimensionnée pour pouvoir être ouverte et clôturée dans une seule session de chat.
• Cette règle fixe une durée maximale par release, pas une obligation de changer de session après chaque release : si une release est clôturée plus vite que prévu, la même session peut ouvrir puis clôturer la release suivante si son propre sizing reste positif et si toutes les frontières version/delta/validation sont conservées.
• Si pre.001 révèle qu'une release est trop grosse, elle est scindée avant implémentation fonctionnelle lourde.
• À partir des couches Program/Decode, KSP progresse verticalement groupe par groupe plutôt que par grandes vagues horizontales de decoders/materializers/executors séparés.

0.0.x — Fondation

• 0.0.1 — Initialiser le dépôt.
• 0.0.2 — Installer le squelette minimal et les règles initiales.
• 0.0.3 — Définir domaines, composants, dépendances, contrats, workers/jobs/scénarios/apps et plan global.
• Sélectionner 0.1.1 comme première release fonctionnelle et produire son prompt quasi-final.
• Clôturer la fondation avec documentation, validations et prompt final ; release stable 0.0.3 validée.

0.1.x — Fondations N1

• 0.1.1 — ksp-core-lib : Error/Result, Program IDs fondamentaux et primitives N1.
• 0.1.2 — ksp-logging-lib : façade KSP de tracing.
• 0.1.3 — ksp-config-lib : documents, profils, environnement, persistence et adapters.
• 0.1.4 — ksp-app-config-desk : première application Tauri de référence.

0.2.x — Accès Solana, Wallet et contrats d'extension initiaux

Cadrage

• 0.2.0 — Audit bot3, ordre fonctionnel de 0.2.x, architecture durable, discipline de sizing et pipeline RAW/STRUCTURAL/DECODED/DOMAIN stabilisés.
• 0.2.1 — HTTP foundation stable : matrice 52+14, runtime/routing/résilience/exécution HTTP, 4 canaris typés, std.transport, adapter Config -> Transport, canaries de clôture, smoke Devnet opt-in et documentation durable validés ; les 48 wrappers typés restants sont reportés à 0.2.2–0.2.4.

Releases fonctionnelles décidées/pressenties

• 0.2.1 — HTTP transport foundation réduite par le gate pre.001 : crate/settings/JSON-RPC/registry 52 current + 14 deprecated historiques, pool/rôles/limites/retry, Config adapter, documentation et 4 méthodes typées canari (getBalance, getGenesisHash, getHealth, getVersion) publiés stables.
• 0.2.2 — HTTP Accounts + Tokens + Cluster : 22 wrappers typés (5 Accounts + 5 Tokens + 12 Cluster), canaries de complétude 52+14, smoke Devnet Transport pur et smoke historique Config -> Transport validés, documentation durable et prompt 0.2.3 publiés stables.
• 0.2.3 — HTTP Transactions stable : 11/11 wrappers typés publiés, classification 8 Read / 2 WriteSubmission / 1 Simulation, no-resend ambigu prouvé pour les write submissions, KSP-TRANSPORT-007 réaudité conforme sur les 37 wrappers HTTP courants, graphes Cargo et deux smokes Devnet validés ; 0.2.4 reprend les 15 Blocks/Economics restants.
• 0.2.4 — HTTP Blocks + Economics stable : 15/15 wrappers V0_2_4 publiés, surface typed complète à 52/52 méthodes courantes, 14/14 historiques conservées, réaudit SIMD/inventaire final et KSP-TRANSPORT-007 global validés ; deux smokes Devnet passés avant publication.
• 0.2.5 — Wallet foundation stable : .kspwallet V1, VIEW/OWNER indépendants, Argon2id/XChaCha20-Poly1305, autorité Ed25519 OWNER, persistence no-clobber, signature, administration/rotations/révocation VIEW forte, import/export Solana CLI JSON + Base58, canaris adversariaux, interop externe et documentation durable publiés. La clôture pre.010-fix.001–fix.003 ajoute ed25519-dalek 3.0.0 direct, normalise le Rust workspace et installe l’audit structurel Python complémentaire à rustfmt/Clippy. Pubkey reste via ksp-core-lib, la keypair reste encapsulée dans Wallet et Config/Transport/ExecutionPolicy/Store/Tauri restent hors Wallet.
• 0.2.6 — ksp-app-wallet-desk + .kspwallet V2 stables : composition Config/Wallet/HTTP/Logging, lifecycle VIEW/OWNER, balance, administration/import/export, wire binaire V2, APIs multi-version, migration V1 -> V2 explicite et runtime Tauri packagé user-writable validés ; bundles Linux .deb/.rpm/.AppImage produits avant publication. Plan clôturé : docs/plans/013-V0_2_6_WALLET_DESK_PLAN.md.
• 0.2.7 — WebSocket Solana standard stable : 9 familles subscribe/unsubscribe typées (18/18 opérations), sessions physiques multiples explicites, subscriptions logiques typées, lifecycle/reconnect/resubscribe/backpressure/shutdown bornés, Config V2, non-régression HTTP 52+14, compliance finale, smoke WebSocket Devnet et audit de dépendances validés ; publication rel.001 et prompt 0.2.8 prêts.
• 0.2.8 — Helius LaserStream WebSocket stable : façade provider dédiée sur l’actor WebSocket partagé, sept familles standard réutilisées (account/logs/program/root/signature/slot/slotsUpdates) + transactionSubscribe/transactionUnsubscribe, block/vote absents, heartbeat Ping 60 s Helius-only, Config V2/secrets redacted, lifecycle adversarial, compliance HTTP 52+14 / Standard WS 18/18 et graphes Cargo finaux validés ; prompt 0.2.9 prêt.
• 0.2.9 — Yellowstone gRPC standard/provider-neutral stable : moteur Tonic/Protobuf KSP partagé, sept unary standard retenues, Subscribe bidi et neuf variantes d’update, lifecycle/backpressure/reconnect/replay bornés sans promesse lossless, Config Transport V3 backward V1/V2 avec provider/protocol séparés, profils PublicNode Mainnet/Testnet authentifiés par x-token, smoke live Subscribe -> Slot 2/2 PASS et graphes Cargo finaux inspectés ; SubscribeDeshred reste hors scope.
• 0.2.10 — OrbitFlare Yellowstone gRPC stable : profil Config V3 Devnet, License Key injectée comme metadata secrète x-token, smoke live Subscribe -> Slot + Ping validé deux fois, sans modification du moteur N1/N2 ni heartbeat provider.
• 0.2.11 — Off-chain price transport stable : ksp-offchain-transport-lib expose SOL/USD via huit adapters REST reqwest sans SDK provider, décimal exact, sémantiques/provenance explicites, registry/availability/rate limits et refresh single/many/all génériques ; Config std.offchain_transport construit le service sans dépendance inverse, DexScreener reste lié à une paire explicite sans discovery, aucun consensus/fallback automatique n’est introduit, et le smoke live keyless final passe 7/7 après correction CoinMarketCap V2.
• 0.2.12 — SOL Prices Desk + projection prix Wallet stables : HID provider-neutral avec refresh row/selected/all et batch 1..=64, observations/timestamps exacts sans polling/consensus, puis refresh balance Wallet enrichi d’une moyenne SOL/USD consumer-owned et d’un équivalent USD exact best-effort ; smoke live de composition, workspace complet et bundles Tauri Linux validés.
• 0.2.13 — Interface / wire foundation stable : ksp-interface-lib expose Pubkey, ProgramAccountMeta et ProgramInstruction passifs, admission bornée à 255 account metas / 10 240 bytes, erreurs et Debug sans payload hostile, façade crate-root et consumer externe canaris ; graphe strict Interface -> Core, sans serde/codec générique, solana-instruction, réseau ni logging runtime.
• 0.2.14 — Program API foundation stable : ksp-program-api expose une surface instruction-only ouverte avec ProgramInstructionRecognition, ProgramInstructionDecodeOutcome<Decoded> et ProgramInstructionDecoder; implémentation externe avec Program Pubkey opaque validée, 10 exports crate-root / 3 modules de production verrouillés, graphe strict Core + Interface, sans registry/runtime/serde/codec/Store/Materializer/Execution. Le prompt 0.3.1 prépare Store RAW-only.

TODO/IDEAS — providers Yellowstone non planifiés

• TODO — Helius LaserStream gRPC : réauditer lorsque l'accès live gRPC est raisonnablement disponible ; conserver N1/N2 Yellowstone inchangés, vérifier auth/endpoints/Subscribe/Ping/replay/from_slot/erreurs provider et traiter les preprocessed transactions comme extension Helius séparée.
• TODO — eRPC : réauditer accès, auth/IP policy, capabilities et produits complémentaires avant toute décision d’implémentation.
• TODO — Triton : réauditer la frontière Yellowstone upstream / extensions Triton, notamment Deshred et futures extensions.
• TODO — Alchemy : réauditer auth, replay, limites et capabilities Yellowstone avant toute intégration.
• TODO — QuickNode : réauditer auth, compression, from_slot, filtres et limites de plan.
• TODO — Chainstack : réauditer networks, auth, add-on et capabilities Yellowstone.
• IDEAS — Tatum, Shyft, Solinfra, NodeFlare et autres providers : conserver comme candidats exploratoires sans numéro de release ni engagement d’implémentation.

Règles Transport pour toute la série

• Couvrir toutes les méthodes/opérations documentées pour la surface normative ciblée par chaque release.
• Conserver les méthodes deprecated/obsolete encore fonctionnelles et émettre un warn KSP lors de leur utilisation.
• Implémenter les méthodes unstable/experimental ciblées et émettre un warn KSP lors de leur utilisation.
• Centraliser la metadata de statut des méthodes plutôt que disperser des warnings ad hoc.
• Garder ksp-onchain-transport-lib indépendant de ksp-config-lib, du Store et des modèles Program/métier.

Architecture de données — progression canonique

La progression durable cible est :

RAW -> STRUCTURAL -> DECODED -> DOMAIN

• RAW et STRUCTURAL ne nécessitent aucun décodage Program.
• La progression n'est pas une chaîne obligatoire pour chaque famille : une donnée event-only peut s'arrêter en D1, et un état de compte pourra aller directement vers un futur decoder si aucune décomposition STRUCTURAL utile n'existe.
• À la fin des couches horizontales RAW/STRUCTURAL réellement persistées, ajouter les jobs/workers/apps nécessaires avant d'ouvrir la couche suivante.
• À partir de DECODED, avancer verticalement groupe par groupe ; DOMAIN désigne les projections métier et la matérialisation est le processus qui les produit.

0.3.x — RAW / acquisition persistée

• 0.3.1 — ksp-store-api stable : modèles D1 RAW backend-agnostic RawTransaction et RawAccountState avec observations, provenance, payload/hash/timestamps bornés, 10 capabilities object-safe, queries cursorisées sans plafond métier arbitraire, outcomes idempotence/conflit et lifecycle logique rétention/tombstone/force-rehydrate ; aucun backend physique, Config, runtime Store, notification dédiée ni surface STRUCTURAL/DECODED/DOMAIN.
• 0.3.2 — ksp-store-lib + ksp-store-postgres-lib stables comme fondation runtime/backend PostgreSQL : feature postgres par défaut, Store lié à un unique RawNetworkId, Config std.store avec targets/bases devnet/mainnet/testnet, pool Deadpool borné, tokio-postgres, TLS Rustls Disabled/VerifyFull, moteur de migrations privé V000 + SHA-256/advisory lock, health/readiness portable et close borné. Gate complet + PostgreSQL réel major 17 verts ; aucune table/capability RawTransaction/RawAccountState métier n'est encore ajoutée.
• 0.3.3 — Vertical slice PostgreSQL RawTransaction complète sur ksp-store-lib + ksp-store-postgres-lib : six capabilities transaction/observation/rétention, V001 physique liée à un réseau, acquisition canonical+observation atomique, idempotence/conflit, get/list keyset cursorisé, archive/purge/tombstone/ForceRehydrate, hardening des erreurs et du schéma, concurrence et rollback validés sur PostgreSQL 17.
• 0.3.4 — Vertical slice PostgreSQL RawAccountState complète sur ksp-store-lib + ksp-store-postgres-lib : quatre capabilities account ajoutées aux six transaction pour une conformance RAW 10/10, V002 additive de 32 ressources au-dessus de V000/V001 immuables, state+observation atomiques, idempotence/conflit exacts, metadata Yellowstone observation-only, get/list keyset (slot,pubkey,state_hash) avec cursor KSPA anti-replay, hardening cross-family et live validé sur PostgreSQL 17 sans rétention destructive account.
• 0.3.5 — ksp-interface-lib étendu avec deux familles passives réellement partagées : SlotLifecycleEvent (Processed, FirstShredReceived, Completed, CreatedBank, Dead, OptimisticallyConfirmed, Rooted) et TransactionExecutionEvent (slot + TransactionSignature[64] + Succeeded/Failed). Interface reste Core-only, provider-neutral, sans serde/codec/runtime/event bus et sans duplication de RawTransaction/RawAccountState; les DTOs riches restent Transport-owned et les candidats non convergents restent différés.
• 0.3.6 — ksp-job-api + ksp-job-backfill-lib stables pour la première verticale historique RawTransaction : lifecycle/cancellation/latest-value runtime-neutral, scopes Latest/Before/After/signatures explicites, découverte/hydratation Transport observée, RAW v1 canonique, persistance Store atomique/idempotente, concurrence bornée, frontier contiguë, checkpoint/reprise caller-owned, snapshots sûrs et hardening externe sans dépendance backend/provider directe.
• 0.3.7 — ksp-app-backfill-desk livrée comme Desk Tauri KSP spécialisée : composition Config Mainnet/Devnet/Testnet, quatre scopes HTTP, validation/start single-run, monitoring latest-value ksp-backfill-status, Cancel ciblé/idempotent, Resume in-session par checkpoint Rust-only réémis pour un nouveau JobId, autocomplete libre depuis ksp-core-lib, hardening IPC/dependency boundaries et build Linux .deb/.rpm/.AppImage. Aucun SQL/backend/provider physique ni checkpoint durable n’est exposé.
• 0.3.8 — ksp-app-store-desk V1 RAW livrée sur le gabarit KSP courant comme application Tauri read-only backend-neutral. La Desk compose Config + Logging + ksp-store-lib, expose health/runtime sûrs, DataTables serverSide pour RawTransaction, RawAccountState et leurs observations, détails bornés, provenance sûre et états de rétention/tombstone, sans SQL/backend physique/Transport dans l'application. La nouvelle inspection random-access offset + limit + counts exacts reste distincte de la pagination machine cursor/keyset conservée pour workers/backfills/replays. Le gate final et les builds Linux .deb/.rpm sont verts.
• 0.3.9 — ksp-worker-api stable comme API générique et volontairement courte pour services continus : identité/kind bornés, lifecycle explicite, health/activity sûrs, stop token partagé, séquence/snapshot latest-value et WorkerSnapshotSource object-safe, avec dépendance Core-only et sans runtime/start-stop universel, Solana, Transport, Store, Config ou Tauri. Après freeze Worker API, l'audit RawTransaction a été consolidé dans une synthèse Store-centrique exhaustive séparant possibilités/support/preuve et classant HTTP, WS standard/provider, Yellowstone gRPC, blocs/slots, discovery + hydration, replay de continuité, archives et sources EARLY. Le Job Backfill historique paramétré et le Worker Ingest live start/stop sont deux producteurs indépendants du même Store ; mainnet est désormais l'identité KSP canonique et mainnet-beta un alias legacy/externe. Le handoff retient ksp-raw-transaction-lib comme lower-layer commune de canonicalisation RAW v1 pour 0.3.10, sans edge Job ↔ Worker.
• 0.3.10 — Lower-layer RAW Transaction commune stabilisée : ksp-raw-transaction-lib possède la canonicalisation RAW v1 source-neutral partagée, le Backfill est migré sans changement des golden bytes/hash, Transport expose get_block_observed, le wire Solana Legacy/V0/V1 est matérialisé et les canaris HTTP/WS standard/Helius/Yellowstone qualifient précisément les voies directes ou nécessitant hydration. La release se ferme sans runtime Worker concret ; celui-ci commence en 0.3.11 selon le redécoupage 0.3.11–0.3.14.
• 0.3.11 — Fondation runtime de ksp-worker-raw-transaction-ingest-lib livrée : crate/dependency firewall, settings source-neutral, handle/start-stop, lifecycle, snapshots, supervisor, admission bornée, canonicalisation Common RAW, persistence/déduplication Store déterministe, backpressure et shutdown/fault hardening. La release se ferme volontairement sans source réseau productive ; Yellowstone + hydration HTTP commencent en 0.3.12.
• 0.3.12 — Première source live productive du Worker livrée : Yellowstone Transaction/TransactionStatus/Block vers signaux source-neutral, coalescence bornée puis hydration HTTP getTransaction observed avant Common RAW/Store ; BlockMeta/Slot restent continuity-only. Processing frontier run-local, reconnect/from_slot/ReplayInfo Transport-owned, compteurs source-neutral et fault sur gap de rétention prouvé sans Backfill automatique. Hardening duplicate/backpressure/stop/fault et canaris cross-layer fermés ; gate workspace complet vert, smokes live HTTP Devnet + WebSocket Devnet verts, Yellowstone token-gated/Worker end-to-end laissés explicitement non exécutés.
• 0.3.13 — Convergence live multi-source du Worker RAW livrée : composition caller-owned 1..32 sources d’un même réseau, cinq familles Yellowstone / Standard Logs / Standard Block / Helius Transaction / HTTP Block Polling, hydration globale des trois voies reference-bearing, RAW-direct Legacy/V0/V1 pour les deux voies blocs, observations multiples, content conflict explicite, coalescence cross-source, fairness/backpressure/health source-neutral et shutdown hardening sans second actor Transport. Gate workspace complet vert (1 850 PASS / 0 échec / 15 ignored) et smokes keyless HTTP + WebSocket Devnet verts ; les preuves provider/resource-gated non exécutées restent explicitement non revendiquées.
• 0.3.14 — Gap repair/hardening multi-source du Worker RAW livré : gaps run-local bornés, distinction reconnect/replay/delivery/coverage, TargetCoverage conservative, coverage redondante prouvée, discovery HTTP bornée, known-reference hydration, réconciliation source-loss, health gap-aware, fairness nominal/repair, snapshots publics source-neutral et shutdown/drain renforcé. Le pipeline Common RAW/Store reste unique, Worker/Backfill restent indépendants, EARLY n’est pas ajouté. Gate workspace complet vert (1 931 PASS / 0 échec / 15 ignored) et smokes keyless HTTP + WebSocket Devnet verts ; preuves provider/resource-gated non provisionnées explicitement non revendiquées.
• 0.3.15 — ksp-app-raw-transaction-ingest-desk livrée comme Desk Tauri KSP multi-route : composition capability-driven par réseau, une instance Worker indépendante par route sélectionnée, Store partagé, Start/Stop ciblé et supervision lifecycle/health/backpressure/reconnect/replay/gaps/repair sans réimplémenter Transport ni persistence. Les cinq familles live sont projetées selon les capacités réellement configurées ; Yellowstone Mainnet utilise le trigger gRPC Block + HTTP getBlock et applique une backpressure bornée sans overflow local prolongé. Le Stop Yellowstone post-half-close est coopératif, et Store accepte le cas strict canonique complet + incoming logMessages explicitement tronqué compatible sans remplacer le canonique ni arrêter le Worker. Gate workspace/Clippy/tests/graphes/bundles Linux vert et live Mainnet Yellowstone + HTTP polling d’environ 19 minutes fermé Stopped/Healthy. La généralisation variantes/conflits/promotions/retry/reconnect reste explicitement 0.3.16.
• 0.3.16 — RAW resilience / conflict management : faire converger Store API/façade/PostgreSQL, Worker live et Store Desk autour de variantes RAW durables, résolution automatique Exact / CompatibleLessComplete / CompatibleMoreComplete / Conflict, quarantaine des conflits non résolus sans arrêt du Worker, historique réversible des promotions/résolutions, retry Store sans perte silencieuse et reconnexion Transport configurable/bornée. Une provenance provider n'est jamais une priorité canonique en soi ; la représentation prouvée la plus complète gagne.
• 0.3.17 — Étendre ksp-job-backfill-lib au backfill multi-route/multi-stratégie à partir de la matrice d'acquisition auditée en 0.3.9 et de la convergence Store 0.3.16. Conserver getSignaturesForAddress + getTransaction comme première voie valide puis ajouter les stratégies historiques/catch-up réellement pertinentes sans edge Job ↔ Worker.
• 0.3.18 — Adapter ksp-app-backfill-desk au Job multi-route 0.3.17 : inventaire/composition de routes, sélection/supervision et progression sur le modèle structurel de ksp-app-raw-transaction-ingest-desk, sans réimplémenter la logique du Job.

TODO/IDEAS — applications spécialisées et control plane

• TODO — faire évoluer ksp-app-store-desk avec chaque nouvelle couche réellement persistée : RAW d'abord, puis STRUCTURAL, DECODED, journal de processing/materialization et projections DOMAIN selon les contrats effectivement disponibles. Les vues avancées restent backend-agnostiques et passent uniquement par ksp-store-lib.
• TODO — différer une future ksp-app-control-desk jusqu'à ce que KSP dispose au minimum d'une couche D3 DECODED de processing/materialization exploitable et de plusieurs decoders réels. Cette application sera une surface end-user simplifiée : démarrer/arrêter les flux autorisés, lancer une recherche courante, voir l'état global et les erreurs importantes. Elle ne recopiera pas le diagnostic détaillé, les réglages avancés, les tables complètes ni toutes les fonctions des ksp-app-*-desk spécialisées, qui resteront les outils d'administration, développement et investigation approfondie.

TODO/IDEAS — taxonomie D1, processing et rétention

• TODO — maintenir la matrice d’admission HTTP/WS/gRPC/provider lors de toute nouvelle famille D1 : plusieurs sources ne convergent vers un même struct que si elles satisfont la même sémantique sans perte.
• TODO 0.3.9 — matrice RAW Transaction unique produite et consolidée dans docs/architecture/011-RAW_TRANSACTION_ACQUISITION.md, avec séparation possibilités/support/preuve, capabilities orthogonales aux producteurs, provenance/déduplication/continuité et handoffs désormais scindés 0.3.11–0.3.14 Worker live / 0.3.16 résilience RAW / 0.3.17–0.3.18 Backfill multi-route.
• TODO Helius 0.3.13 — la voie Worker Helius transactionSubscribe réutilise la surface Transport et les profils Config Helius déjà existants avec KSP_SECRET_HELIUS_API_KEY; aucun nouveau profil, secret, SDK provider, tier codé ou second client parallèle n’a été nécessaire. Le payload riche reste Transport-owned et la voie Worker hydrate via getTransaction observed tant que le RAW complet n’est pas prouvé directement.
• TODO réseau — identité KSP canonique fixée à mainnet dans Config/Store/Transport/tests ; mainnet-beta reste uniquement un alias legacy/externe lorsque la frontière provider l'exige. Les données D1 RAW antérieures restent non autoritaires pendant cette phase et aucune compatibilité de base de test n'impose l'ancien libellé.
• RawAccountState + observation — contrat commun stabilisé en 0.3.1 avec bytes complets + slot, provenance séparée et enrichissements source-specific optionnels ; la persistence PostgreSQL physique est complétée en 0.3.4 avec les quatre capabilities account et la conformance RAW 10/10.
• TODO — statut/commitment transactionnel restant : 0.3.5 couvre uniquement le fait passif d’exécution slot + signature + outcome; réauditer séparément signatureSubscribe et getSignatureStatuses lorsqu’un consumer de commitment/snapshot réel apparaît, sans fusionner snapshot, transition et execution update dans un modèle Option-soup.
• IDEA — logs realtime enrichis : logsSubscribe alimente déjà la projection minimale TransactionExecutionEvent, mais un éventuel TransactionLogEvent portant les lignes de log reste différé dans docs/IDEAS.md jusqu’à démonstration d’un consumer et de bornes explicites. logMessages reste dans RawTransaction jusqu’à STRUCTURAL ; le wake-up post-commit reste distinct et Store API-owned conformément à KSP-NOTIFY-*.
• slot/root/slotsUpdates — 0.3.5 stabilise SlotLifecycleEvent pour l’intersection réellement partagée, sans persistence Store par défaut et sans promettre l’ordre/complétude du flux.
• TODO — vote realtime : reste hors Interface tant qu’aucun consumer transversal et aucune sémantique provider-neutral suffisamment précise ne justifient un contrat partagé.
• IDEA — RawBlock : ne rouvrir que si une information block-level non reconstructible devient nécessaire ; getBlock doit d’abord être traité comme source de RawTransaction, pas comme invitation à recopier le ledger en blocs.
• REJET ACTUEL — Yellowstone Entry : trop bas niveau et aucune destination replay/decomposition/event métier justifiant un modèle KSP n’est identifiée.
• TODO — processing ledger : reprendre l’idée kbot2/kbot3 stage + processor identity/version + input identity/hash + terminal status, sans faire d’un processed: bool la preuve durable unique ; prévoir force replay/version upgrades lorsque les processors seront ouverts.
• lifecycle RAW logique — RawRetentionState, tombstone minimal, normal-skip et force-rehydrate sont stabilisés en 0.3.1 pour RawTransaction.
• rétention physique RawTransaction PostgreSQL — 0.3.3 matérialise Full -> Archived -> Purged, tombstone et ForceRehydrate atomiques ; Compacted reste explicitement unsupported tant qu’aucune représentation compactée réelle n’existe.
• TODO — policy de rétention/compaction : définir les critères d’éligibilité fondés sur les preuves de processing et la maintenance worker/job ; Store applique une transition demandée mais ne décide pas seul qu’un RAW peut être archivé/purgé, et la compaction physique ne sera ajoutée qu’avec un besoin réel.
• frontière ksp-interface-lib / ksp-store-api — ownership documenté et canaris de non-duplication stabilisés en 0.3.1; les events passifs non persistés restent Interface, les modèles persistants/replayables restent Store API.
• IDEA — réauditer la structure de processing/decode/materialization historique kbot2/kbot3 lors de l’ouverture de D2/D3 ; conserver l’isolation instruction/CPI et les statuts terminal/versionnés, sans reprendre automatiquement le schéma SQL historique.

Série STRUCTURAL suivante

• Définir la persistence STRUCTURAL canonique Solana générique pour les familles réellement décomposables.
• Implémenter en priorité RawTransaction -> STRUCTURAL sans decoder Program : transaction/message, comptes/références, instructions top-level, CPI/inner instructions, logs/meta/balances/return data et relations structurelles.
• Vérifier avant extension si d'autres familles D1 possèdent une vraie décomposition STRUCTURAL utile ; ne pas créer de niveau vide par convention.
• Ajouter replay/backfill RAW -> STRUCTURAL avec processing versionné.
• Ajouter le worker/service STRUCTURAL utile sans le coupler à un worker RAW concret.
• Faire évoluer ksp-app-store-desk avec des vues/requêtes STRUCTURAL lorsque cette couche est réellement persistée ; ne pas créer une seconde application de browsing des mêmes données.

Séries DECODED/DOMAIN/EXECUTION — progression verticale

Priorité 1 — Solana Core Programs

• Wire/decoding des programmes Core nécessaires transversalement.
• Matérialisation et projections utiles.
• Préparation d'exécution, policy et scénarios Devnet pour les opérations retenues.

Priorité 2 — SPL token/trading

• SPL Token.
• Associated Token Account.
• Token-2022 et extensions pertinentes.
• Pour chaque famille : decode -> materialize -> domain projection -> prepare -> policy -> execute -> scenarios.

Priorité 3 — Metadata token

• Metaplex Token Metadata.
• Token-2022 Metadata.
• [R] Solana Program Metadata (SPM) — redéveloppement plus tard avec le décodage généraliste.

Priorité 4 — Anchor

• Introduire les contrats et mécanismes Anchor nécessaires aux protocoles trading suivants.

Priorité 5 — DEX à fort intérêt

• Meteora, y compris vaults/fees/positions/états auxiliaires nécessaires à son groupe.
• Raydium, y compris programmes satellites nécessaires.
• Pump, y compris fee program et composants launch/bonding/pool nécessaires.
• Orca, y compris programmes satellites nécessaires.
• Chaque groupe est terminé verticalement avant de devenir secondaire au profit du suivant.

Market Desk V1

• Après les premiers groupes Meteora/Raydium/Pump/Orca, introduire une petite ksp-app-market-desk spécialisée.
• Visualiser tokens, pools/markets, liquidité, swaps/trades, prix, volumes, OHLC/candles et activité live/récente lorsque disponible.
• Lire les projections DOMAIN KSP ; ne pas reconstruire la logique protocolaire dans l'UI.

Routing

• Jupiter.
• OKX et autres routeurs selon besoin réel.
• Enrichir Market Desk avec routes, legs, DEX impliqués, fees/slippage et comparaison quote/execution lorsque disponible.

Trading-adjacent puis décodage généraliste

• Ajouter ensuite les programmes indépendants utiles au trading : oracles, locks/vesting indépendants, lifecycle token, risk/signaux, etc.
• Ne jamais y repousser un satellite appartenant à un groupe DEX déjà ciblé.
• Étendre enfin le décodage au reste de Solana selon valeur fonctionnelle.

Trading Intelligence et produits ultérieurs

• Statistiques/features/datasets historiques.
• Signaux, risque, anomalies et patterns.
• Replay analytique/backtests.
• XGBoost puis autres modèles lorsque les données et contrats sont stables.
• Construire ensuite les produits de trading opérationnel au-dessus de ces couches.
• Faire évoluer Market Desk vers davantage d'analyse sans la confondre avec l'application globale ou l'orchestrateur.
• Étudier plus tard les autres applications Wallet : mobile, extensions navigateur et web.