Las transacciones de Solana crecerán hasta 4 KB: los equipos de wallets y RPC que probablemente necesitarán ayuda primero

Señales que conviene observar

• Un error al construir o decodificar v1
• Pruebas de transacciones v1 en un validador local
• Transacciones actuales próximas al límite de 1.232 bytes
• Trabajo público de compatibilidad en el repositorio de una wallet, RPC, indexador o explorador
• Preguntas sobre las priority fees de transacciones más grandes

Transaction V1 de Solana modifica una restricción alrededor de la cual los equipos de aplicaciones han diseñado desde el lanzamiento de la red: una transacción completa tenía que caber en 1.232 bytes. El nuevo formato eleva ese límite a 4.096 bytes. Solana Foundation apunta al tercer trimestre de 2026 para la activación en Mainnet, mientras que informaciones de prensa señalan el 9 de septiembre. Sin embargo, a 31 de agosto, la tabla oficial todavía muestra Devnet, Testnet y Mainnet como no activadas.

Para quien vende ingeniería de wallets, infraestructura RPC, operación de nodos, indexación o desarrollo onchain, la pregunta útil no es si todos los proyectos de Solana deben actualizarse. No todos tienen que hacerlo. La pregunta útil es qué equipos mostrarán primero trabajo de implementación concreto y qué evidencia separa una queja del parser de un proyecto externo con presupuesto.

Conclusión clave

• Las aplicaciones solo necesitan v1 si quieren enviar transacciones más grandes; las transacciones legacy y v0 siguen siendo válidas.
• Los componentes que leen, decodifican o indexan bytes de transacciones deben reconocer v1, por lo que wallets, servicios RPC, indexadores y exploradores probablemente mostrarán pronto problemas de compatibilidad.
• Un error publicado en una comunidad, una pregunta sobre tarifas o una actualización de pruebas puede elevar la prioridad de revisión. No verifica identidad, autoridad, presupuesto, estado de compra ni necesidad de ayuda externa.

Qué cambió y qué no

Una transacción de Solana contiene firmas, una cabecera de mensaje, direcciones de cuentas, datos del blockhash reciente y las instrucciones que ejecutará un programa. Todos esos elementos han compartido el mismo envoltorio de 1.232 bytes. El límite nació de una decisión temprana de red para mantener los datos dentro de un tamaño de paquete conservador, no de una conclusión a nivel de aplicación de que ningún flujo necesitaría más espacio.

Transaction V1 eleva el tamaño serializado máximo a 4.096 bytes, aproximadamente 3,3 veces el límite anterior.

La página de Solana Foundation fija el nuevo límite en 4.096 bytes, unas 3,3 veces los 1.232 bytes anteriores. Captura comprobada el 31 de agosto de 2026.

Dos propuestas definen el cambio. SIMD-0296 cubre el mayor tamaño, mientras que SIMD-0385 define el formato de transacción v1. La página oficial de actualización indica que ya es posible probarlo localmente con el validador de Solana CLI v4.2+ y Surfpool, aunque su tabla de estado todavía no muestra ninguna red activada.

Hay tres límites importantes desde el punto de vista comercial.

1. Enviar v1 es opcional. Un proyecto puede seguir enviando transacciones legacy o v0. La actualización no impone una fecha de reescritura general para todas las aplicaciones.
2. Leer v1 es una obligación de compatibilidad. Un servicio que consume bytes sin procesar no podrá asumir que los formatos antiguos son los únicos posibles cuando v1 se active. Esto afecta a indexadores, exploradores de bloques, capas RPC personalizadas, sistemas de monitorización y algunas herramientas analíticas.
3. Más bytes pueden implicar una priority fee mayor. La página oficial dice que se espera que las transacciones grandes requieran una tarifa de prioridad superior a las pequeñas con una prioridad equivalente. El coste final depende de cómo se construyan y envíen; el aumento de tamaño no produce una estimación universal.

El propio marcador de formato probablemente será una fuente temprana de errores. La comparación oficial muestra el byte cero como 0x81, 129 en decimal, para v1. Un decodificador que rechace una versión desconocida o presuponga el diseño de v0 puede fallar antes de ejecutar cualquier lógica de negocio.

