> ## 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.
# Renta y renta reclamable
> Solana está reduciendo el mínimo exento de renta en un 90% en cinco pasos bajo SIMD-0437. Las cuentas financiadas antes de cada paso ahora contienen más de lo que necesitan — qué es ese exceso, qué programas lo devuelven, y cómo encontrarlo y reclamarlo.
**Esta página fue traducida automáticamente por IA. La versión en inglés es la fuente autorizada.**
[Ver versión en inglés →](/solana-fundamentals/rent-and-reclaimable-rent)
La renta es un depósito reembolsable, no una tarifa. SIMD-0437 reduce el depósito que cada cuenta debe mantener, en cinco pasos independientes controlados por feature gates. Las cuentas creadas antes de un paso conservan el saldo con el que fueron financiadas, por lo que cada paso las deja sobrefinanciadas. Los programas SPL Token y Token-2022 pueden devolver esa diferencia a través de `WithdrawExcessLamports` sin cerrar la cuenta ni tocar su saldo de tokens. Nada expira — el exceso permanece en tus propias cuentas hasta que decidas moverlo.
Lee primero [Modelo de cuentas](/es/solana-fundamentals/account-model) si eres nuevo en cómo se financian las cuentas en Solana.
## Qué es realmente la renta
Cada cuenta en Solana mantiene un depósito de SOL dimensionado por el espacio que ocupa. No se gasta — se devuelve en su totalidad cuando se cierra la cuenta. La fórmula es:
```
minimum_balance(data_len) = (ACCOUNT_STORAGE_OVERHEAD + data_len) × lamports_per_byte
```
`ACCOUNT_STORAGE_OVERHEAD` es un fijo de 128 bytes que cada cuenta paga independientemente de su contenido. `lamports_per_byte` es la constante de toda la red que SIMD-0437 cambia.
Una cuenta de token SPL estándar de 165 bytes ha costado por lo tanto siempre `(128 + 165) × 6,960 = 2,039,280` lamports — los \~0.00203928 SOL que ves deducidos cada vez que una billetera abre una cuenta de token asociada.
## Qué cambia SIMD-0437
SIMD-0437 reduce `lamports_per_byte` de 6,960 a 696 — una reducción del 90% — implementada a través de cinco feature gates separados para que los validadores puedan absorber el efecto del crecimiento del estado de uno en uno.
| Paso | `lamports_per_byte` | Reducción del original | Renta para una cuenta de token de 165 bytes |
| ------------ | ------------------- | ---------------------- | ------------------------------------------- |
| — (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 |
El paso 1 se activó en mainnet el 3 de septiembre de 2026. Los pasos restantes se implementan conforme se habilitan sus feature gates; trata el cronograma como sujeto a cambios y lee el valor actual del cluster en lugar de codificarlo.
SIMD-0437 depende de SIMD-0194, que depreca el umbral de exención de renta "para evitar matemática de punto flotante innecesaria al establecer los parámetros de renta en la activación de feature". En la práctica, la sysvar `Rent` ahora lleva `lamports_per_byte_year = 6,333` con `exemption_threshold = 1.0`, en lugar de la antigua división `3,480 × 2` que producía 6,960. No multipliques esos dos campos tú mismo — llama a `getMinimumBalanceForRentExemption` y deja que el cluster responda.
## Por qué las cuentas existentes contienen demasiado
Reducir la constante cambia lo que una cuenta *necesita*. No cambia lo que una cuenta *tiene*. Una cuenta financiada a 6,960 lamports por byte mantiene ese saldo después de que se active el paso 1, por lo que está sobrefinanciada por:
```
excess = (128 + data_len) × (old_rate − new_rate)
```
Para una cuenta de token SPL de 165 bytes después del paso 1, eso es `293 × (6,960 − 6,333) = 183,711` lamports, o \~0.000184 SOL por cuenta. Una cuenta de Token-2022 que lleva extensiones es más grande, por lo que contiene proporcionalmente más — una cuenta de 182 bytes está sobrefinanciada por `310 × 627 = 194,370` lamports.
Individualmente eso es insignificante. Una billetera que ha interactuado con algunos cientos de tokens a lo largo de los años está manteniendo un múltiplo significativo de eso, y en el paso 5 cada cuenta de 165 bytes tiene 1,835,352 lamports (\~0.00184 SOL) por encima de su mínimo.
## Qué cuentas pueden devolverlo
El exceso de lamports en una cuenta propiedad de un programa solo puede ser movido por ese programa. Si puedes reclamar renta sin cerrar la cuenta depende completamente de qué programa la posee.
Ambos exponen `WithdrawExcessLamports`. La cuenta permanece abierta, mantiene su saldo de tokens, y simplemente cae al mínimo actual.
Sin instrucción equivalente. La renta se libera solo cuando se cierra la cuenta — una operación destructiva con sus propias precondiciones, no un barrido de renta.
Concretamente, para los tipos de cuenta que los usuarios de Raydium mantienen:
| Cuenta | Propietario | ¿Puede devolver el exceso en su lugar? |
| ------------------------------------- | --------------------------------------------- | --------------------------------------------------------------- |
| Cuenta de token SPL | `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA` | Sí — `WithdrawExcessLamports` |
| Cuenta de token Token-2022 | `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb` | Sí — `WithdrawExcessLamports` |
| Cuenta de token SOL envuelto (nativo) | cualquier programa de token | No — ver abajo |
| Posición CLMM | Raydium CLMM | No — la renta se devuelve cuando se cierra la posición |
| Órdenes abiertas OpenBook v1 | OpenBook v1 | No — solo `CloseOpenOrders` |
| Órdenes abiertas OpenBook v2 | OpenBook v2 | No — solo `close_open_orders_account` |
| Cuenta de stake | Programa de Stake | No — SIMD-0490 fija `rent_exempt_reserve` en 2,282,880 lamports |
Las cuentas de SOL envuelto son la única excepción del programa de token: su saldo de lamports *es* su saldo de tokens, por lo que ambos programas las rechazan con `TokenError::NativeNotSupported`. Token-2022 añadió `UnwrapLamports` (discriminante 45) para ese caso; `@solana/spl-token` envía `createUnwrapLamportsInstruction` para ello a partir de 0.4.15. Salta las cuentas nativas en un barrido de renta y manéjalas deliberadamente.
## La instrucción `WithdrawExcessLamports`
Discriminante **38** en los enums de instrucción de ambos programas de token. 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,
```
Tres propiedades la hacen segura de ejecutar en cada cuenta de una billetera:
* **No toma una cantidad.** El programa calcula `source.lamports − rent.minimum_balance(source.data_len())` por sí mismo, por lo que nunca puede llevar una cuenta por debajo del mínimo actual, y permanece correcta conforme se activan los pasos posteriores.
* **No cierra nada.** La cuenta mantiene sus datos, su propietario y su saldo de tokens.
* **Es idempotente.** Ejecutarla contra una cuenta ya en el mínimo mueve cero lamports y tiene éxito.
Una cuenta de token congelada sigue siendo elegible: congelar restringe el movimiento de tokens, no de lamports.
### Construyendo la instrucción
`@solana/spl-token` no exporta un constructor para ella. A partir de `0.4.15` la entrada del enum sigue comentada:
```ts theme={null}
// packages/spl-token/src/instructions/types.ts
export enum TokenInstruction {
// ...
TransferHookExtension = 36,
// ConfidentialTransferFeeExtension = 37,
// WithdrawalExcessLamports = 38, // ← not exposed
MetadataPointerExtension = 39,
// ...
}
```
Codifícala directamente. El payload es un único byte discriminante:
```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]),
});
}
```
Pasa el `programId` de cada cuenta. Las instrucciones de SPL Token y Token-2022 pueden compartir una transacción, pero cada una debe dirigirse al programa que posee su cuenta de origen.
Medido en mainnet, la instrucción cuesta 270 unidades de cómputo en el programa SPL Token y 1,414 en Token-2022 — insignificante de cualquier forma. La restricción real es el tamaño de la transacción, no el cómputo.
## Encontrando cuentas reclamables
No derives el exceso de una tasa codificada. Pregunta al cluster qué necesita cada cuenta ahora mismo, para que el mismo código siga funcionando a través de los cinco pasos:
```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)` es un canal lateral útil: devuelve exactamente `128 × lamports_per_byte`, por lo que dividir por 128 te dice en qué paso de implementación está el cluster sin analizar la sysvar `Rent`.
## Agrupamiento: cuántas caben en una transacción
Cada instrucción `WithdrawExcessLamports` contribuye una clave de cuenta escribible única — 32 bytes en el mensaje compilado — más aproximadamente 7 bytes de codificación de instrucción. Destino, autoridad y pagador de tarifa son todos la misma billetera, por lo que cuestan una clave entre ellos.
Contra el límite de transacción de 1,232 bytes, aproximadamente 26 instrucciones caben una vez que se cuentan las instrucciones de presupuesto de cómputo y el blockhash. **Veinte por transacción** es el número de trabajo seguro, y es lo que usa la propia implementación de Raydium. Una billetera con 116 cuentas reclamables por lo tanto barre en seis transacciones, a una tarifa base de 5,000 lamports cada una.
Ten en cuenta la economía: la tarifa se cobra por transacción, no por cuenta. Reclamar menos cuentas no cuesta menos, por lo que un barrido parcial rara vez vale los viajes redondos adicionales.
## Reclamando a través de Raydium
La página [raydium.io/reclaim-rent](https://raydium.io/reclaim-rent) escanea las cuentas de SPL Token y Token-2022 de la billetera conectada, muestra el total dividido por programa, y barre todo en transacciones agrupadas. El escaneo es de solo lectura — sin firma hasta que presiones **Reclaim all rent**.
La página deliberadamente cubre solo cuentas de token. Los tipos de cuenta que pueden liberar renta solo cerrándose se excluyen en lugar de listarse como no disponibles, porque cerrar una cuenta es una acción diferente y destructiva.
## Reclamando desde la demostración del SDK
**Banner de versión.** Las demostraciones apuntan a `@raydium-io/raydium-sdk-v2@0.2.42-alpha` contra Solana mainnet-beta, verificado 2026-09. `WithdrawExcessLamports` se codifica a mano y es independiente de la versión del SDK; el SDK se usa solo para construcción y agrupamiento de transacciones.
Dos scripts en [`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` agrupa a 20 cuentas por transacción y firma todos los lotes en un solo paso:
```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 });
```
Simula antes de enviar. `simulateTransaction` con `accounts.addresses` devuelve saldos de lamports post-ejecución, que es la forma más barata de confirmar que la aritmética coincide con lo que el cluster realmente hará.
## ¿Deberías reclamar ahora o esperar?
Ambas opciones están bien, y la diferencia es pequeña de cualquier forma:
* **El exceso no va a ningún lado.** Permanece en tus propias cuentas. Nada expira, nada se barre, no hay plazo.
* **Esperar se compone.** Cada paso libera más de las mismas cuentas, y un barrido después del paso 5 cuesta lo mismo en tarifas que un barrido hoy.
* **Reclamar ahora no renuncia a pasos posteriores.** Una cuenta que barres hoy simplemente está en el mínimo actual; el siguiente paso la deja sobrefinanciada de nuevo y puedes barrerla de nuevo.
El único costo real de reclamar temprano es la tarifa base, y el único costo real de esperar es que los lamports permanezcan inmóviles un poco más.
## Lectura adicional
La propuesta en sí — los cinco feature gates y la justificación para escalonar la reducción.
Página de implementación de Solana: paso actual, cronograma, y qué cambia para nuevas cuentas.
La economía, y el riesgo de crecimiento del estado que la implementación escalonada está diseñada para gestionar.
Cómo se financian, poseen y cierran las cuentas de Solana — el trasfondo para todo lo anterior.