El plan de Solana de reducir en 90% los depósitos de cuentas podría debilitar una razón para mantener SOL

Los propietarios elegibles de cuentas de tokens de Solana ahora pueden reclamar el exceso de $SOL que antes se requería para mantener esas cuentas abiertas, tras la primera reducción de renta de la red, que entró en vigor el 3 de septiembre. Para las empresas que financian cuentas nuevas, el mismo cambio reduce el capital inicial necesario para crearlas.

El plan completo alteraría cómo se traduce el crecimiento de cuentas en $SOL retenido como respaldo del almacenamiento. Si Solana completa su reducción propuesta del 90%, el estado total de cuentas persistentes —incluida la sobrecarga de almacenamiento de cada cuenta— tendría que multiplicarse por diez para requerir las mismas reservas mínimas de $SOL que antes de la implementación. La adopción podría expandirse sustancialmente mientras cae el mínimo de $SOL necesario para este canal de reservas.

El rastreador de la Fundación Solana confirma que solo la primera reducción, de aproximadamente 9%, está activa actualmente en mainnet. La comparación de diez veces se aplica al objetivo final condicional, mientras que el recorte inicial ya redujo los requisitos de reserva.

La reducción de renta de Solana y la barrera de 10×

La "renta" de Solana es un saldo retenido como respaldo del almacenamiento de la cuenta. Generalmente es recuperable cuando la cuenta se cierra, en lugar de ser un pago continuo a los validadores. Reducir el saldo requerido permite que las cuentas nuevas se abran con menos $SOL y puede dejar a las cuentas existentes con saldos superiores a su mínimo.

En la época 1028, el 3 de septiembre, Solana redujo el parámetro de reserva de 6.960 a 6.333 lamports por byte. El objetivo final del plan de cinco etapas es 696.

Según SIMD-0437, la especificación de la reducción de renta, el mínimo equivale al tamaño de datos de la cuenta más 128 bytes de sobrecarga, multiplicado por el parámetro actual de lamports por byte. Una cuenta de tokens estándar contiene 165 bytes de datos, lo que le da un tamaño efectivo de 293 bytes. SIMD significa propuesta de mejora y diseño de Solana, el mecanismo mediante el cual se especifican los cambios de protocolo y, cuando corresponde, se activan por voto de los validadores.

Aplicar esa fórmula a un millón de cuentas de tokens estándar idénticas produce la siguiente ilustración:

Estas cifras son requisitos mínimos calculados para una población fija de cuentas, no retiros medidos. La última fila asume que las cinco reducciones se activan. Tamaños de cuenta distintos producirían totales diferentes.

El ejemplo del millón de cuentas ilustra capital operativo, pero no puede establecer un efecto de oferta a nivel de red. Su reducción final condicional de 1.835,352 $SOL representa alrededor del 0,000314% de los aproximadamente 585,36 millones de $SOL en circulación según los datos de mercado del 5 de septiembre de CryptoSlate. El canal de reservas agregado real requeriría un inventario más amplio de cuentas, considerando tamaños, saldos y la posibilidad de reclamo.

El umbral de diez veces se deriva de la misma relación. Con una décima parte de la tasa de reserva original, se necesitarían diez veces más bytes sujetos a renta para mantener el mínimo agregado sin cambios. Esa medida cubre el stock total de estado persistente, incluida la sobrecarga por cuenta. Los recuentos de usuarios, de transacciones y los precios de $SOL son medidas separadas; la comparación de diez veces describe solo los requisitos de almacenamiento.

El primer paso activo establece una barrera menor: aproximadamente un 9,9% más de estado sujeto a renta preservaría el requisito mínimo original a 6.333 lamports por byte. Ambas comparaciones se refieren a reservas requeridas —los saldos reales de las cuentas pueden permanecer por encima de esos pisos.

Para pagos, la demanda de reservas surge principalmente cuando se abren cuentas. El estudio de julio de la Fundación sobre el estado de cuentas explica que una cuenta de tokens asociada normalmente sirve a un monedero y un mint de token en particular. Una vez que existe, pagos posteriores con el mismo token no requieren otro depósito de creación de cuenta. Por lo tanto, más pagos a través de cuentas existentes no necesitan producir un aumento proporcional en las reservas de almacenamiento.

La autoridad de retiro decide quién obtiene el capital

El beneficio inmediato es el acceso a capital ya en la cadena. La guía de reclamo del 3 de septiembre de la Fundación describe una instrucción llamada WithdrawExcessLamports, que mueve el $SOL por encima del mínimo actual sin cerrar una cuenta de tokens ni cambiar su saldo de tokens. El programa Token-2022 ofrece la misma instrucción.

