El código de la próxima versión de Aztec está terminado y ya espera el voto de los tenedores de su token. La propuesta AZUP-3, que sustituye el rollup actual por uno nuevo, llegó al foro de gobernanza el 9 de octubre de 2026 y un día después quedaron publicadas las direcciones del paquete de contratos. El cambio estrella es medible: los mensajes que viajan de Ethereum a Aztec tardan hoy entre 24 y 108 segundos y pasarán a resolverse en 12 o 30 segundos, según la propia Aztec.
Aztec es una red de capa 2 sobre Ethereum centrada en la privacidad. Sus contratos ejecutan la lógica privada en el dispositivo del usuario y envían una prueba criptográfica a los secuenciadores, que validan el resultado sin llegar a ver los datos. La red abrió su fase Alpha el 31 de marzo de 2026 y activó la versión 5 el 21 de julio del mismo año, cuando redujo el tiempo de prueba de una transacción privada a más de la mitad. Ahora prepara un salto de otra clase: v6 no es una revisión del rollup, sino un rollup nuevo.
La votación para activarlo empieza este sábado 17 de octubre de 2026 y dura una semana, con cierre el día 24. Pero este no es un simple cambio. El nuevo paquete mueve el reparto de recompensas entre secuenciadores y probadores, abre un margen de comisión que la gobernanza podrá subir más adelante y reserva 1,8 millones de tokens AZTEC para que la versión anterior siga operando durante un mes. Cada una de esas piezas viaja dentro de las doce propuestas de mejora que componen AZUP-3.
Un rollup nuevo para acortar el trayecto desde Ethereum
Hoy, un mensaje que sale de Ethereum con destino a Aztec espera a que se cierre el árbol del Inbox, el contrato de la capa uno que acumula los envíos pendientes. Ese recorrido tarda entre 24 y 108 segundos.
La propuesta AZIP-22, bautizada como Fast Inbox, hace que los nodos incorporen cada mensaje al bloque en cuanto lo ven en Ethereum, sin esperar al cierre del árbol ni al retraso de dos checkpoints.
El resultado baja a un rango de 12 a 30 segundos, siempre según la propuesta. El beneficio alcanza a todo lo que cruza la frontera entre las dos redes: depósitos, puentes y flujos de portal.
Para una red que presume de privacidad en el ecosistema Ethereum, acortar esa espera también reduce la ventana en la que el usuario ya ha enviado su dinero y todavía no puede operar con él en la capa dos.
La mejora es real, aunque conviene medirla con precisión. Pasar de 24-108 segundos a 12-30 segundos no convierte el puente en instantáneo, porque elimina la espera larga y deja el retraso en el orden de un bloque. En una red que liquida sus pruebas en Ethereum, eso sigue siendo una ganancia concreta y comprobable, no un eslogan.
Los números que cambian con el v6
El paquete no toca solo el mensajero. La red reparte 500 AZTEC por checkpoint, la unidad con la que agrupa bloques y paga recompensas, y v6 mueve la porción que se queda cada actor. Estas son las cifras que publica la propuesta y que cualquier operador debería comprobar antes de votar.
| Cambio |
Antes |
Después |
Propuesta |
| Mensajes de Ethereum a Aztec |
24 a 108 segundos |
12 a 30 segundos |
AZIP-22 |
| Reparto al secuenciador |
350 AZTEC (70%) |
450 AZTEC (90%) |
AZIP-30 |
| Bote del probador por checkpoint |
150 AZTEC |
50 AZTEC |
AZIP-30 |
| Recompensa de v5 tras el cambio |
500 AZTEC |
50 AZTEC durante 30 días |
AZIP-34 |
| Tope de gas del registro de claves |
250.000 |
300.000 |
AZIP-33 |
| Gas de capa 1 por checkpoint |
300.000 |
500.000 |
AZIP-35 |
| Gas de capa 1 por prueba de época |
3.600.000 |
4.000.000 |
AZIP-35 |
| Margen de comisión del protocolo |
no existía |
arranca en cero |
AZIP-23 |
Las emisiones totales no cambian: siguen siendo 500 AZTEC por checkpoint. Lo que se mueve es el reparto. La cuota del secuenciador sube del 70% al 90%, mientras el bote que remunera al probador por bloque cae de 150 a 50 AZTEC por checkpoint.
¿Qué gana y qué cede cada actor de la red?
Para un secuenciador, la subida es directa. Pasa de 350 a 450 AZTEC por checkpoint si sigue al rollup más reciente, y su participación se traslada a v6 en el momento de la ejecución.
Quien prefiera quedarse en v5 cobra 35 AZTEC por checkpoint hasta que se agote la reserva de la versión anterior. Sus primeros deberes en la red nueva llegan dos o tres épocas después del cambio.
Para un probador el ajuste va en sentido contrario. El bote de recompensa por bloque baja de 150 a 50 AZTEC, aunque los ingresos que llegan por comisiones no se tocan. Las puntuaciones de actividad solo suben con pruebas de época completa, un cambio que ordena el trabajo de quien compite por probar el estado de la red.
Los tenedores de AZTEC no ven emisiones nuevas, porque el total se mantiene intacto. Lo que ganan es control. La gobernanza recibe un margen sobre la comisión y una calculadora de recompensas que se puede cambiar sin desplegar un rollup, dos palancas que hoy no existen y que se activarán en propuestas posteriores.
Para los desarrolladores, el aviso importante es que v6 es un rollup distinto. Los contratos hay que recompilarlos, los identificadores de clase y las direcciones cambian, y las comisiones de capa dos suben ligeramente por los nuevos constantes de gas. Nada de eso se resuelve con una actualización silenciosa.
El margen de comisión y la calculadora de recompensas
Hasta ahora las comisiones se calculaban al coste exacto de operar la red, sin colchón. La propuesta AZIP-23 añade un margen que la gobernanza fija por encima de ese coste, con un destinatario elegido también por votación.
El margen arranca en cero y solo puede subir en pasos limitados que apruebe una propuesta posterior de gobernanza. Con ese diseño, no cambia la factura de nadie el primer día del despliegue.
La calculadora de recompensas de AZIP-31 resuelve otro problema estructural. Antes, cambiar la fórmula que decide lo que cobra un secuenciador obligaba a desplegar un rollup nuevo entero, con todo lo que eso arrastra.
Ahora la gobernanza puede apuntar el rollup a un contrato aparte. Si esa calculadora falla o se comporta mal, el sistema vuelve a la recompensa por defecto y una prueba nunca se queda bloqueada.
Las dos piezas son infraestructura para gobernar mejor, no mejoras visibles para el usuario final. Su valor aparecerá cuando la gobernanza las use, y ese uso todavía no está escrito en AZUP-3. Quedan como herramientas cargadas para el futuro, que es exactamente lo que dicen ser.
Los doce cambios que viajan dentro de AZUP-3
El paquete agrupa doce propuestas de mejora, conocidas por sus siglas AZIP. Algunas son grandes y otras son ajustes técnicos de perfil bajo. Esta es la lista completa que publicó el foro de Aztec:
- AZIP-22, Fast Inbox
- AZIP-23, margen de comisión de protocolo
- AZIP-24, atribución del primer probador por checkpoint
- AZIP-25, puntuación de actividad solo para pruebas de época completa
- AZIP-26, árbol de efectos de transacción en las cabeceras de bloque
- AZIP-27, salidas limitadas por tasa para proveedores de staking
- AZIP-29, refinamiento del nullifier de protocolo
- AZIP-30, despliegue de v6 con reparto del 90% al secuenciador
- AZIP-31, calculadora de recompensas enchufable
- AZIP-33, subida del tope de gas del GSE a 300.000
- AZIP-34, sostenimiento del rollup v5 tras el cambio
- AZIP-35, constantes de gas de Glamsterdam
Dos de ellas merecen atención aparte. AZIP-26 hace que cada cabecera de bloque comprometa un árbol con los efectos de sus transacciones, de modo que un contrato pueda probar contra esa cabecera.
AZIP-27 permite que un proveedor de staking inicie la salida de las posiciones que opera, algo que antes solo podía hacer el delegador que le había confiado sus tokens en primer lugar.
Esa salida lleva un límite compartido del 5% del conjunto de validadores cada siete días. El tope existe para que nadie use las retiradas como herramienta con la que inclinar una votación de gobernanza, un riesgo que ya había aparecido en otros diseños de staking delegado.
El verdadero juego está en la migración
El titular fácil es la velocidad. La realidad es más matizada: los mensajes ya llegaban en segundos y pasarán a llegar en menos segundos, sin dejar de depender de la cadencia de Ethereum. La ganancia se nota sobre todo en los puentes y en los depósitos, donde cada segundo de espera es dinero en tránsito.
Lo que de verdad decidirá el éxito de v6 es la migración. Un rollup nuevo obliga a moverse a la vez a todos los que operan la red, desde quien secuencia hasta quien prueba.
Aztec ha diseñado su fase Alpha como una sucesión de despliegues que no arrastran estado. Como ya ocurrió con los experimentos de privacidad probados sobre esta red, la parte visible es la función y lo que cuesta de verdad es la infraestructura que la sostiene.
Si la votación sale adelante, la ejecución llegará en los días siguientes y con ella el primer mes de convivencia entre las dos versiones. Si no sale, el código seguirá listo y el payload seguirá desplegado, así que el calendario de la gobernanza volverá a empezar por la señalización.
