Solana Transaction V1 llega el 9 de septiembre: qué cambia para los comercios que aceptan pagos con stablecoins

Qué se activa el 9 de septiembre — y qué es en realidad

Solana Transaction V1 es un formato de transacción nuevo, no una cadena nueva, ni un estándar de token nuevo, ni un modelo de comisiones distinto. Su cambio principal es de tamaño: la transacción serializada máxima pasa de 1.232 bytes a 4.096 bytes. El tope viejo venía heredado de la MTU mínima de IPv6, 1.280 bytes; la red se movió a QUIC, que no impone un techo fijo sobre un stream, y el número nuevo se eligió para alinearse con la página de memoria estándar de 4 KiB del hardware de los validadores.

Dos documentos de mejora lo sostienen: SIMD-0296 sube el techo de tamaño y SIMD-0385 define el formato de mensaje v1, ambos escritos por los ingenieros de Solana Jacob Creech y Andrew Fitzgerald. El conjunto completo de propuestas aceptadas vive en el repositorio público de Solana Improvement Documents, que es la fuente primaria si querés la especificación y no el resumen.

El despliegue fue inusualmente legible. Las pruebas locales se abrieron el 24 de agosto con la CLI de Solana v4.2 en adelante. La fecha de mainnet se confirmó el 29 de agosto. Transaction V1 se activó en testnet en el epoch 1025 el 1 de septiembre, y la cobertura de fin de agosto fijó mainnet para el 9 de septiembre. Eso les dio a proveedores de RPC, indexadores, wallets, SDKs y plataformas de analítica unos diez días para confirmar soporte. Una ventana corta, a propósito.

Dentro del formato se movieron tres cosas. El discriminador de versión (0x81 para v1) queda en la posición cero. Las firmas se reubicaron al final del mensaje. Y un TransactionConfigMask de 32 bits en un offset fijo ahora codifica comisiones de prioridad, límites de unidades de cómputo, tamaño de datos de cuentas cargadas y tamaño de heap directamente en la cabecera, reemplazando las instrucciones de ComputeBudgetProgram que antes los llevaban.

Y algo se sacó a propósito: las address lookup tables. Con v0, las lookup tables permitían referenciar hasta 64 cuentas con índices de un byte, porque 64 direcciones inline de 32 bytes reventaban un presupuesto de 1.232 bytes. Con 4.096 bytes, esas mismas 64 direcciones ocupan 2.048 bytes y entran cómodas. Así que v1 elimina la indirección y exige que cada dirección de cuenta aparezca completa.

Tres mejoras al mismo riel en seis semanas

Transaction V1 no llega solo, y el racimo es la noticia. Tres cambios al comportamiento de Solana relevantes para pagos caen en unas seis semanas:

• Reducción de rent (SIMD-0437, paso 1) — arrancó la semana del 31 de agosto, el primero de cinco pasos hacia un recorte objetivo del 90% en el costo de almacenamiento de las cuentas de token. Cada saldo de stablecoin en Solana vive en una cuenta de token, y cada cuenta de token carga un depósito de exención de rent. Bajar ese costo un orden de magnitud cambia la economía de crear cuentas a escala: airdrops, payouts, wallets que abren una cuenta por usuario.
• Transaction V1 — 9 de septiembre, lo descrito arriba.
• Alpenglow — apuntado a octubre con Agave 4.3. Reemplaza Proof-of-History y TowerBFT por dos componentes nuevos, Votor y Rotor, colapsa un proceso de confirmación de 32 rondas en una o dos, y lleva la finalidad de 12,8 segundos a unos 150 milisegundos. Los validadores aprobaron la propuesta de base, SIMD-0326, con un 98,27% de apoyo en septiembre de 2025, y Anza corrió una competencia de seguridad con hasta 50.000 SOL en premios antes de la activación.

