Solana baja el precio del almacenamiento por cuentas: queda saldo recuperable
La red recorta un 90% el coste de mantener cuentas en cinco pasos. Las creadas al precio viejo guardan lamports de más que se pueden retirar sin cerrarlas.
Solana está bajando el precio de mantener una cuenta en la red, el llamado alquiler, un 90% repartido en cinco pasos que se activan por feature gate. Las cuentas creadas al precio antiguo no han perdido lamports: siguen dentro, y en cuatro tipos se pueden sacar sin cerrarlas.
El cálculo es ahora una sola multiplicación: (128 + longitud de los datos) × lamports por byte. Los 128 son un coste fijo por cuenta, y el multiplicador de dos años que antes lo complicaba quedó integrado en el precio por byte a principios de año. La escalera va de 6.960 lamports por byte a 696: 6.960 → 6.333 → 5.080 → 2.575 → 1.322 → 696. El 11 de septiembre de 2026 se activó el segundo escalón, 5.080, un recorte del 27%; en mainnet seguía ahí el 17 de septiembre. Quedan tres pasos, previstos con Agave 4.4.
El excedente frente al precio original sale de (128 + longitud) × 1.880 lamports. Al final de la escalera será (128 + longitud) × 6.264, esto es, nueve décimos de lo que se depositó en su día. Traducido a cuentas concretas:
- nonce, 80 bytes: unos 0,00039 SOL hoy y 0,0013 SOL al final
- stake, 200 bytes: 0,00062 SOL hoy y 0,0021 SOL al final
- vote, 3.762 bytes: 0,0073 SOL hoy y 0,024 SOL al final
- token, 165 bytes: 0,00055 SOL hoy y 0,0018 SOL al final
Por cuenta es calderilla. Multiplicado por lo que maneja un validador con cien cuentas nonce para una canalización de firmas, un programa de distribución que creó diez mil cuentas stake o un market maker con mil cuentas token, es una línea con peso, y engorda en cada escalón. El excedente solo existe en las cuentas creadas antes de cada paso: las que nazcan después del último ya pagan el precio final y no tienen nada que reclamar. El stock de cuentas sobrefinanciadas se cierra el día que termine la escalera y solo mengua según la gente se entera.
Qué instrucción retira el excedente
Cada programa protege sus cuentas, así que hay cuatro instrucciones distintas con una regla común: la cuenta conserva al menos el mínimo exento de alquiler y firma su propia autoridad. Las nonce usan WithdrawNonceAccount, firmada por la autoridad nonce. Las stake, el Withdraw del programa de stake, firmada por la autoridad de retirada; en una cuenta delegada solo se puede sacar lo que supere el stake delegado más la reserva, y en una desactivada, todo lo que pase de la reserva. Las vote, el Withdraw del programa de voto, firmado por el withdrawer autorizado, que ha de dejar el mínimo exento más las recompensas pendientes de los delegadores: ese dinero está en el saldo, pero no es suyo. Las token, WithdrawExcessLamports, firmada por el propietario; es una instrucción que los dos programas de token llevan justo para este caso.
Ninguna cierra nada. La herramienta de la app arma el lote con las cuentas que controla una wallet conectada y la wallet lo firma. Con Alpenglow activo —el 17 de septiembre de 2026 no lo estaba en mainnet— la cuenta vote tendrá que guardar además el ticket de admisión de una época: 1,2 SOL con slots de 300 ms y 1,0 SOL a partir de la época 1037, cuando los slots bajen a 250 ms.
La marcha atrás y los IDs que se renumeran
La escalera tiene reversa. Un feature gate llamado set_lamports_per_byte_to_6960 devuelve el precio original; a 17 de septiembre no se había activado en mainnet, y la regla de ordenación del validador le da prioridad: si una vuelta atrás y un recorte se activan en la misma época, gana la vuelta atrás. Para los recortes, si varios coinciden en una época gana el precio más bajo, y si se activan desordenados gana el que entró más tarde.
Quien planifique crear cuentas esperando un escalón más barato se juega eso: un lote que se deja "para después del próximo recorte" puede acabar cayendo después de una reversión. Toca vigilar las dos direcciones y mirar qué escalón está activo en el build que se ejecute.
Los feature gates se identifican por claves públicas, y esas claves no son estables hasta que la funcionalidad se activa. El 11 de septiembre de 2026 el gate de reversión de SIMD-0438 y los recortes que quedan de SIMD-0437 se renumeraron en el código del validador. Cualquier panel, script o marcador que siguiera los IDs viejos vigila cuentas que no se activarán nunca. Es lo normal con funcionalidad sin activar, y la razón de releer los IDs del release que se esté ejecutando en cada versión.