La comparación oficial sitúa 0x81 (129 en decimal) en el byte cero de v1 y presenta el orden de campos y los límites de legacy, v0 y v1. Captura comprobada el 31 de agosto de 2026.

El espacio adicional hace más prácticos diseños que antes resultaban difíciles: pruebas de conocimiento cero, aprobaciones multisig anidadas, firmas BLS y flujos atómicos que exigían varias transacciones. También puede permitir sustituir la división, la gestión de finalizaciones parciales y los reintentos por una operación atómica. Esa posibilidad es real; no demuestra que a todos los proyectos les compense reescribir código que ya funciona.

Cinco tipos de proyectos que probablemente mostrarán trabajo primero

Los mejores candidatos no son simplemente las marcas más conocidas de Solana. Los equipos grandes pueden contar con especialistas de protocolo y no tener motivo para subcontratar. Una empresa menor con volumen en producción, una pila personalizada y pocos ingenieros de Solana puede tener una necesidad más clara de capacidad externa.

1. Equipos que mantienen una wallet propia

Una wallet propia o muy modificada debe construir, explicar y firmar el nuevo formato. El problema no es solo la serialización. Una transacción de 4 KB puede contener más instrucciones y cuentas, lo que complica la pantalla de firma. La compatibilidad con hardware wallets y la simulación también pueden seguir calendarios de lanzamiento distintos.

Esta categoría cobra interés cuando el equipo controla el código afectado y publica evidencia de trabajo activo: una rama con serialización v1, un error del parser, una duda sobre hardware wallets o una petición de diseño para la vista previa. “Admitimos Solana” es demasiado amplio. “Nuestro firmador no puede mostrar todas las instrucciones de la transacción v1 de prueba” ya merece investigación.

2. Proveedores de RPC, nodos y datos de transacciones

Las aplicaciones que se mantienen en v0 no afrontan un cambio disruptivo al enviar. Los servicios que leen datos tienen otra obligación. Quizá necesiten actualizar parsers, manejo de respuestas, límites de peticiones, errores, logs y documentación. Un proyecto con nodo o gateway RPC propio puede controlar todas esas capas.

La oportunidad comercial resulta más clara cuando el proveedor expone tanto el fallo como la restricción operativa: un indexador descarta versiones desconocidas, un proxy RPC rechaza un payload por encima del límite antiguo o un método devuelve errores incoherentes. Un anuncio genérico de que “el soporte v1 está en camino” dice poco sobre recursos.

3. Aplicaciones que ya luchan contra el límite de 1.232 bytes

Agregadores, libros de órdenes onchain, sistemas de liquidación de juegos, nóminas multidirección y recompensas por lotes suelen dividir trabajo porque una sola transacción no cabe. La solución puede incluir cálculo de bloques, varias firmas, secuenciación, recuperación ante fallos parciales y reintentos.

Estos proyectos tienen la motivación más fuerte porque su código actual registra el coste del límite antiguo. Busca issues que mencionen tamaño, demasiadas cuentas, empaquetado de instrucciones, lotes divididos o finalización no atómica. Después comprueba si el nuevo formato elimina realmente el cuello de botella. Los límites de cómputo, los bloqueos de cuentas, el diseño del programa y el soporte de las wallets pueden seguir siendo restricciones.

4. Equipos que intentan diseños antes poco prácticos

El multisig anidado, las pruebas ZK y los diseños basados en BLS pueden pasar de una nota de arquitectura a un plan de implementación porque los datos ya caben. Estos equipos quizá necesiten primero un estudio de viabilidad: modelado, tarifas, compatibilidad, revisión de seguridad o un prototipo en un validador local.

También es la categoría más fácil de sobreinterpretar. Un punto del roadmap que diga “explorar ZK” no es un proyecto aprobado. Un repositorio con fixtures de prueba, responsables nombrados y una versión objetivo aporta evidencia mucho más fuerte.

5. Mantenedores de indexadores, exploradores y kits de desarrollo

Toda herramienta que analice bytes sin procesar necesita una respuesta explícita para v1. Esto incluye indexadores y exploradores comerciales, además de kits de desarrollo de software (SDK) incorporados en otros productos. El trabajo puede realizarse internamente, pero los problemas pueden propagarse a clientes que dependen de una versión antigua.

