Sur Solana, un compte ne reste ouvert que s'il détient un dépôt minimal en SOL. Ce plancher dépend de la taille des données stockées et du coût par octet en vigueur sur le réseau. Le 3 septembre 2026, la première des cinq phases de réduction de ce coût est entrée en vigueur. Des comptes de jetons, des mints et des comptes de programmes détiennent donc aujourd'hui plus de SOL que le nouveau plancher n'en exige. Ce dépôt n'est pas du SOL délégué à un validateur comme dans le staking de SOL. Il est attaché au compte, et le surplus peut sortir sans fermer ce compte ni toucher au solde de jetons.
Comment récupérer le surplus sur un compte de jetons ?
Le Token Program a été réécrit avec Pinocchio, une version surnommée P-token. Son passage sur le mainnet a apporté plusieurs instructions nouvelles, dont WithdrawExcessLamports. Elle calcule le plancher du compte source, puis déplace vers un compte destinataire tout ce qui le dépasse. Le compte source reste ouvert et fonctionnel. L'instruction accepte les comptes de jetons, les mints et les multisigs. Le code publié refuse en revanche les comptes natifs, ceux qui enveloppent du SOL, et renvoie une erreur si le solde se situe déjà sous le plancher. Côté client, l'appel passe par la fonction getWithdrawExcessLamportsInstruction du paquet @solana-program/token. Token 2022 expose la même instruction via son propre paquet.
Qui doit signer le retrait ?
L'autorisation dépend du compte visé.
| Compte source | Signataire attendu |
|---|---|
| Compte de jetons | Le propriétaire du compte |
| Mint | L'autorité de mint |
| Mint dont l'autorité a été révoquée | Le mint lui-même, avec sa propre clé |
Et les comptes détenus par un programme ?
Le Token Program n'agit que sur les comptes qu'il possède. Pour une PDA appartenant à un programme tiers, position DeFi, compte de configuration ou coffre d'escrow, l'équipe doit écrire son propre code. Un transfert par le System Program ne fonctionne pas, celui-ci ne déplaçant des lamports que depuis les comptes qu'il détient. Le programme propriétaire modifie donc directement les soldes, en débitant le compte cible et en créditant la destination dans la même instruction. La documentation liste cinq vérifications avant d'expédier une telle instruction :
- le compte cible appartient bien au programme, faute de quoi la modification directe échoue
- le signataire est celui autorisé à déclencher le retrait
- le plancher est lu dans le sysvar Rent au moment de l'exécution
- seul l'excédent bouge, la réserve reste en place pour que le compte survive
- la somme des lamports reste conservée entre les comptes de la transaction
Le raisonnement vaut à l'identique pour Anchor, Rust natif ou Pinocchio. Le framework ne change que l'enveloppe autour du calcul.
Que faut-il corriger dans le code existant ?
Solana demande de supprimer les constantes de rent codées en dur. Le montant doit être demandé au réseau à chaque création de compte, par Rent::get() côté programme ou getMinimumBalanceForRentExemption côté client. Un programme qui lit la valeur courante reste juste à chaque étape du déploiement, sans intervention. Le code du processeur on-chain de WithdrawExcessLamports et des exemples de realloc pour Anchor, Rust natif et Pinocchio sont publiés sur les dépôts GitHub de Solana.
