kb_executor_spl_token

Ce crate construit des plans typés pour le programme SPL Token classique exact :

TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

Il ne dépend ni du RPC, ni du wallet, ni de Tauri, ni du décodeur. La lecture d’état, la simulation, la signature, l’envoi et la validation post-exécution appartiennent à l’orchestration commune.

Politique de surface

Le décodeur conserve les 28 tags publiés, y compris les formes historiques. L’exécuteur expose 24 opérations encore courantes ou récentes et refuse quatre initialisations obsolètes dépendantes de Rent : InitializeMint, InitializeAccount, InitializeMultisig et InitializeAccount2. Leurs équivalents actuels utilisent respectivement InitializeMint2, InitializeAccount3 et InitializeMultisig2.

Les opérations non checked Transfer, Approve, MintTo et Burn restent constructibles : leur wire est ancien, mais les builders officiels 3.0.0 les publient toujours et elles ne sont pas obsolètes. Les variantes checked doivent être préférées lorsqu’un mint et ses decimals sont connus.

Contrat typé

SplTokenExecutionIntent contient :

un identifiant d’intent et un fee payer ;
une ExecutionPolicy commune, simulation obligatoire et dry-run par défaut ;
une instruction typée ou un Batch de sous-instructions non batch ;
les comptes métier explicites ;
une autorité simple ou un multisig avec signataires ordonnés ;
les montants bruts sous forme de chaînes décimales JSON, converties en u64 seulement dans le builder ;
les decimals séparés lorsqu’ils appartiennent réellement au wire.

Les doublons des metas multisig sont conservés dans l’ordre officiel. La liste des signataires transactionnels est dédupliquée séparément avec le fee payer.

Builders

Chaque opération appelle directement le builder spl-token-interface 3.0.0. Cela couvre les initialisations actuelles, transferts, délégations, changements d’autorité, mint/burn, close, freeze/thaw, variantes checked, SyncNative, les trois instructions de return data, InitializeImmutableOwner, WithdrawExcessLamports, UnwrapLamports et Batch.

InitializeImmutableOwner est explicitement un no-op de compatibilité sur le programme classique ; il n’est jamais présenté comme une extension Token-2022.

Batch est borné à 64 enfants, 512 occurrences de comptes et 255 octets de data par enfant. Son type enfant exclut structurellement un autre Batch. Les slices de comptes et l’ordre produits par le builder officiel sont conservés.

Constructibilité et clusters

La constructibilité de bibliothèque ne dépend pas du cluster. UnwrapLamports et Batch sont publiés avec un builder exact dans l’interface 3.0.0 et sont donc constructibles. Deux simulations réussies le 16 juillet 2026 prouvent leur présence sur le programme classique Devnet. Cette preuve n'est pas extrapolée à Localnet, Testnet ou Mainnet. Mainnet demeure gouverné par kb_execution_safety et la confirmation opérateur, pas par une interdiction interne à ce crate.

Les opérations d’initialisation supposent que les comptes ont déjà été créés avec la bonne taille, le bon owner et le bon financement. La création System et le rent ne sont pas masqués dans une instruction Token ; le préflight stateful de la tranche suivante les vérifiera sans utiliser ATA.

Coûts et validation

Les montants token ne sont pas des frais réseau et ne sont pas reportés comme lamports dépensés. Un montant explicite UnwrapLamports est déclaré dans requested_spend_lamports; un unwrap total et WithdrawExcessLamports restent simulation-only tant qu’une lecture d’état n’a pas borné les lamports déplaçables. Le plafond de frais reste séparé dans ExecutionCostLimit.

Toute construction impose une simulation, un plafond de frais positif, une insertion canonique, l’extraction core et le replay décodé. Les mutations exigent aussi la validation de matérialisation ; les conversions, requêtes de return data et le no-op de compatibilité n’inventent aucune projection.

Limites actuelles

aucun préflight Mint/Account/Multisig dans ce crate : ces lectures sont implémentées dans kb_pipeline afin de conserver l'exécuteur pur ;
aucun envoi ni simulation RPC dans ce crate ; l'orchestrateur commun a validé ces étapes sur Devnet pour TransferChecked et le lifecycle contrôlé ;
aucun compte ATA créé implicitement ;
aucun support Token-2022 ;
aucun déploiement de UnwrapLamports ou Batch revendiqué hors Devnet sans simulation cluster dédiée.

Le parcours Devnet réel a prouvé simulation, soumission, confirmation, hydratation canonique, extraction, replay, matérialisation et idempotence pour les opérations du lifecycle documentées dans docs/SPL_TOKEN_MATRIX.json. La démo Tauri refuse volontairement un envoi si le wallet du profil ne résout pas aussi l'autorité Token requise ; elle ne prend jamais en charge une clé externe implicite.

Le probe Devnet simulation-only du 16 juillet 2026 a validé le wire déployé de Batch avec un enfant TransferChecked de montant nul en 270 compute units, puis UnwrapLamports d'un lamport en 140 compute units. Aucune transaction n'a été signée ou envoyée par ce probe.

5.3 KiB Raw Blame History Unescape Escape