Anza habilitó la Transacción V1 en la testnet de Solana el 1 de septiembre, dando a la red un último ensayo de la actualización antes de su lanzamiento programado en la mainnet el 9 de septiembre. Según Solana Compass, el cambio permite que las cargas de trabajo criptográficas y de DeFi que antes debían fragmentarse en múltiples transacciones se procesen en una sola transacción atómica.

Los trabajos divididos ahora caben en una sola llamada

El cambio más notable es el aumento de espacio. El tamaño máximo de una transacción serializada de Solana pasó de 1.232 bytes a 4.096 bytes —un aumento de 3,3 veces—, con efecto en la época 1025 de la testnet. El límite de 1.232 bytes se remontaba al diseño protocolar más temprano de Solana, y V1 marca la primera vez que se eleva ese límite a nivel del formato de mensaje desde que V0 introdujo las Address Lookup Tables como solución parcial a la presión de tamaño.

Según la página de actualización de transacciones grandes de la Solana Foundation, el mayor tamaño hace posible implementar pruebas de conocimiento cero, transacciones multisig grandes y diversos esquemas de firma que antes no cabían en una sola transacción. El resultado son menos transacciones por procesar, menores costos de firmas y la eliminación de la espera por una cadena de confirmaciones. Se espera que los esquemas de firma BLS, las transacciones confidenciales y las configuraciones multisig se beneficien de esta actualización.

Dos propuestas son centrales para esta mejora: SIMD-0296 eleva el límite de tamaño de transacción de 1.232 a 4.096 bytes, mientras que SIMD-0385 define el formato de mensaje V1 y traslada la configuración de la transacción al propio mensaje.

Menos de un día después de la activación, el CEO de Anza, Brennan Watt, publicó en X señalando una transacción grande en el explorador de la testnet con el mensaje: "ATTENTION: large transactions have hit the testnet."

Por qué una transacción supera a un bundle

La atomicidad importa porque los desarrolladores a veces sorteaban el antiguo límite de tamaño de Solana mediante bundles de Jito. SIMD-0296 documenta explícitamente esa solución alternativa y señala que los bundles carecen de atomicidad a nivel de protocolo, a diferencia de una única transacción nativa.

Según la documentación de Jito, los bundles pueden contener hasta cinco transacciones procesadas secuencialmente bajo un esquema de todo o nada. Sin embargo, los bundles operan dentro del motor de bloques de Jito y compiten entre propinas a los validadores. Una transacción V1, en cambio, es una única transacción nativa de Solana que lleva la garantía de atomicidad a nivel de transacción del propio Solana.

Para los desarrolladores de DeFi, esto simplifica la construcción de rutas de intercambio, pruebas y otras operaciones de varios pasos: si toda la operación cabe en una transacción V1, se ejecuta con éxito o se revierte como una sola transacción nativa, en lugar de depender de un bundle.

Lo que DeFi gana más allá de los bytes adicionales

V1 también cambia la estructura de la transacción. Mientras que las transacciones Legacy y V0 gestionan las tarifas de prioridad y las solicitudes de recursos mediante instrucciones ComputeBudget, SIMD-0385 traslada estos ajustes a la configuración de la transacción V1, facilitando que los validadores identifiquen las necesidades de recursos sin recorrer la lista de instrucciones.

V1 también elimina las Address Lookup Tables (ALT), que V0 usaba para abreviar las direcciones de cuenta. Según el análisis de la Fundación sobre la contrapartida de las ALT en V1, V1 en cambio ubica las direcciones de forma inline, lo que simplifica la entrada de los validadores frente al enfoque de V0, que consumía más bytes al convertir direcciones en aplicaciones con muchas cuentas.

El beneficio práctico para los routers y agregadores de DEX es más espacio para rutas atómicas complejas. Sin embargo, la mejora no está exenta de límites: el tope de Solana de 64 cuentas distintas por transacción se mantiene sin cambios, por lo que las aplicaciones intensivas en cuentas aún pueden toparse con ese techo aunque la capacidad en bytes ya no sea la restricción.

La actualización llega mientras Solana avanza hacia las finanzas on-chain. El informe de Solana del segundo trimestre de 2026 de Galaxy muestra una actividad creciente en stablecoins, acciones tokenizadas y activos del mundo real. Según Galaxy, el potencial futuro de Solana dependerá en gran medida de la capacidad de usar estos activos en préstamos, colateralización, margen y rendimiento, no solo en emisión o negociación. Los datos de DeFiLlama sobre Solana indican una fuerte presencia de DeFi en la plataforma.

El momento también coincide con la fase de actualización de Agave 4.2. Como informó previamente Cryptopolitan, se esperaba que el plan escalonado de reducción de costos generara ahorros de aproximadamente el 90% y redujera el tiempo de procesamiento de 500 a 200 milisegundos, en beneficio de los emisores de stablecoins, proveedores de wallets y sistemas de pago.

Los operadores de RPC tienen una semana para actualizarse

V1 es opcional, por lo que las transacciones Legacy y V0 siguen funcionando. La pregunta abierta es si la infraestructura que lee el tráfico V1 está lista.

Anza ha exigido a los proveedores de RPC actualizar a Agave v4.2.2 o v4.3.0-beta.3. La lista de verificación de migración a Agave 4.2 de Helius advierte que los consumidores de RPC que no declaren compatibilidad con V1 pueden experimentar fallas en llamadas, como getBlock, cuando intervenga una transacción V1.

El despliegue comenzó con pruebas locales de V1 el 24 de agosto, seguido de la confirmación de la fecha de mainnet del 9 de septiembre el 29 de agosto. V1 se habilitó en la testnet el 1 de septiembre en la época 1025, con la activación en la mainnet programada para el 9 de septiembre.

Esta última prueba en la testnet sirve como paso preparatorio final para los proveedores de RPC, indexadores, wallets, SDKs y plataformas de análisis antes del lanzamiento en la mainnet.