Leído junto, eso es un riel reconstruyéndose en público, con calendario y con los comprobantes publicados. También conviene ser preciso con lo que cambia Alpenglow, porque el número se sobrevende fácil. Finalidad no es primera confirmación. Un pago en Solana hoy se ve y se confirma bastante por debajo del segundo —el número práctico que maneja Payzum para confirmaciones en Solana es ~0,4 segundos—. Lo que tarda 12,8 segundos es el punto en el que el estado de la cadena queda criptográficamente asentado más allá de una reorganización. Alpenglow encoge el segundo número, no el primero. Para una cafetería, la experiencia en el mostrador casi no se mueve. Para una tesorería que decide cuándo una transferencia es irreversible, se mueve muchísimo.

Ahora preguntate para quién es cada mejora

Acá el análisis se pone incómodo, y es el mismo patrón que escribimos sobre las stablecoins de consorcios bancarios y sobre los estándares de pagos agénticos.

Tomá la lista de lo que desbloquea Transaction V1 y nombrá al beneficiario de cada punto:

• Pruebas de conocimiento cero que ya no hay que partir en varias transacciones → el beneficiario es quien está probando algo en privado. En términos de stablecoins, eso son los saldos confidenciales (más abajo), y hoy quienes construyen sobre eso son instituciones y wallets, no comercios.
• Agregación de firmas BLS para atestaciones de puentes → el beneficiario es el operador del puente.
• Multifirma grande y anidada en una sola transacción atómica → el beneficiario es la tesorería, la DAO, el custodio. La motivación principal declarada para subir el tamaño fue la multifirma anidada.
• Valores de configuración en la cabecera del mensaje en vez de instrucciones separadas → el beneficiario es el desarrollador que arma la transacción.
• Cuentas de token más baratas → el beneficiario es quien crea muchas cuentas: emisores, wallets y operadores de payouts. No un negocio que recibe un pago por vez.

Ninguno es el comercio. Eso no es una crítica al roadmap —los protocolos deben arreglar problemas de protocolo, y estos son reales—. Es una observación sobre dónde aparece siempre el hueco de este mercado. La emisión se financia. La liquidación se financia. El consenso se reconstruye. El negocio parado detrás de un mostrador, intentando tomar una stablecoin de un cliente y terminar con ella en una cuenta que controla, sigue siendo el último participante para el que alguien diseña.

Lo único con forma de comercio en este paquete: los saldos confidenciales

Hay una excepción genuina que vale la pena nombrar, y es la parte más interesante de la mejora para cualquiera que opere un negocio sobre una cadena pública.

Las pruebas de conocimiento cero que Transaction V1 vuelve más fáciles de acomodar son las que están detrás de Confidential Balances, una extensión de Token-2022 que cifra saldos y oculta los montos transferidos sin dejar de verificarlos on-chain. Las direcciones de las cuentas de token siguen siendo públicas; los montos no. Y el diseño incluye una clave de auditor opcional: un mint se puede configurar para que cada transferencia cifre el monto para emisor, receptor y auditor, con la prueba confirmando que los tres textos cifrados contienen el mismo valor. El público no puede leer el monto. El auditor sí.

Esa combinación le habla directo a la objeción más común que escuchamos de negocios evaluando pagos on-chain: "no quiero que mi facturación sea legible para cualquiera con un explorador de bloques". Es una objeción justa. Una dirección de cobro estática en una cadena pública es un feed de facturación en vivo para competidores, proveedores y cualquiera que esté negociando con vos.

Ahora, con los ojos abiertos: los saldos confidenciales son una capacidad a nivel de cadena, con herramientas reales detrás, pero no son algo que un checkout de comercio te entregue hoy como un interruptor, ni en Solana ni en ningún lado. Es una capacidad sobre la que el ecosistema recién ahora tiene espacio para construir — que es exactamente por qué Transaction V1 importa más de lo que sugiere un conteo de bytes.

Hasta que eso llegue a la capa de checkout, la mitigación práctica es mucho más simple y está disponible ya: no reutilices una sola dirección para todo. El POS de Payzum emite un QR nuevo por cada venta en vez de una dirección estática pegada en la pared. No es criptografía, es higiene básica, pero es la diferencia entre un feed público de facturación y un conjunto de solicitudes de pago sin vincular.

El cambio que rompe cosas es la lección real para los comercios

La parte de esta mejora que debería registrar un dueño de negocio no es el conteo de bytes. Es lo que tuvo que pasar en los diez días previos al 9 de septiembre.

