# kb_executor_spl_memo Ce crate reconnaît les Program IDs exacts SPL Memo v1, v3 et v4, mais construit des plans d’exécution uniquement pour la génération courante v4. Il ne dépend ni du wallet, ni du RPC, ni du décodeur et n’effectue directement aucune signature ni aucun envoi. ## Contrat typé L’unique opération est `spl_memo.add_memo`, portée par : - `SplMemoGeneration::V1`, `V3` ou `V4`, afin de produire une capacité exacte ; - `SplMemoOperation::AddMemo` ; - `SplMemoExecutionIntent` avec intent ID, fee payer et politique commune ; - une liste ordonnée de `SplMemoSigner` dont les doublons sont conservés dans l’instruction. Le message est un `String` Rust : sa validité UTF‑8 est donc acquise avant la construction. Les octets UTF‑8 exacts deviennent l’intégralité de `Instruction::data`, sans préfixe, discriminator, Borsh ou `bincode`. ## Builder et comptes Pour v4, le crate appelle directement `spl_memo_interface::instruction::build_memo` de la version 2.1.0 avec le Program ID explicite. Les tests comparent le plan produit au builder officiel. Les générations v1 et v3 sont historiques `decode-only` et n'atteignent jamais ce builder par l'API de l'exécuteur. Chaque signer fourni devient un compte `readonly`, `is_signer = true`, dans l’ordre exact. Aucun compte writable n’est inventé. Les occurrences dupliquées restent dans les metas ; la liste transactionnelle `required_signers` est dédupliquée et commence toujours par le fee payer. Le payload est borné à 566 octets et la liste à 32 occurrences de signataires. Ces limites sont des garde-fous conservateurs de l’exécuteur, pas de nouveaux rejets attribués au runtime. L’assembleur commun vérifie ensuite la taille wire exacte de 1 232 octets, qui dépend notamment du nombre de signatures. ## Capacités et politiques La construction de plan est `Supported` pour `AddMemo` uniquement sur l'ID v4 exact. V1 et v3 retournent `Unsupported(reason)` avec le code stable `execution_spl_memo_historical_generation_decode_only`. Toute autre opération ou tout autre Program ID est également `Unsupported(reason)` avec son propre motif. - simulation obligatoire ; - dry-run par défaut via `ExecutionPolicy::default()` ; - plafond de frais strictement positif obligatoire ; - dépense d’instruction égale à zéro lamport, hors frais réseau ; - construction v4 disponible sur Localnet, Devnet, Testnet et Mainnet ; - aucune génération artificiellement limitée au dry-run par la bibliothèque ; - Mainnet gouverné par la politique commune `allow_mainnet` et sa confirmation explicite ; - insertion canonique, extraction core, decode replay Memo et matérialisation exigés après exécution. La disponibilité effective de v4 sur un cluster n’est pas supposée par le builder : elle est établie par la simulation RPC obligatoire. Une future génération expérimentale officiellement encodée pourra être ajoutée sans la limiter artificiellement à un cluster. Les générations historiques restent décodables dans `kb_decoder_spl_memo`, mais ne sont pas exécutables. La démo `0.4.3` reste limitée à Devnet. Les signataires restent visibles dans `ExApiPreparedExecutionPlan` avant toute signature. Les clés privées ne font partie ni de l’intent ni du plan. ## Validation Devnet et démos `kb_pipeline::execute_devnet_memo` réutilise l’infrastructure de `0.4.2` pour construire un Memo v4, simuler, demander une autorisation explicite avant l’envoi, confirmer, hydrater, extraire, rejouer le décodeur, vérifier l’annotation puis prouver l’idempotence par un second replay non forcé. La fenêtre Solana Devnet existante expose ce parcours sans nouvelle WebView. Elle affiche payload, fee payer, signataire wallet readonly, plan, simulation et validation post-exécution. Le journal générique `demo_decode_replay` reste la surface de consultation des annotations matérialisées. Les DTO Memo sérialisent soldes et frais en chaînes décimales et n’exportent aucune clé privée ni `bigint` actif. La validation réelle du 15 juillet 2026 comprend une simulation seule et trois transactions v4 Devnet confirmées. Chacune a produit une insertion canonique, une extraction core, un decode, une annotation et un second replay `skipped` sans nouvelle matérialisation. Les signatures exactes sont enregistrées dans `docs/SPL_MEMO_MATRIX.json`.