Solana tiene en producción la actualización que ordena el terreno para su nuevo consenso. Agave 4.4, el cliente validador que ejecuta la práctica totalidad de la red, cierra la rebaja del alquiler de cuentas, hace que los programas devuelvan SOL al encogerse y elimina una regla que invalidaba bloques enteros por una sola transacción mal financiada. El telón de fondo: con slots objetivo de 200 milisegundos, cada época dura cerca de un día.
Conviene aterrizar los términos. Solana produce bloques en slots —turnos de producción asignados a un validador líder— y agrupa esos turnos en épocas: la unidad donde se liquidan las recompensas del staking, el SOL delegado a un validador a cambio de rendimiento, y donde se encienden los cambios de protocolo. Una época son 432.000 slots. A 400 ms por slot, dos días; a 200 ms, uno.
La rebaja del alquiler de cuentas llega a su último tramo
Cada cuenta de Solana, programas incluidos, debe mantener un saldo mínimo en SOL proporcional a los bytes que ocupa. Es el depósito rent-exempt, una fianza inmovilizada mientras el dato exista. Se partía de 6.960 lamports por byte; el plan de la SIMD-0437 lo lleva a 696, un recorte del 90% repartido en cinco pasos.
Agave 4.4 activa los tres últimos: 2.575 lamports por byte (63% de reducción), 1.322 (81%) y los 696 finales. Cada tramo tiene su propia feature gate, el interruptor que el protocolo enciende cuando la red ya digiere el anterior, de modo que el efecto sobre la creación de cuentas se mide antes de seguir bajando.
Las estimaciones de Ghost recogidas en el análisis técnico de referencia sitúan en más de 3 millones de SOL, unos 300 millones de dólares, el capital recuperable de depósitos sobredimensionados, y ya existen herramientas para reclamarlo. Para un servicio de pagos que abre cuentas en nombre de sus usuarios, la diferencia entre 6.960 y 696 lamports por byte es la diferencia entre subsidiar cada alta o no hacerlo.
El ahorro no está en procesar más rápido, sino en dejar de inmovilizar capital en bytes que nadie llega a usar.
Programas que se encogen y devuelven lamports
El segundo bloque es la SIMD-0433. El loader v3, hoy el mecanismo por defecto para desplegar y actualizar programas, guarda el binario compilado en una cuenta ProgramData junto a los metadatos. Hasta ahora esa cuenta solo podía crecer: quien actualizaba a un binario más pequeño se quedaba con el hueco vacío y con el SOL que lo mantenía exento de alquiler, bloqueado dentro.
Con el cambio, la instrucción de upgrade redimensiona la cuenta al tamaño del nuevo binario y devuelve el excedente a la cuenta de destino designada. Si el binario crece, la cuenta se expande sola. Eso sí: los saldos deben cubrir el nuevo requisito o la actualización falla, y en las actualizaciones lanzadas por CPI sigue aplicando el límite de 10 KiB de crecimiento por llamada.
El incentivo de fondo es que los equipos migren a frameworks más ligeros, tipo Pinocchio, en lugar de arrastrar binarios heredados. Menos bytes y menos SOL dormido.
SIMD-0290: una comisión impagada deja de tumbar el bloque
Antes, si un bloque incluía una transacción cuyo pagador de comisiones no pasaba la validación —por ejemplo, por saldo insuficiente—, el bloque entero quedaba invalidado. La SIMD-0290 rompe esa dependencia: la transacción permanece, los validadores omiten su ejecución y el estado de las cuentas no se toca. Se convierte en un no-op que no ejecuta instrucciones ni cobra comisiones, pero sí consume capacidad de bloque.
La razón técnica importa. El saldo de un pagador puede cambiar según se ejecuten las transacciones anteriores, así que exigir pagadores válidos obligaba a ejecutar parte del bloque antes de saber si el bloque era válido. Tratar el fallo como transacción omitida elimina esa atadura y abre la puerta a la ejecución asíncrona: primero se acuerda el orden, después se aplica al estado. Los durable nonce quedan para la SIMD-0297.
Shreds de 32 y 32: menos flexibilidad, más claridad
Solana reparte los bloques con Turbine, que los trocea en shreds y los retransmite en capas de validadores. Los fragmentos se agrupan en conjuntos de 32 de datos y 32 de codificación: con cualquier combinación de 32 entre los 64 se reconstruye el bloque, lo que tolera pérdida de paquetes. Cada shred lleva una prueba de Merkle de seis niveles atada a la firma del líder.
La SIMD-0317 convierte esa estructura en obligatoria. Los clientes ya la producían, pero los receptores aceptaban configuraciones más laxas. Fijarla simplifica la validación y facilita detectar la equivocación, el escenario en el que un líder reparte dos versiones contradictorias del mismo bloque.
Lo que Agave 4.4 revela de la Solana de 2026
Leído en conjunto, el release es plomería para Alpenglow, la reforma del consenso que Anza puso sobre la mesa en 2025 para recortar los tiempos de finalización. También recuerda dónde está el riesgo. Agave ejecuta la enorme mayoría del stake de la red; Firedancer, el segundo cliente independiente que Jump Crypto construye en C++, avanza pero todavía no iguala esa cuota. Mientras siga así, un fallo en Agave es un fallo de red, no de un operador.
Hay una segunda tensión, menos comentada. Bajar el slot a 200 ms y comprimir la época a un día acelera la iteración, pero también sube el listón de hardware y ancho de banda. Quien no pueda seguir el ritmo pierde competitividad, y el stake tiende a concentrarse en quienes sí pueden.
¿Y para el inversor? Agave 4.4 no mueve el precio por sí solo. Mejora la economía de construir sobre Solana justo cuando la red compite por volumen institucional y por aplicaciones de pago reales. Son argumentos de venta para equipos, no titulares de portada.
El siguiente hito ya está marcado: Anza encadena Agave 4.5 tras la cita de la comunidad en Londres. Habrá que ver si las tres feature gates del alquiler se encienden al ritmo previsto y si la ejecución asíncrona aparece en el calendario con fecha. Hasta entonces, esto es infraestructura haciendo su trabajo. Silenciosa, aburrida y decisiva.