Las llamadas RPC que leen bloques y transacciones —getTransaction, getBlock— fallan con una transacción V1 salvo que quien llama pase maxSupportedTransactionVersion: 1, devolviendo el error -32015. Un blockSubscribe por WebSocket que no se actualizó emite block: null y deja de avanzar. Las versiones mínimas de SDK se movieron: @solana/kit 8.0.0, @solana/web3.js 1.99.0-beta.0, los crates de Rust solana-* en 4.2.x.

Traducilo fuera del lenguaje de ingeniería. Un servicio que vigila pagos y quedó atrasado en la versión de una librería podría, el 9 de septiembre, dejar de ver una categoría de transacciones. No porque el dinero no llegue, sino porque su indexador dejó de avanzar. La cadena estaría bien. El tablero estaría mal.

Ese es el costo normal de construir sobre infraestructura pública que se mueve, y es un costo que alguien tiene que cargar. La pregunta es quién. Si sos un restaurante, un gimnasio o una tienda online, la respuesta correcta es enfáticamente vos no. Nunca deberías ser la persona que sigue flags de maxSupportedTransactionVersion, números de epoch o canales de release de Agave. Para eso está un procesador de pagos — y es una pregunta justa para hacerle a cualquier proveedor antes de firmar: ¿quién en tu empresa se ocupa de seguir las actualizaciones de las cadenas, y qué pasó el 9 de septiembre?

Por qué nada de esto responde la pregunta real del comercio

Esto es lo que una cadena más rápida no puede arreglar.

Cuando un cliente te paga en stablecoins, el dinero se mueve en un solo salto on-chain. Que ese salto liquide en 400 milisegundos o en 150 es un error de redondeo al lado de la pregunta de dónde cae. Si cae en la wallet agrupada de un procesador, ahora tenés un crédito contra una empresa, no un saldo en una cadena — y tu tiempo real de liquidación es el calendario de payouts de esa empresa, no la finalidad de Solana. Si esa empresa te congela la cuenta, la compran, cambia su política de riesgo o cierra, el rendimiento de la cadena te resulta irrelevante.

Eso es riesgo de contraparte, y no es un problema de protocolo. Ningún SIMD lo aborda. Alpenglow no lo aborda. Es una decisión de producto que toma quien construyó la capa de aceptación, y es la única decisión que determina si la velocidad del riel de abajo te llega a vos.

El roadmap de Solana es genuinamente impresionante y genuinamente relevante: la cadena tendrá transacciones más grandes, cuentas más baratas y finalidad más rápida, y ya mueve una porción seria del volumen real de pagos con stablecoins. Pero un comercio no recibe nada de eso si el último salto del pago termina en el balance de otro.

Dónde entra Payzum: el lado de la aceptación, sin cambios el 9 de septiembre

Payzum es un procesador de pagos sin custodia y solo cripto. Los fondos van directo a wallets que controla el comercio; Payzum nunca retiene, agrupa ni controla el dinero. La liquidación es el pago.

En concreto, contra todo lo anterior:

• Solana es una red soportada hoy, junto con Bitcoin, Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain y Avalanche. Tiempos de confirmación típicos: Solana ~0,4 s, Base ~2 s, Polygon ~2 s. Ya estás sobre el riel que esta mejora mejora.
• Nada de tu configuración cambia el 9 de septiembre. Los formatos legacy y v0 siguen válidos; V1 es opcional para quien arma la transacción. No hay migración que correr ni fecha límite que perderte.
• La volatilidad se resuelve en la capa de aceptación, no en la de consenso. La conversión automática opcional a USDC o USDT te deja aceptar cripto y quedarte con dólares, con independencia de lo que pase en el roadmap de la cadena.
• La finalidad ya juega a tu favor. Los pagos on-chain no se revierten. No hay contracargos, ni adquirente, ni fees de red de tarjetas — la propiedad que más le importa a un comercio ya estaba antes de esta mejora y no es de lo que trata la mejora.
• Seguir las actualizaciones de las cadenas es nuestro problema, no el tuyo. Vos cobrás; nosotros miramos los canales de release.

Cómo funciona, paso a paso

