Solana impulsa una desinflación más rápida mientras la disputa de gobernanza revela una división de validadores

SGP-0002 aceleraría el camino de Solana hacia la inflación terminal

SGP-0002, conocido como Double Disinflation, duplicaría la tasa de desinflación de Solana del 15% al 30%. Solana seguiría emitiendo nuevos SOL para recompensar a los participantes que aseguran la red, pero las recompensas basadas en la emisión disminuirían más rápidamente hasta que la inflación anual alcance el piso existente del 1.5% de la red.

La propuesta estima que el calendario más rápido podría resultar en 18.9 millones menos de SOL emitidos durante seis años. Una estimación valoró esa reducción en $1.5 billion. Solana alcanzaría su tasa de inflación terminal en aproximadamente 2.8 años en lugar de 5.7 años, mientras que otra descripción dijo que la red podría alcanzar ese nivel tan pronto como en 2029.

El cambio reduciría la dilución por SOL recién emitido para los tenedores existentes, pero la información proporcionada no presenta una emisión más lenta como garantía de precios más altos del activo. Las recompensas de staking financiadas mediante emisión podrían disminuir más rápido con el tiempo, mientras que las comisiones de los validadores, las comisiones de transacción y otras fuentes de ingresos de la red permanecerían sin cambios por el propio SGP-0002.

Una instantánea de votación posterior del 28 de agosto mostró una participación de 60.17%, por encima del cuórum requerido de un tercio. El apoyo se situó en 65.15%, representando 169.91 millones de SOL, dejando la propuesta 1.52 puntos porcentuales por debajo de su umbral de aprobación requerido de 66.67%.

Kraken se volvió central en la disputa porque su pool de votación tenía 8.92 millones de SOL. Kraken inicialmente se unió a Figment, Everstake y P2P.org para oponerse a SGP-0002, una postura caracterizada como preservación de los rendimientos de staking. El CEO de Helius, Mert Mumtaz, cuestionó públicamente la oposición y acusó a los exchanges de irracionalidad matemática.

Kraken posteriormente revirtió su voto de “NO” a “YES” tras las críticas de la comunidad. El cambio fue descrito como una reconfiguración del “tira y afloja entre whales y la comunidad.” A medida que la votación se acercaba a su umbral, Mumtaz también pidió al fundador de Solana, Anatoly Yakovenko, que ayudara a movilizar a los validadores restantes.

La aprobación por sí sola no cambiaría de inmediato el calendario de emisión de Solana. SGP-0002 proporcionaría un mandato de gobernanza, mientras que la implementación requeriría la actualización técnica separada SIMD-0550. Se esperaba que la coordinación y el despliegue entre validadores tomaran al menos 4.5 meses.

La propuesta de comisiones divide a los principales validadores

SGP-0003 propuso una reestructuración separada de las comisiones de transacción de Solana. Actualmente los usuarios pagan una comisión estándar basada en la cantidad de firmas adjuntas a una transacción. La propuesta añadiría en su lugar un pequeño cargo fijo y otro cargo ligado a la cantidad de capacidad de red solicitada.

Las transacciones simples podrían volverse más baratas bajo el sistema propuesto, mientras que las transacciones más exigentes y las aplicaciones que reserven más capacidad de la necesaria podrían pagar más. La comisión adicional sería destruida en lugar de pagarse a los validadores.

Dependiendo de los parámetros finales, SGP-0003 podría retirar entre 1,500 y 9,000 SOL de circulación cada día. La propuesta también requería decisiones sobre el cargo fijo, la tasa a la que subirían las comisiones relacionadas con la capacidad y si los ingresos deberían quemarse.

Los principales validadores adoptaron posiciones marcadamente diferentes. Figment y Staking Facilities apoyaron SGP-0003, mientras que Jupiter, Bitwise Onchain Solutions y Forward Industries se opusieron. Helius, Kraken, Everstake y Kiln colocaron la mayor parte o la totalidad de su stake de votación en la categoría de abstención.

