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 au solde des 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 SPL Token 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 jetons 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. Les étapes restantes arrivent à mesure que leurs portes de fonctionnalités sont activées ; considérez le calendrier comme sujet à modification 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 :
Pour un compte SPL Token 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 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 tombe 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 des exceptions du programme de jetons : leur solde en lamports est leur solde en jetons, donc les deux programmes les rejettent avec TokenError::NativeNotSupported. Token-2022 a ajouté UnwrapLamports (discriminant 45) pour ce cas ; @solana/spl-token expédie createUnwrapLamportsInstruction à partir de 0.4.15. Ignorez les comptes natifs dans un balayage de loyer et traitez-les délibérément.

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 à exécuter 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 tomber un compte en dessous du minimum actuel, et 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 jetons 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 :
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 indique à 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 26 instructions tiennent une fois que les instructions de budget de calcul et le blockhash sont comptabilisé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 cher, 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 — 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. Les démos ciblent @raydium-io/raydium-sdk-v2@0.2.42-alpha contre Solana mainnet-beta, vérifiées en 2026-09. 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 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.

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 basée sur 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.