La Foundation enumera versiones mínimas de SDK y separa las rutas para lectores, indexadores y aplicaciones que eligen enviar v1. Describe la lectura como un requisito disruptivo y el envío como una acción opcional. Captura comprobada el 31 de agosto de 2026.

Qué proyectos deberían subir en la cola de revisión

Usa evidencia pública para ordenar tu atención, no para declarar demanda. Cinco condiciones justifican revisar antes:

1. Las transacciones actuales ya rozan el límite antiguo. El proyecto tiene una restricción medida y no un beneficio hipotético.
2. El equipo mantiene su wallet, capa RPC, indexador o explorador. Controla el código y puede elegir el calendario.
3. Un repositorio muestra pruebas locales de v1. Fixtures, ramas, issues y pull requests indican implementación, no solo conocimiento.
4. El roadmap nombra una función que depende de más espacio. Liquidación por lotes, multisig anidado, pruebas ZK o BLS dan una razón para migrar.
5. La aplicación tiene mucho volumen y sensibilidad a tarifas. Incluso una migración correcta puede necesitar ajustes de tamaño y priority fee antes de producción.

Dos factores reducen la probabilidad de contratación externa. Un equipo líder puede tener ingenieros y capacidad de revisión propios. Además, cuando las wallets y SDK más usados admitan v1, parte del trabajo se convertirá en una actualización de dependencias. Aun así, hay que comprobar la pila, el estado de lanzamiento y la propiedad del código proyecto por proyecto.

Cómo es el primer mensaje útil en una comunidad

Los grupos de desarrolladores de Telegram, comunidades del ecosistema y canales de hackathons suelen mostrar fricción antes de que aparezca un changelog pulido. Son útiles para descubrir, pero débiles como prueba independiente.

Este es un ejemplo compuesto representativo, escrito para ilustrar el patrón y no citado de un cliente real:

“Nuestro reparto semanal paga a más de 40 direcciones. No cabe en 1.232 bytes, así que lo dividimos en tres y la lógica de reintentos es horrible.”

“¿Podría v1 hacerlo atómico? El parser de nuestra wallet todavía no reconoce el prefijo 129 y lanza un error.”

“¿Alguien ha medido las priority fees de una transacción cercana a 4 KB? Necesitamos un rango de costes antes de cambiar la ruta de pagos.”

El intercambio contiene tres hechos útiles: una solución actual, un fallo reproducible y una pregunta de costes ligada a una decisión. Sigue sin identificar empresa, responsable, presupuesto, plazo, proceso de compra o disposición a contratar.

El error del parser es la pista más fuerte porque alguien ha probado el formato. El siguiente paso es verificar: ¿qué repositorio contiene el código?, ¿solo se ejecuta en un validador local?, ¿quién controla el cliente de wallet?, ¿falta capacidad o el equipo solo documenta su propia actualización?

De una conversación a un candidato que merece seguimiento humano

Empieza por el repositorio público. Busca v1, versión de transacción, tamaño, serialización, 0x81, 129 y 4.096. Lee el código o los comentarios cercanos. Una etiqueta “help wanted”, un milestone sin asignar o un lanzamiento retrasado puede sugerir falta de capacidad, pero no demuestra presupuesto.

Después, define el componente. “Necesita v1” no es un alcance. El trabajo puede ser construcción de la wallet, experiencia de firma, compatibilidad con hardware, parsing RPC, cambios de esquema, límites, simulación, modelado de tarifas o batching de la aplicación. Un proveedor debe saber qué capa puede asumir antes de contactar.

Por último, usa una vía autorizada. Un contacto público, un canal oficial o una relación existente no equivale a tratar a cada miembro del grupo como lista comercial. Conserva como desconocido lo que la evidencia no dijo: identidad, autoridad, cantidad, presupuesto, fecha, preferencia de proveedor y estado de compra.

Dónde encaja TOP Prospect y dónde se detiene

Estas conversaciones están dispersas entre comunidades a las que el usuario ya se ha unido. Compiten con republicaciones, promociones de tokens, soporte y charla cotidiana. Alertas para “v1” o “4096” capturarán ruido y perderán contexto distribuido entre varios mensajes.

