> ## Documentation Index > Fetch the complete documentation index at: https://docs.raydium.io/llms.txt > Use this file to discover all available pages before exploring further. # Loyer et loyer récupérable > Solana réduit le minimum exempt de loyer de 90 % en cinq étapes selon SIMD-0437. Les comptes financés avant chaque étape conservent plus que nécessaire — découvrez quel est cet excédent, quels programmes le restituent, et comment le trouver et le récupérer. **Cette page est traduite automatiquement par IA. La version anglaise fait foi.** [Voir la version anglaise →](/solana-fundamentals/rent-and-reclaimable-rent) 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](/fr/solana-fundamentals/account-model) 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 : ``` minimum_balance(data_len) = (ACCOUNT_STORAGE_OVERHEAD + data_len) × lamports_per_byte ``` `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. | Étape | `lamports_per_byte` | Réduction par rapport à l'original | Loyer pour un compte de jetons de 165 octets | | ------------ | ------------------- | ---------------------------------- | -------------------------------------------- | | — (original) | 6 960 | — | 2 039 280 lamports | | 1 | 6 333 | 9 % | 1 855 569 lamports | | 2 | 5 080 | 27 % | 1 488 440 lamports | | 3 | 2 575 | 63 % | 754 475 lamports | | 4 | 1 322 | 81 % | 387 346 lamports | | 5 | 696 | 90 % | 203 928 lamports | 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 : ``` excess = (128 + data_len) × (old_rate − new_rate) ``` 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. Les deux exposent `WithdrawExcessLamports`. Le compte reste ouvert, conserve son solde de jetons, et tombe simplement au minimum actuel. 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 : | Compte | Propriétaire | Peut restituer l'excédent sur place ? | | ----------------------------------- | --------------------------------------------- | ------------------------------------------------------------------ | | Compte de jetons SPL | `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA` | Oui — `WithdrawExcessLamports` | | Compte de jetons Token-2022 | `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` | Oui — `WithdrawExcessLamports` | | Compte de jetons SOL enrobé (natif) | l'un ou l'autre programme de jetons | Non — voir ci-dessous | | Position CLMM | Raydium CLMM | Non — le loyer est restitué à la fermeture de la position | | Ordres ouverts OpenBook v1 | OpenBook v1 | Non — `CloseOpenOrders` uniquement | | Ordres ouverts OpenBook v2 | OpenBook v2 | Non — `close_open_orders_account` uniquement | | Compte de mise en jeu | Programme de mise en jeu | Non — SIMD-0490 épingle `rent_exempt_reserve` à 2 282 880 lamports | 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` : ```rust theme={null} /// This instruction is to be used to rescue SOL sent to any TokenProgram /// owned account by sending them to any other account, leaving behind only /// lamports for rent exemption. /// /// 0. `[writable]` Source Account owned by the token program /// 1. `[writable]` Destination account /// 2. `[signer]` Authority /// 3. `..3+M` `[signer]` M signer accounts WithdrawExcessLamports, ``` 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 : ```ts theme={null} // packages/spl-token/src/instructions/types.ts export enum TokenInstruction { // ... TransferHookExtension = 36, // ConfidentialTransferFeeExtension = 37, // WithdrawalExcessLamports = 38, // ← not exposed MetadataPointerExtension = 39, // ... } ``` Encodez-la directement. La charge utile est un seul octet discriminant : ```ts theme={null} import { PublicKey, TransactionInstruction } from "@solana/web3.js"; export function createWithdrawExcessLamportsInstruction(params: { source: PublicKey; // the token account holding excess lamports destination: PublicKey; // where the excess goes — usually the wallet itself authority: PublicKey; // owner of `source`, or the multisig account multiSigners?: PublicKey[]; programId: PublicKey; // TOKEN_PROGRAM_ID or TOKEN_2022_PROGRAM_ID }): TransactionInstruction { const { source, destination, authority, multiSigners = [], programId } = params; return new TransactionInstruction({ programId, keys: [ { pubkey: source, isSigner: false, isWritable: true }, { pubkey: destination, isSigner: false, isWritable: true }, { pubkey: authority, isSigner: !multiSigners.length, isWritable: false }, ...multiSigners.map((pubkey) => ({ pubkey, isSigner: true, isWritable: false })), ], data: Buffer.from([38]), }); } ``` 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 : ```ts theme={null} const [tokenResp, token2022Resp] = await Promise.all([ connection.getTokenAccountsByOwner(owner, { programId: TOKEN_PROGRAM_ID }), connection.getTokenAccountsByOwner(owner, { programId: TOKEN_2022_PROGRAM_ID }), ]); const raw = [...tokenResp.value, ...token2022Resp.value]; // one lookup per distinct account size — a wallet normally has two or three const spaces = Array.from(new Set(raw.map(({ account }) => account.data.length))); const minimums = new Map( await Promise.all( spaces.map(async (space) => [space, await connection.getMinimumBalanceForRentExemption(space)] as const), ), ); const reclaimable = raw.filter(({ account }) => { // wrapped SOL carries its token balance as lamports — both programs refuse it. // The `is_native` COption tag sits at offset 109 in the token account layout, // which Token-2022 preserves before its extension data. if (account.data.readUInt32LE(109) === 1) return false; return account.lamports > minimums.get(account.data.length)!; }); ``` `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](https://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`](https://github.com/raydium-io/raydium-sdk-V2-demo/tree/master/src/rent) : ```bash theme={null} # read-only: what can this wallet reclaim, and what would it be worth after all five steps yarn dev src/rent/checkReclaimableRent.ts yarn dev src/rent/checkReclaimableRent.ts # build, simulate (DRY_RUN = true by default), then send the batched sweep yarn dev src/rent/reclaimRent.ts ``` `reclaimRent.ts` regroupe à 20 comptes par transaction et signe tous les lots en une seule passe : ```ts theme={null} const batches = chunk(report.accounts, ACCOUNTS_PER_TX); const builtTxs = await Promise.all( batches.map(async (batch) => { const builder = new TxBuilder({ connection, feePayer: owner.publicKey, cluster: raydium.cluster, owner: raydium.owner, }); builder.addInstruction({ instructions: batch.map((account) => createWithdrawExcessLamportsInstruction({ source: account.pubkey, destination: owner.publicKey, authority: owner.publicKey, programId: account.programId, }), ), }); return builder.versionBuild({ txVersion }); }), ); // versionMultiBuild puts the calling builder's transaction first and appends // extraPreBuildData after it, so batch 1 drives and batches 2..n follow in order const [firstTx, ...restTxs] = builtTxs; const { execute } = await firstTx.builder.versionMultiBuild({ txVersion, extraPreBuildData: restTxs }); const { txIds } = await execute({ sequentially: true }); ``` 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 La proposition elle-même — les cinq portes de fonctionnalités et la justification de l'échelonnement de la réduction. Page de déploiement de Solana : étape actuelle, calendrier, et ce qui change pour les nouveaux comptes. L'économie, et le risque de croissance d'état que le déploiement échelonné est conçu pour gérer. Comment les comptes Solana sont financés, possédés et fermés — le contexte pour tout ce qui précède.