# Agave v4.5 pone fecha a la tecnología de Solana en diciembre > Anza publica el calendario de Agave v4.5: activación en mainnet el 14 de diciembre, renta más baja, acceso directo a cuentas y adopción en dos pasos. > Por José Maldonado · Blockchain · 2026-11-12 El 14 de diciembre de 2026 es la fecha que Anza ha puesto para empezar a activar en mainnet las funciones de Agave v4.5, el cliente de validador con el que opera la mayoría de la red Solana. El documento vive en [la página de Agave v4.5 de la wiki de Anza](https://github.com/anza-xyz/agave/wiki/v4.5-Release-Schedule), actualizada el 10 de noviembre, y encadena ocho hitos entre el 6 de noviembre y esa segunda semana de diciembre. Ninguna fecha está garantizada: la propia Anza repite que son tentativas y que los operadores esperen los avisos de Discord antes de tocar un nodo. Para quien usa la red, el resumen cabe en dos frases: abrir una cuenta costará menos y los programas dejarán de copiar los datos de la cuenta para leerlos. Para quien opera un nodo, el cambio importante está en el proceso: la adopción en mainnet pasa de tres pasos a dos y eso recorta una semana del ciclo de despliegue. El calendario se detiene entre el 11 y el 18 de noviembre por Breakpoint, la conferencia anual de la Solana Foundation que se celebra en Londres del 15 al 17, y vuelve el 19 con la reactivación de funciones en los tres clústeres. La ventana de pruebas queda partida en dos mitades y el margen hasta diciembre se mide en semanas. ## Un calendario que reduce los pasos El ciclo de v4.4 pedía tres gestos (10%, 20 o 25% del stake y adopción general) y el de v4.5 pide dos. El 30 de noviembre Anza llamará a voluntarios con el 20% del stake y el 7 de diciembre recomendará la versión a todos los validadores. El equipo lo resumió en redes como una semana menos de ciclo. Ese primer escalón no es cosmético. Los [datos de validadores de la red](https://solanacompass.com/news/anzas-agave-v45-schedule-cuts-solana-mainnet-adoption-to-two-steps-and-pauses-feature-activations-for-breakpoint) sitúan el stake activado en 432,4 millones de SOL repartidos entre 658 validadores en el epoch 1083, de modo que el 20% ronda los 86 millones de SOL. Un validador mediano que se lo piense dos veces deja el paso en manos de los grandes operadores, que responden antes a estas llamadas. La rama de v4.5 se creó el 5 de noviembre, el testnet recibió la recomendación el 6 y el devnet se actualizó el 10. El candidato a mainnet se etiqueta el 27 de noviembre y ese mismo 7 de diciembre se abre la rama de v5.0. El precedente inmediato desaconseja dar nada por hecho. El 5 de noviembre Anza pidió un parche no programado, Agave 4.4.1, antes de que llegara el epoch 1079, y lo publicó esa tarde. Un ciclo que ya necesitó una parada de emergencia puede necesitar otra. ## La renta por byte baja en tres tramos La renta de Solana es un depósito reembolsable que cada cuenta mantiene por byte de datos, no un pago que se consuma. La propuesta [SIMD-0437](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0437-incremental-rent-reduction.md) plantea bajarla de 6.960 lamports por byte a 696 en cinco pasos, y Anza incluye los tres últimos en este ciclo. El precio actual, 5.080 lamports por byte, baja a 2.575, después a 1.322 y al final a 696. Una cuenta de token estándar ocupa 165 bytes y el sistema suma 128 de sobrecarga, así que el depósito cae de unos 0,0015 SOL a unos 0,0002 SOL cuando los tres tramos estén activos. Los dos primeros pasos se probaron en testnet desde agosto y el recorte total llega al 90% de la factura original. Las cuentas que ya existen siguen operando con el depósito antiguo y [su titular puede retirar el excedente después de cada tramo](https://solanacompass.com/news/anzas-agave-v45-schedule-cuts-solana-mainnet-adoption-to-two-steps-and-pauses-feature-activations-for-breakpoint). Es la parte menos vistosa del anuncio y la que más se nota en una cartera con cientos de cuentas pequeñas. Un depósito siete veces menor cambia la cuenta de resultados de una aplicación que crea una cuenta por usuario, y también la de los airdrops que reparten saldo a decenas de miles de direcciones nuevas. ## Los programas leen la cuenta donde está El runtime actual copia los datos de la cuenta a la memoria del programa y los devuelve al terminar, y repite esa copia en cada llamada entre programas. [SIMD-0460](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0460-virtual-address-space-adjustments.md) elimina el paso intermedio: el programa lee y escribe sobre los datos donde están, también cuando llama a otro programa. Jonas Hahn, del equipo de desarrolladores de la Solana Foundation, pidió el 10 de noviembre probar los programas con la función virtual\_address\_space\_adjustments activada, en local o contra devnet, porque algunos todavía muestran divergencias con el mapeo nuevo. Ese detalle importa a quien mantiene código en producción: un programa que daba por hecha una copia propia de los datos puede comportarse distinto cuando la copia desaparece. Probar en devnet deja de ser un trámite y pasa a ser la única forma de comprobarlo. ## Las actualizaciones ajustan el tamaño del programa El cargador de programas de Solana permite ampliar los datos con la instrucción ExtendProgram, pero no reducirlos, y por eso un proyecto que adelgaza su binario sigue pagando renta por bytes que ya no usa. [SIMD-0433](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0433-loader-v3-set-program-data-to-elf-length.md) ataca las dos mitades del problema. Con el cambio, la actualización redimensiona la cuenta al tamaño del binario nuevo: un programa más grande ya no necesita el paso previo y uno más pequeño devuelve la renta sobrante a la cuenta que el desarrollador indique. Quien despliega a menudo ahorra en el guion de despliegue y en la renta que deja de pagar por bytes vacíos. ## El calendario, hito por hito Las fechas que resumen el ciclo figuran en la wiki desde el 10 de noviembre. Las dos primeras filas ya ocurrieron; el resto son objetivos que Anza puede mover sin más aviso que una edición de la página. Hito Fecha objetivo Estado Rama v4.5 creada 5 de noviembre cumplido Testnet recomienda v4.5 6 de noviembre cumplido Candidato a mainnet etiquetado 27 de noviembre pendiente Voluntarios con el 20% del stake 30 de noviembre pendiente Adopción general recomendada 7 de diciembre pendiente Activación de funciones en mainnet 14 de diciembre pendiente Fuera de la tabla quedan dos hitos que conviene tener a mano: la reactivación de funciones en testnet, devnet y mainnet el 19 de noviembre, y la actualización del devnet el 10. Los dos sirven de ensayo antes de que el código toque dinero real. ## Breakpoint parte el ciclo en dos La pausa por Breakpoint no es un detalle de agenda. Entre el 11 y el 18 de noviembre Anza congela la actividad de release, y cuando vuelve el 19 tiene que reactivar funciones en los tres clústeres a la vez. Menos de cuatro semanas separan esa reanudación de la activación final del 14 de diciembre. El margen se estrecha porque el cliente acaba de pasar por un cambio de consenso. Alpenglow se activó en mainnet el 21 de octubre con [Votor y una finalidad de 150 milisegundos](https://observatorioblockchain.com/blockchain/solana-alpenglow-consenso-150ms-finalidad/), frente a los 12,8 segundos anteriores, y exigió a los validadores actualizar el cliente. Los tres frentes de v4.5 comparten runtime, así que un fallo de renta puede aparecer como un fallo de mapeo directo y al revés. La pausa de Breakpoint, además, junta las pruebas en la misma ventana de noviembre en lugar de repartirlas. El 20% del stake no se mueve solo: hay que convencer a operadores que responden ante sus usuarios. Cuando un proveedor de staking falla, el efecto llega al depositante antes que a la red, como ocurrió con [la paralización de recompensas de Solflare](https://observatorioblockchain.com/defi/solflare-staking-proveedor-incidente-recompensas/) a finales de octubre. ## Lo que se juega Solana en cinco semanas Anza lleva dos ciclos intentando que la adopción en mainnet sea menos ceremoniosa. El escalón del 10% obligaba a dos rondas de coordinación y a dos esperas, y el resultado era el mismo: todo el mundo actualizaba. Quitarlo reduce el tiempo y las ocasiones de detectar un problema antes de que llegue a todos. El riesgo de ejecución se concentra en el 30 de noviembre. Si los voluntarios no llegan al 20% del stake, el calendario se estira y el 14 de diciembre deja de ser una fecha. Los operadores grandes responden rápido porque tienen equipo; el validador pequeño que alterna entre [Firedancer](https://observatorioblockchain.com/blockchain/solana-y-firedancer-buscan-eficiencia-web2-para-atraer-inversores/) y Agave decide con menos información. Para el desarrollador, la parte útil del anuncio no son las fechas, sino las tres funciones: cuentas más baratas, datos sin copia y actualizaciones que se ajustan solas. Para el validador, la parte útil es el aviso de que hay una ventana en devnet y otra en testnet antes de tocar mainnet. La fecha del 14 de diciembre se moverá si algo se tuerce, como se han movido otras este ciclo. Lo que no se mueve es la dirección: menos depósito por byte, menos copias en memoria y menos pasos manuales en las actualizaciones.