Skip to main content
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 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 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:
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. 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:
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.

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.
Concretamente, para los tipos de cuenta que los usuarios de Raydium mantienen: 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:
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:
Codifícala directamente. El payload es un único byte discriminante:
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:
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 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:
reclaimRent.ts agrupa a 20 cuentas por transacción y firma todos los lotes en un solo paso:
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

SIMD-0437

La propuesta en sí — los cinco feature gates y la justificación para escalonar la reducción.

Renta reducida

Página de implementación 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 la implementación escalonada está diseñada para gestionar.

Modelo de cuentas

Cómo se financian, poseen y cierran las cuentas de Solana — el trasfondo para todo lo anterior.