Una tercera propuesta, SGP-0001, establecería reglas formales para futuras decisiones de la red Solana y permitiría a stakers individuales anular la posición de gobernanza adoptada por su validador. Tuvo un apoyo sustancialmente mayor, con el 89.17% del stake participante votando a favor.

Anza inicia una reducción de cinco etapas en los costos de cuentas de Solana

Separado de las votaciones de gobernanza, el equipo central de desarrollo de Solana, Anza, comenzó a implementar una reducción por fases en la cantidad de capital requerida para el almacenamiento de cuentas on-chain. Anza anunció que la primera de cinco compuertas de funciones ya estaba activa como parte de un programa que apunta a una reducción eventual del 90%.

En esa etapa, solo la primera reducción se había activado en testnet en lugar de que la reducción completa estuviera activa en mainnet.

La reforma está definida por SIMD-0437, escrita por Igor Durovic de Anza. Cambia la constante lamports_per_byte usada para determinar el saldo mínimo de cuenta requerido para almacenamiento, reduciendo finalmente ese valor de 6,960 a 696.

La primera compuerta recorta la constante en aproximadamente 9%. Cada etapa posterior requiere una activación separada basada en información de crecimiento de estado revisada por los desarrolladores centrales de Solana, lo que hace que la reducción total esté condicionada a que la red avance por todas las compuertas restantes.

La Solana Foundation dijo que la constante de almacenamiento se había establecido muchos años antes y se había mantenido sin cambios. Dado que el requisito estaba vinculado a SOL, el costo del almacenamiento subió junto con el valor de SOL en lugar de seguir los costos reales de almacenamiento de los validadores.

El alquiler (rent) de Solana no es una comisión recurrente bajo el sistema descrito por la Solana Foundation. Es una fianza totalmente reembolsable que se devuelve cuando se cierra una cuenta. SIMD-0437 reduce la cantidad de capital que debe depositarse por adelantado.

Para una cuenta estándar de token SPL, el depósito exento de rent disminuiría de aproximadamente $0.159 a $0.0159 una vez que se implemente todo el programa. Para una empresa de pagos que crea 1 millón de cuentas, el capital requerido caería de $159,000 a $15,900, una diferencia de $143,100.

Los depósitos más bajos están orientados en particular a emisores de stablecoin, empresas de pagos, firmas fintech y wallets que pueden crear grandes cantidades de cuentas de tokens para los usuarios. Se informó que el volumen de pagos en Solana aumentó 755.3% en 2025 a medida que la red se utilizó como capa de liquidación para stablecoins asociadas con Western Union, PayPal y Fiserv.

Los desarrolladores están usando el despliegue por fases para limitar el riesgo de inflación del estado (state bloat), porque cada validador debe almacenar e indexar el estado on-chain. Una sexta compuerta de funciones puede restaurar la constante de almacenamiento a su nivel original si surgen problemas, mientras que la propuesta complementaria SIMD-0392 permitiría aumentar más adelante los requisitos de rent sin interrumpir las cuentas existentes.

El investigador de datos de la Solana Foundation, Umberto Natale, modeló la economía de un ataque de inflación del estado después de la reducción total. Su análisis estimó que agotar el margen de almacenamiento existente de la red aún requeriría alrededor de $17.2 million en capital bloqueado, y concluyó que la reducción total no crearía un riesgo sistémico para el clúster.

Los cambios de rent se entregan con Agave 4.2, la versión de validador de Anza recomendada para mainnet en agosto de 2026. Agave 4.2 también admite transacciones de 4,096 bytes y reduce a la mitad los tiempos de slot a 200 milisegundos.

La Solana Foundation dijo que las activaciones de funciones en mainnet para la versión comenzaron durante la semana del 17 de agosto. Las cuentas existentes continúan operando sin ser recreadas y pueden reducir sus saldos al nuevo mínimo aplicable a medida que se activan requisitos más bajos.

Four compuertas de reducción permanecen después de la primera etapa, y cada una debe superar una revisión de riesgo separada antes de su activación. Por lo tanto, la cifra indicada de “90% lower storage costs” se refiere al despliegue completado y no a la reducción ya activa en la primera etapa de testnet.