TOP Prospect permite seleccionar grupos y canales de Telegram a los que la propia cuenta del usuario está autorizada a acceder y analizar esas fuentes según un objetivo declarado. Las conversaciones candidatas existentes pueden mostrarse con mensajes originales, contexto, evidencia y prioridad para revisión humana. La prioridad indica dónde mirar primero; no completa la cualificación.

El producto no lee chats privados ni fuentes no seleccionadas. No certifica identidad, presupuesto, intención de compra ni autoridad. No garantiza descubrimiento en tiempo real ni contacta a nadie automáticamente. Estos límites importan especialmente aquí, porque un error técnico puede parecer comercial mucho antes de que el equipo decida contratar ayuda externa.

Conclusión

Transaction V1 crea dos mercados distintos de trabajo de ingeniería. Uno es la compatibilidad obligatoria para sistemas que leen bytes. El otro es el rediseño opcional para aplicaciones que quieren más espacio. El primero mostrará fallos de parsers e indexadores; el segundo, preguntas de batching, atomicidad, firma y tarifas.

El objetivo actual de Solana Foundation sitúa la activación en este trimestre, y el 9 de septiembre sigue siendo una fecha publicada por medios, no una confirmación oficial de estado. Los proveedores pueden investigar antes de que exista un anuncio de compra, pero deben mantener la distinción: la conversación encuentra el proyecto; el repositorio, la documentación primaria y la cualificación directa determinan si hay trabajo perseguible.

Fuentes

• Larger Transaction Sizes — Solana Foundation
• SIMD-0385: Transaction V1 — GitHub
• Solana Docs: Transactions
• Solana sets Sept. 9 date for Transaction V1 — crypto.news (la fecha procede de medios; el objetivo de la Foundation es el tercer trimestre de 2026)
• Solana V1 Transactions Now Testable Locally — Solana Compass

Preguntas frecuentes

¿Todas las aplicaciones de Solana deben migrar a Transaction V1?

No. Las aplicaciones que solo envían transacciones legacy o v0 pueden conservar esos formatos. Las que quieran transacciones más grandes deben adoptar v1, y los componentes que lean, decodifiquen o indexen datos v1 deben añadir compatibilidad.

¿El 9 de septiembre es una fecha de activación confirmada oficialmente por Solana?

No. El 9 de septiembre procede de informaciones de prensa; el objetivo de Solana Foundation es el tercer trimestre de 2026. A 31 de agosto de 2026, la tabla oficial todavía marca Devnet, Testnet y Mainnet como no activadas.

¿Qué componentes necesitan una revisión de compatibilidad con v1?

Los servicios RPC, indexadores, exploradores y sistemas de monitorización que analizan bytes de transacciones deben reconocer v1. También deben actualizarse las wallets y aplicaciones que construyan, muestren o firmen transacciones v1.

¿Cuánto más costará una transacción de 4.096 bytes?

No existe una cifra universal. La página oficial dice que se espera una priority fee mayor que para transacciones pequeñas con prioridad equivalente; el coste real depende de cómo se construyan y envíen.

Fuentes y lecturas adicionales

• Solana Foundation: Larger Transaction Sizes↗
• SIMD-0385: Transaction V1↗
• Solana Docs: Transactions↗
• crypto.news: Solana sets Sept. 9 date for Transaction V1↗
• Solana Compass: Solana V1 Transactions Now Testable Locally↗

Contenido elaborado por el equipo editorial

Este artículo ha sido elaborado por el equipo editorial. TOP Prospect solo procesa grupos de Telegram conectados expresamente y accesibles para el usuario. Los resultados ayudan al vendedor a decidir, pero no sustituyen el criterio humano ni contactan automáticamente con los miembros del grupo.

INVESTIGACIÓN Y DEFINICIONES

Cómo se descubre una Signal que merece atención

La metodología muestra cómo Top Prospect encuentra y organiza Signals que conviene revisar, conserva el contexto original de Telegram, elimina duplicados y ayuda a decidir qué mirar primero. Tú decides si hacer seguimiento y qué hacer después.

Abrir la metodología y las definiciones →