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 →
La renta es un depósito reembolsable, no una tarifa. SIMD-0437 reduce el depósito que debe mantener cada cuenta, en cinco pasos independientes. 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.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:ACCOUNT_STORAGE_OVERHEAD son 128 bytes fijos 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 reducelamports_per_byte de 6,960 a 696 — una reducción del 90% — implementada a través de cinco compuertas de características separadas para que los validadores puedan absorber el efecto del crecimiento del estado de uno en uno.
El paso 1 se activó en mainnet el 3 de septiembre de 2026. El paso 2 llegó a testnet el mismo día y se espera en mainnet a mediados de septiembre de 2026; los pasos 3–5 se reservan para Agave 4.4, esperado alrededor de noviembre de 2026. Trata el cronograma como sujeto a cambios — la Fundación ha dicho que pausará el despliegue si el crecimiento del estado se comporta mal — y lee el valor en vivo del clúster en lugar de codificarlo.
SIMD-0437 depende de SIMD-0194, que depreca el umbral de exención de renta “para evitar matemáticas innecesarias de punto flotante al establecer los parámetros de renta en la activación de características”. 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 clúster responda.Por qué las cuentas existentes mantienen 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: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 mantiene 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 después del 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.SPL Token y Token-2022
Ambos exponen
WithdrawExcessLamports. La cuenta permanece abierta, mantiene su saldo de tokens, y simplemente cae al mínimo actual.Todo lo demás
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.
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. Ambos programas en su lugar exponen UnwrapLamports (discriminante 45) para ese caso — está en spl-token-interface junto a WithdrawExcessLamports, por lo que el programa heredado también lo tiene, no solo Token-2022 — y @solana/spl-token envía createUnwrapLamportsInstruction para ello a partir de 0.4.15. Salta las cuentas nativas en un barrido de renta simple y manéjalas deliberadamente; el patrón para hacerlo de forma segura es el que usan los propios programas de Raydium, abajo.
La instrucción WithdrawExcessLamports
Discriminante 38 en los enums de instrucciones de ambos programas de token. De spl-token-interface:
- 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 a medida que 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.
Construyendo la instrucción
@solana/spl-token no exporta un constructor para ella. A partir de 0.4.15 la entrada del enum aún está comentada — y ten en cuenta que upstream escribe el identificador WithdrawalExcessLamports, con el “al” extra, así que busca eso con grep:
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 clúster qué necesita cada cuenta ahora mismo, para que el mismo código siga funcionando a través de los cinco pasos:getMinimumBalanceForRentExemption(0) es un canal secundario útil: devuelve exactamente 128 × lamports_per_byte, por lo que dividir por 128 te dice en qué paso de despliegue está el clúster sin analizar la sysvar Rent.
Agrupamiento: cuántos caben en una transacción
Cada instrucciónWithdrawExcessLamports 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 25 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 implementación propia 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 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. Estas demostraciones apuntan a
@raydium-io/raydium-sdk-v2@0.2.64-alpha contra Solana mainnet-beta, verificado 2026-09; el repositorio raydium-sdk-V2-demo en sí actualmente instala 0.2.62-alpha, y los dos son intercambiables aquí. WithdrawExcessLamports se codifica a mano y es independiente de la versión del SDK — el SDK se usa solo para construcción de transacciones y agrupamiento.raydium-sdk-V2-demo/src/rent:
reclaimRent.ts agrupa a 20 cuentas por transacción y firma todos los lotes en un solo paso:
simulateTransaction con accounts.addresses devuelve saldos de lamports posteriores a la ejecución, que es la forma más barata de confirmar que la aritmética coincide con lo que el clúster realmente hará.
Qué barren los programas de Raydium por su lado
Tu billetera no es el único lugar donde la reducción libera lamports. Cada pool mantiene renta también — bóvedas, mints de LP, y las cuentas de estado propiedad del programa que fueron todas financiadas a la tasa antigua. Esa renta pertenece al protocolo, no a los LP: fue pagada por quien creó la cuenta, no es parte de las reservas de ningún pool, y nunca entró en la curva. Tres programas ganaron una instrucción de administrador el 2026-09-09 para devolverla:
Las direcciones están en
reference/program-addresses. CLMM y Stable AMM no fueron parte de ese lanzamiento.
Nada aquí afecta a un LP o a un comerciante. Estas instrucciones mueven lamports y solo lamports. Los saldos de tokens, datos de cuenta, propietarios, estado del pool, suministro de LP, contadores de tarifas y la curva están todos intactos, y ninguno de ellos puede cerrar una cuenta. La cotización de un pool para un swap es idéntica antes y después de un barrido. No hay acción del lado del usuario, sin opt-in, y sin plazo.
Las tres formas de cuenta que cada programa maneja
Los tres siguen el mismo envío, en el propietario de la cuenta de origen:- Una cuenta de token o mint propiedad de un PDA de autoridad del programa — el programa CPI la
WithdrawExcessLamportsdel programa de token (discriminante 38), firmando como ese PDA. - Una bóveda de SOL envuelto —
WithdrawExcessLamportsrechaza cuentas nativas, por lo que el programa primeroSyncNative(que pliega el exceso donado en elamountenvuelto), mide exactamente cuánto creció el monto envuelto,UnwrapLamportspara ese delta, y luego afirma que el saldo envuelto vuelve a su valor anterior a la sincronización. Si esa verificación falla, toda la instrucción se revierte con unLamportsCalculateError. Por eso una bóveda de pool del lado de SOL mantiene su liquidez completa a través de un barrido. - Una cuenta de estado propiedad del programa —
AmmInfo,PoolState,AmmConfig,ObservationState, unPlatformConfig, y así sucesivamente. Un programa puede debitar sus propias cuentas directamente, por lo que mueve el saldo hacia abajo arent.minimum_balance(data_len)sin CPI en absoluto.
Estas rutas dependen del programa de token implementado, no de una versión de crate. Los tres programas codifican a mano las instrucciones de token — un único byte
38 para WithdrawExcessLamports, 45 más un COption<u64> para UnwrapLamports — y las envían a cualquier programa de token que posea la cuenta de origen. Ambas instrucciones existen en los programas actuales de SPL Token y Token-2022 de mainnet. Un validador local o arnés de prueba que ejecute una compilación más antigua de SPL Token agrupada no las implementa, y un barrido contra él falla en un discriminador desconocido en lugar de en algo en el programa de Raydium. Prueba estas rutas contra un programa de token clonado de mainnet.Qué aún no puede ser reclamado en su lugar
La renta de una posición CLMM no cambia por todo esto — vuelve cuando se cierra la posición, como dice la tabla anterior. Lo mismo para el mint base de LaunchLab: la instrucción de inicialización revocaMintTokens en la misma llamada que acuña el suministro, por lo que ninguna clave puede firmar nunca un WithdrawExcessLamports para ese mint y su renta está varada por diseño.
¿Deberías reclamar ahora o esperar?
Ambos están bien, y la diferencia es pequeña de cualquier forma:- El exceso no va a ningún lado. Se sienta en tus propias cuentas. Nada expira, nada se barre, no se aplica 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 los 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.
Lectura adicional
SIMD-0437
La propuesta en sí — las cinco compuertas de características y la justificación para escalonar la reducción.
Renta reducida
Página de despliegue de Solana: paso actual, cronograma, y qué cambia para nuevas cuentas.
Reducción de renta: un análisis respaldado por datos
La economía, y el riesgo de crecimiento del estado que el despliegue escalonado está diseñado para manejar.
Modelo de cuentas
Cómo se financian, poseen y cierran las cuentas de Solana — el trasfondo para todo lo anterior.

