Skip to main content
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.
Lisez d’abord Modèle de compte si vous découvrez comment les comptes Solana sont financés.

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éduit lamports_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 conservent 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 :
Pour un compte de jeton SPL de 165 octets après l’étape 1, c’est 293 × (6 960 − 6 333) = 183 711 lamports, ou ~0,000184 SOL par compte. Un compte Token-2022 portant des extensions est plus volumineux, il conserve 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. Que vous puissiez 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.
Concrètement, pour les types de comptes que les utilisateurs de Raydium détiennent : Les comptes SOL enrobés sont l’une exception au programme de jeton : leur solde de 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 jetons. De spl-token-interface :
Trois propriétés la rendent sûre de déclencher sur chaque compte d’un portefeuille :
  • 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.
Un compte de jeton gelé est toujours admissible : le gel restreint le mouvement des jetons, pas des lamports.

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 épelle l’identifiant WithdrawalExcessLamports, avec le « al » supplémentaire, donc cherchez cela :
Encodez-la directement. La charge utile est un seul octet discriminant :
Passez le 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 instruction WithdrawExcessLamports 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 regroupées. L’analyse est en lecture seule — aucune signature jusqu’à ce que vous appuyiez sur Reclaim all rent. La page couvre délibérément les comptes de jetons uniquement. 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 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.
Deux scripts dans raydium-sdk-V2-demo/src/rent :
reclaimRent.ts regroupe à 20 comptes par transaction et signe tous les lots en une seule passe :
Simulez avant d’envoyer. simulateTransaction avec accounts.addresses retourne les soldes de lamports post-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 jetons 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 gagné une instruction d’administrateur le 2026-09-09 pour le restituer, et CLMM a suivi le 2026-09-30 : Les adresses sont dans reference/program-addresses. L’AMM stable n’a pas d’équivalent. 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 intacts, 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 aucune action côté utilisateur, aucun opt-in, et aucune date limite.

Les trois formes de compte que chaque programme gère

Les quatre suivent le même envoi, sur le propriétaire du compte source :
  • Un compte de jeton ou une monnaie appartenant à un PDA d’autorité du programme : le programme CPI l’instruction WithdrawExcessLamports du programme de jeton (discriminant 38), en signant comme ce PDA. Dans CLMM, ce PDA est le PoolState lui-même, donc un appel couvre les coffres d’un pool.
  • Un coffre SOL enrobé — WithdrawExcessLamports refuse les comptes natifs, donc le programme SyncNative d’abord (ce qui replie l’excédent donné dans le amount enrobé), mesure exactement combien le montant enrobé a grandi, UnwrapLamports pour 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 une LamportsCalculateError. 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, une PlatformConfig, un TickArrayState CLMM, 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.
Les comptes appartenant à autre chose sont ignorés silencieusement, donc passer un compte non lié est inoffensif plutôt que fatal. La séquence SOL enrobée vaut la peine d’être copiée si vous détenez vos propres comptes natifs : c’est le seul moyen de prendre l’excédent d’un compte wSOL sans changer ce que le compte rapporte comme solde de jetons.
Ces chemins dépendent du programme de jeton déployé, pas d’une version de caisse. Les quatre programmes encodent à la main les instructions de jeton — un seul octet 38 pour WithdrawExcessLamports, 45 plus une 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 du mainnet. Un validateur local ou un harnais de test exécutant une version plus ancienne du SPL Token fourni ne les implémente pas, et un balayage contre lui échoue sur un discriminateur inconnu plutôt que sur quelque chose dans le programme Raydium. Testez ces chemins contre un programme de jeton cloné du mainnet.

Ce qui ne peut toujours pas être récupéré sur place

Vous ne pouvez toujours pas récupérer le loyer d’une position CLMM sur place vous-même. Il revient à la fermeture de la position, comme le dit le tableau ci-dessus. Le CollectExcessLamports propre de CLMM ne vérifie pas qui a financé un compte, il peut donc prendre l’excédent d’un PersonalPositionState ou LimitOrderState. Le compte reste à son minimum de loyer, et c’est ce minimum que la fermeture restitue. Même pour la monnaie de base LaunchLab : l’instruction d’initialisation révoque MintTokens dans le même appel qui frappe l’offre, donc aucune clé ne peut jamais signer un WithdrawExcessLamports pour cette monnaie 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é, aucune date limite 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.
Le seul vrai coût de la récupération précoce est les frais de base, et le seul vrai coût de l’attente est que les lamports restent immobiles un peu plus longtemps.

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.

Loyer réduit

Page de déploiement de Solana : étape actuelle, calendrier, et ce qui change pour les nouveaux comptes.

Réduction de loyer : une analyse soutenue par les données

L’économie, et le risque de croissance d’état que le déploiement échelonné est conçu pour gérer.

Modèle de compte

Comment les comptes Solana sont financés, possédés et fermés — le contexte pour tout ce qui précède.