4.4 KiB
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,V3ouV4, afin de produire une capacité exacte ;SplMemoOperation::AddMemo;SplMemoExecutionIntentavec intent ID, fee payer et politique commune ;- une liste ordonnée de
SplMemoSignerdont 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_mainnetet 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.