Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
Le loyer est un dépôt remboursable, pas une commission. SIMD-0437 abaisse le dépôt que chaque compte doit conserver, en cinq étapes indépendantes. Les comptes créés avant une étape conservent le solde avec lequel ils ont été financés, donc chaque étape les laisse surfinancés. Les programmes SPL Token et Token-2022 peuvent restituer cette différence via
WithdrawExcessLamports sans fermer le compte ni toucher à son solde de jetons. Rien n’expire — l’excédent reste dans vos propres comptes jusqu’à ce que vous décidiez de le déplacer.Ce qu’est réellement le loyer
Chaque compte sur Solana détient un dépôt en SOL dimensionné par l’espace qu’il occupe. Il n’est pas dépensé — il est restitué intégralement à la fermeture du compte. La formule est :ACCOUNT_STORAGE_OVERHEAD est un nombre fixe de 128 octets que chaque compte paie indépendamment de sa charge utile. lamports_per_byte est la constante à l’échelle du réseau que SIMD-0437 modifie.
Un compte de jeton SPL standard de 165 octets a donc toujours coûté (128 + 165) × 6 960 = 2 039 280 lamports — les ~0,00203928 SOL que vous voyez déduits chaque fois qu’un portefeuille ouvre un compte de jeton associé.
Ce que SIMD-0437 change
SIMD-0437 réduitlamports_per_byte de 6 960 à 696 — une réduction de 90 % — déployée via cinq portes de fonctionnalités distinctes pour que les validateurs puissent absorber l’effet de croissance d’état une étape à la fois.
L’étape 1 s’est activée sur mainnet le 3 septembre 2026. L’étape 2 a atteint testnet le même jour et devrait arriver sur mainnet à la mi-septembre 2026 ; les étapes 3–5 sont réservées à Agave 4.4, attendue vers novembre 2026. Considérez le calendrier comme sujet à changement — la Fondation a déclaré qu’elle pauserait le déploiement si la croissance d’état se comportait mal — et lisez la valeur en direct depuis le cluster plutôt que de la coder en dur.
SIMD-0437 dépend de SIMD-0194, qui déprécie le seuil d’exemption de loyer « pour éviter les mathématiques inutiles en virgule flottante lors de la définition des paramètres de loyer à l’activation de la fonctionnalité ». En pratique, la sysvar
Rent porte maintenant lamports_per_byte_year = 6 333 avec exemption_threshold = 1.0, plutôt que l’ancienne division 3 480 × 2 qui produisait 6 960. Ne multipliez pas ces deux champs vous-même — appelez getMinimumBalanceForRentExemption et laissez le cluster répondre.Pourquoi les comptes existants détiennent trop
Abaisser la constante change ce qu’un compte a besoin. Cela ne change pas ce qu’un compte possède. Un compte financé à 6 960 lamports par octet conserve ce solde après l’activation de l’étape 1, il est donc surfinancé de :293 × (6 960 − 6 333) = 183 711 lamports, ou ~0,000184 SOL par compte. Un compte Token-2022 portant des extensions est plus grand, il détient donc proportionnellement plus — un compte de 182 octets est surfinancé de 310 × 627 = 194 370 lamports.
Individuellement, c’est négligeable. Un portefeuille qui a interagi avec quelques centaines de jetons au fil des ans détient un multiple significatif de cela, et à l’étape 5, chaque compte de 165 octets a 1 835 352 lamports (~0,00184 SOL) au-dessus de son minimum.
Quels comptes peuvent le restituer
L’excédent de lamports dans un compte appartenant à un programme ne peut être déplacé que par ce programme. La possibilité de récupérer le loyer sans fermer le compte dépend donc entièrement du programme qui le possède.SPL Token et Token-2022
Les deux exposent
WithdrawExcessLamports. Le compte reste ouvert, conserve son solde de jetons, et descend simplement au minimum actuel.Tout le reste
Aucune instruction équivalente. Le loyer n’est libéré que lorsque le compte est fermé — une opération destructrice avec ses propres préconditions, pas un balayage de loyer.
Les comptes SOL enrobés sont l’une des exceptions du programme de jeton : leur solde en lamports est leur solde de jetons, donc les deux programmes les rejettent avec
TokenError::NativeNotSupported. Les deux programmes exposent plutôt UnwrapLamports (discriminant 45) pour ce cas — il est dans spl-token-interface aux côtés de WithdrawExcessLamports, donc le programme hérité l’a aussi, pas seulement Token-2022 — et @solana/spl-token expédie createUnwrapLamportsInstruction pour cela à partir de 0.4.15. Ignorez les comptes natifs dans un balayage de loyer simple et traitez-les délibérément ; le modèle pour le faire en toute sécurité est celui que les propres programmes de Raydium utilisent, ci-dessous.
L’instruction WithdrawExcessLamports
Discriminant 38 dans les énumérations d’instructions des deux programmes de jeton. De spl-token-interface :
- Elle ne prend pas de montant. Le programme calcule
source.lamports − rent.minimum_balance(source.data_len())lui-même, il ne peut donc jamais faire descendre un compte en dessous du minimum actuel, et il reste correct à mesure que les étapes ultérieures s’activent. - Elle ne ferme rien. Le compte conserve ses données, son propriétaire et son solde de jetons.
- Elle est idempotente. L’exécuter sur un compte déjà au minimum déplace zéro lamports et réussit.
Construire l’instruction
@solana/spl-token n’exporte pas de constructeur pour cela. À partir de 0.4.15, l’entrée d’énumération est toujours commentée — et notez que l’amont orthographie l’identifiant WithdrawalExcessLamports, avec le « al » supplémentaire, donc cherchez celui-là :
programId de chaque compte. Les instructions SPL Token et Token-2022 peuvent partager une transaction, mais chacune doit être adressée au programme qui possède son compte source.
Mesuré sur mainnet, l’instruction coûte 270 unités de calcul sur le programme SPL Token et 1 414 sur Token-2022 — négligeable de toute façon. La vraie contrainte est la taille de la transaction, pas le calcul.
Trouver les comptes récupérables
Ne dérivez pas l’excédent d’un taux codé en dur. Demandez au cluster ce que chaque compte a besoin maintenant, pour que le même code continue de fonctionner à travers les cinq étapes :getMinimumBalanceForRentExemption(0) est un canal auxiliaire utile : il retourne exactement 128 × lamports_per_byte, donc diviser par 128 vous dit à quelle étape de déploiement le cluster se trouve sans analyser la sysvar Rent.
Regroupement : combien tiennent dans une transaction
Chaque instructionWithdrawExcessLamports contribue une clé de compte inscriptible unique — 32 octets dans le message compilé — plus environ 7 octets d’encodage d’instruction. La destination, l’autorité et le payeur de frais sont tous le même portefeuille, ils coûtent donc une clé entre eux.
Contre la limite de 1 232 octets de transaction, environ 25 instructions tiennent une fois que les instructions de budget de calcul et le blockhash sont comptés. Vingt par transaction est le nombre de travail sûr, et c’est ce que l’implémentation propre de Raydium utilise. Un portefeuille avec 116 comptes récupérables balaie donc en six transactions, à 5 000 lamports de frais de base chacune.
Notez l’économie : les frais sont facturés par transaction, pas par compte. Récupérer moins de comptes ne coûte pas moins, c’est pourquoi un balayage partiel vaut rarement les allers-retours supplémentaires.
Récupération via Raydium
La page raydium.io/reclaim-rent analyse les comptes SPL Token et Token-2022 du portefeuille connecté, affiche le total divisé par programme, et balaie tout en transactions par lots. L’analyse est en lecture seule — pas de signature jusqu’à ce que vous appuyiez sur Reclaim all rent. La page couvre délibérément uniquement les comptes de jetons. Les types de comptes qui ne peuvent libérer le loyer qu’en fermant sont exclus plutôt que listés comme indisponibles, car fermer un compte est une action différente et destructrice.Récupération depuis la démo du SDK
Bannière de version. Ces démos ciblent
@raydium-io/raydium-sdk-v2@0.2.64-alpha contre Solana mainnet-beta, vérifiées en 2026-09 ; le dépôt raydium-sdk-V2-demo lui-même installe actuellement 0.2.62-alpha, et les deux sont interchangeables ici. WithdrawExcessLamports est encodé à la main et est indépendant de la version du SDK — le SDK est utilisé uniquement pour la construction et le regroupement de transactions.raydium-sdk-V2-demo/src/rent :
reclaimRent.ts regroupe à 20 comptes par transaction et signe tous les lots en une seule passe :
simulateTransaction avec accounts.addresses retourne les soldes en lamports après exécution, ce qui est le moyen le moins cher de confirmer que l’arithmétique correspond à ce que le cluster fera réellement.
Ce que les programmes Raydium balaient de leur côté
Votre portefeuille n’est pas le seul endroit où la réduction libère des lamports. Chaque pool détient aussi du loyer — les coffres, les mints LP, et les comptes d’état appartenant au programme qui ont tous été financés à l’ancien taux. Ce loyer appartient au protocole, pas aux LP : il a été payé par celui qui a créé le compte, il ne fait pas partie des réserves d’aucun pool, et il n’a jamais entré la courbe. Trois programmes ont reçu une instruction d’administrateur le 2026-09-09 pour le restituer :
Les adresses sont dans
reference/program-addresses. CLMM et Stable AMM ne faisaient pas partie de cette version.
Rien ici n’affecte un LP ou un trader. Ces instructions déplacent des lamports et uniquement des lamports. Les soldes de jetons, les données de compte, les propriétaires, l’état du pool, l’offre de LP, les compteurs de frais et la courbe sont tous intouchés, et aucun d’eux ne peut fermer un compte. Le devis d’un pool pour un swap est identique avant et après un balayage. Il n’y a pas d’action côté utilisateur, pas d’opt-in, et pas de délai.
Les trois formes de compte que chaque programme gère
Les trois suivent le même envoi, sur le propriétaire du compte source :- Un compte de jeton ou un mint appartenant à un PDA d’autorité du programme — le programme CPI l’instruction
WithdrawExcessLamportsdu programme de jeton (discriminant 38), en signant en tant que ce PDA. - Un coffre SOL enrobé —
WithdrawExcessLamportsrefuse les comptes natifs, donc le programmeSyncNatived’abord (ce qui replie l’excédent donné dans leamountenrobé), mesure exactement combien le montant enrobé a grandi,UnwrapLamportspour ce delta, puis affirme que le solde enrobé est revenu à sa valeur pré-sync. Si cette vérification échoue, l’instruction entière revient avec uneLamportsCalculateError. C’est pourquoi un coffre de pool côté SOL conserve sa liquidité complète à travers un balayage. - Un compte d’état appartenant au programme —
AmmInfo,PoolState,AmmConfig,ObservationState, unPlatformConfig, et ainsi de suite. Un programme peut débiter ses propres comptes directement, il déplace donc le solde jusqu’àrent.minimum_balance(data_len)sans CPI du tout.
Ces chemins dépendent du programme de jeton déployé, pas d’une version de caisse. Les trois programmes encodent à la main les instructions de jeton — un seul octet
38 pour WithdrawExcessLamports, 45 plus un COption<u64> pour UnwrapLamports — et les envoient au programme de jeton qui possède le compte source. Les deux instructions existent dans les programmes SPL Token et Token-2022 actuels de mainnet. Un validateur local ou un harnais de test exécutant une ancienne version groupée du SPL Token ne les implémente pas, et un balayage contre lui échoue sur un discriminateur inconnu plutôt que sur n’importe quoi dans le programme Raydium. Testez ces chemins contre un programme de jeton cloné de mainnet.Ce qui ne peut toujours pas être récupéré sur place
Le loyer d’une position CLMM est inchangé par tout cela — il revient à la fermeture de la position, comme le tableau ci-dessus le dit. Même chose pour le mint de base LaunchLab : l’instruction initialize révoqueMintTokens dans le même appel qui frappe l’offre, donc aucune clé ne peut jamais signer un WithdrawExcessLamports pour ce mint et son loyer est bloqué par conception.
Devriez-vous récupérer maintenant ou attendre ?
Les deux vont bien, et la différence est petite de toute façon :- L’excédent ne va nulle part. Il reste dans vos propres comptes. Rien n’expire, rien n’est balayé, aucun délai ne s’applique.
- Attendre compose. Chaque étape libère plus des mêmes comptes, et un balayage après l’étape 5 coûte les mêmes frais qu’un balayage aujourd’hui.
- Récupérer maintenant ne renonce pas aux étapes ultérieures. Un compte que vous balayez aujourd’hui est simplement au minimum actuel ; l’étape suivante le surfinance à nouveau et vous pouvez le balayer à nouveau.
Lectures complémentaires
SIMD-0437
La proposition elle-même — les cinq portes de fonctionnalités et la justification de l’échelonnement de la réduction.
Reduced rent
La page de déploiement de Solana : étape actuelle, calendrier, et ce qui change pour les nouveaux comptes.
Rent reduction: a data-backed analysis
L’économie, et le risque de croissance d’état que le déploiement échelonné est conçu pour gérer.
Account model
Comment les comptes Solana sont financés, possédés et fermés — le contexte pour tout ce qui précède.