Para una cuenta de tokens, el propietario debe autorizar el retiro. Para un mint, la autorización proviene de la autoridad del mint, o de la propia cuenta del mint firmando si esa autoridad fue revocada. Las cuentas propiedad de programas personalizados requieren que el programa propietario provea la lógica de retiro y verifique la autoridad correspondiente.

Esto hace que el control de la cuenta sea económicamente significativo. Un proveedor de pagos que financió la cuenta de tokens de un cliente no puede asumir que pagar el depósito original le otorga derecho a reclamar el exceso. La parte facultada para autorizar el retiro puede ser distinta de la que aportó el $SOL.

Mover un saldo excedente requiere una transacción autorizada que deje intacto el mínimo. Transfiere $SOL existente entre cuentas conservando el total; no emite tokens nuevos. La guía no ofrece una medida agregada de retiros completados ni de ventas posteriores.

Para la incorporación de usuarios futura, el beneficio es más directo: quien financie una cuenta necesita menos $SOL por adelantado. Los proveedores podrían atender más cuentas de clientes con el mismo capital, incluso cuando los propios clientes no compren $SOL. Si el excedente existente puede redistribuirse depende de los acuerdos de autoridad y de programa descritos anteriormente.

Cuánto sobrevivan esas cuentas determinará el requisito de reserva continuo. La creación bruta de cuentas puede dar una impresión muy distinta del estado que realmente permanece en la cadena.

En su análisis del 20 de julio, el investigador de la Fundación Solana Umberto Natale halló que el 75,5% de los eventos de creación de cuentas en la cohorte analizada se cerraron dentro de la misma transacción. Las observaciones no se deduplicaron por dirección, por lo que creaciones y cierres repetidos podían contar como eventos separados.

Esos flujos de trabajo pueden generar actividad dejando poco almacenamiento persistente de cuentas. El hallazgo no predice cómo responderán los usuarios a la reducción de septiembre. El estudio también advierte que sus correlaciones débiles e inestables entre los precios de $SOL y la actividad de cuentas son descriptivas, no una estimación causal de cómo la renta más barata cambia la demanda.

Una prueba útil de la política seguirá por tanto los bytes persistentes de cuentas y sus reservas mínimas asociadas junto con la actividad. Contar solo cuentas nuevas no puede establecer si la red absorbió la tasa de reserva más baja.

La demanda de $SOL va más allá de las reservas de cuentas

Otros usos de $SOL también continúan. Según las reglas de tarifas de Solana, las transacciones requieren $SOL: la mitad de la tarifa base se quema y la mitad va al validador, mientras que la tarifa de prioridad completa va al validador. Los pagos de tarifas son un canal de demanda separado de las reservas reembolsables de cuentas. Más actividad podría aumentar el uso de tarifas, pero el rendimiento por sí solo no establece cuánto pagan los usuarios ni los saldos que conservan.

Los tenedores de $SOL también pueden delegar participación a validadores para ayudar a asegurar la red y ser elegibles para recompensas. El capital reclamado podría apostarse o usarse para financiar más cuentas. El material citado no establece ninguno de esos resultados como consecuencia del recorte, por lo que estas posibilidades no ofrecen un contrapeso cuantificado a los menores requisitos de reserva.

El análisis reciente de CryptoSlate sobre actividad y economía de tarifas examinó una distinción relacionada: el uso de la red y la economía del token pueden moverse de forma distinta. La reducción de renta añade una razón específica por la cual el crecimiento puede requerir menos $SOL por unidad de estado persistente.

Al 5 de septiembre, la segunda reducción, a 5.080 lamports por byte, está en testnet, con mainnet prevista para mediados de septiembre. Los últimos tres pasos se esperan con Agave 4.4 en noviembre. Cada activación sigue sujeta a revisión del crecimiento del estado, y un mecanismo de reversión puede restaurar el parámetro original. El diseño escalonado y condicional refleja una disyuntiva que los operadores de Solana han sopesado desde hace tiempo: menores requisitos de reserva abaratan las cuentas, pero un crecimiento más rápido del estado aumenta la carga de almacenamiento que validadores y proveedores RPC deben soportar.

Los próximos umbrales determinarán hasta dónde llega el ahorro de capital. El crecimiento del estado persistente y el reclamo real mostrarán entonces cuánto de ese ahorro se convierte en capacidad de nuevas cuentas, capital de trabajo reutilizable o menor $SOL retenido como respaldo del almacenamiento.