1. Conectá tu wallet. Indicás las direcciones de Solana (y/o EVM) donde querés que llegue el dinero. Payzum nunca toma custodia de las llaves: no existe un saldo Payzum reteniendo tus fondos.
2. Elegí cómo cobrás. Online: checkout alojado, links y botones de pago, facturas con vencimiento y detección de sobrepago, suscripciones, o un plugin drop-in. Presencial: POS con QR nuevo por venta, terminales físicas y cajeros con PIN, con analítica por cajero y por terminal.
3. Elegí en qué liquidás. Aceptá lo que el cliente tenga; opcionalmente convertí automáticamente a USDC o USDT para que tus libros queden en dólares.
4. Conciliá. Webhooks firmados y una API REST empujan las confirmaciones a tus sistemas a medida que caen on-chain. El registro on-chain es el comprobante: la misma transacción que cualquiera puede verificar.

Cómo se ve esto en tres negocios reales

La abstracción solo se gana el lugar si cambia algo concreto. Tres casos:

• Una cafetería que cobra USDC en el mostrador. La confirmación de Solana por debajo del segundo ya hace que esto funcione a la velocidad de un tap de tarjeta; la mejora de finalidad de Alpenglow en octubre acá es casi invisible. Lo que le importa al dueño es que el QR sea nuevo en cada venta, que el cajero tenga PIN, que la venta no se pueda contracargar y que el USDC llegue a una wallet que él controla antes de que el cliente guarde el teléfono. Mirá cómo convertir un celular en un POS cripto.
• Una tienda online que vende a diez países. La mejora relevante no es V1: es que la tienda nunca tiene que pensar en V1. El checkout alojado toma USDC o USDT en Solana, Base o Polygon, convierte automático si el comprador pagó en algo volátil, dispara un webhook firmado y liquida directo a la wallet de la tienda, sin adquirente en el medio y sin ventana de reversión de 120 días.
• Una agencia que factura al exterior. Las facturas con vencimiento y detección de sobrepago reemplazan una transferencia que tarda días y pierde puntos en FX. La finalidad significa que la factura está saldada cuando lo dice la cadena, no cuando lo acepta un banco corresponsal. Y la mejora de cadena que acá realmente ayuda es la aburrida —cuentas de token más baratas— y ayuda a la wallet del cliente, no a la factura de la agencia.

Cadena rápida vs procesador con custodia: adónde va la velocidad

Objeciones justas

"Si la cadena cambia todo el tiempo, ¿no es riesgoso apoyar mi negocio ahí?"

El cambio acá es aditivo y opcional. Los formatos legacy y v0 siguen válidos con su tope original; nada que funcionaba el 8 de septiembre dejó de funcionar el 9. Lo que sí requirió atención fueron las herramientas —indexadores, clientes RPC, versiones de SDK—, que es exactamente la capa que le pagás a un procesador para que se ocupe. El riesgo es real; simplemente no es tuyo, y que el calendario se publicara con semanas de anticipación y con testnet primero es cómo se ve una actualización de riel bien gestionada.

"Cualquiera puede ver cuánto facturo en una cadena pública. ¿No es peor que un banco?"

En parte es cierto, y la respuesta honesta tiene dos mitades. Hoy: usá una solicitud de pago nueva por venta en vez de una dirección estática —que es lo que el POS de Payzum hace por defecto— y tratá tus direcciones de cobro como tratarías un número de cuenta. Mañana: los saldos confidenciales de Token-2022 ocultan los montos manteniéndolos verificables, con clave de auditor opcional, y Transaction V1 es parte de lo que vuelve práctico meter esas pruebas en una sola transacción. Esa capacidad es real, pero todavía no es un interruptor en el checkout de un comercio; preferimos decirlo a prometerlo.

"¿Conviene esperar a Alpenglow antes de empezar a aceptar stablecoins?"

No, y la razón está en los números. Alpenglow apunta a la finalidad, no a la primera confirmación. El pago de tu cliente ya confirma bastante por debajo del segundo en Solana. Esperar a octubre te compra una garantía de liquidación más fuerte para decisiones de tesorería y no cambia prácticamente nada en un café de 6 dólares o un pedido online de 400.