O novo formato de transação v1 da Solana aumenta o espaço disponível por transação em mais de três vezes. Contudo, clientes RPC, indexadores, relayers e patrocinadores de taxas podem falhar caso não recebam atualizações. Enquanto alguns serviços podem interromper a leitura da rede, outros podem continuar operando com limites incorretos. Assim, operadores precisam verificar a compatibilidade antes da ativação na mainnet.

Em 4 de setembro de 2026, a documentação oficial indicava que a v1 ainda não estava ativa na mainnet. Já a testnet executava o formato, enquanto a devnet operava a atualização no epoch 1140. Além disso, um changelog publicado em 28 de agosto informou que as transações v1 chegariam em breve. Esse cronograma abriu uma janela para que operadores atualizassem suas infraestruturas.

Novo formato amplia o tamanho das transações

A v1 eleva o payload máximo de 1.232 bytes para 4.096 bytes, o que representa um aumento aproximado de 3,3 vezes. Por outro lado, transações nos formatos legacy e v0 preservam os limites e comportamentos atuais. Portanto, usuários e aplicações que continuarem nesses formatos não precisam migrar. A criação de transações v1 também permanece opcional.

Consumidores de RPC precisam enviar o inteiro maxSupportedTransactionVersion: 1 ao usar getTransaction, getBlock ou blockSubscribe. Caso essa opção esteja ausente, uma consulta getTransaction para v1 retorna o erro -32015. Além disso, uma única transação v1 pode fazer a consulta getBlock falhar para todo o bloco. Nesse caso, o problema afeta a leitura, embora as demais transações estejam válidas.

No serviço blockSubscribe, o sistema emite block: null e deixa de avançar no primeiro slot afetado. No entanto, o parâmetro apenas informa ao serviço RPC a maior versão que o cliente consegue decodificar. Ele não solicita dados v1 nem modifica o retorno de transações legacy ou v0. Dessa forma, clientes compatíveis preservam o comportamento dos formatos anteriores.

Indexadores e patrocinadores precisam rever controles

Outros erros podem ocorrer sem alertas visíveis. A v1 transfere limites de unidades de computação, dados de contas carregadas e taxas prioritárias para o objeto transactionConfig. Por isso, um indexador que examina apenas instruções ComputeBudget pode registrar orçamento computacional zero em todas as transações v1. Na prática, o serviço continua funcionando, mas produz informações incorretas.

Consumidores de Geyser e gRPC enfrentam uma limitação semelhante. A flag versioned do protobuf fica verdadeira tanto para v0 quanto para v1. Assim, um consumidor desatualizado pode classificar uma transação v1 como v0 e manter um orçamento vazio. A correção exige regenerar os stubs do protobuf e verificar Message.config, localizado no campo 7, antes de ler a flag.

Relayers, paymasters e servidores que assinam transações também precisam modificar suas políticas. Um patrocinador que procura instruções ComputeBudget para impor um teto de taxas deixa de aplicar um limite vinculante. Embora essas instruções possam aparecer em transações v1, elas serão executadas como operações sem efeito. Portanto, os servidores devem identificar o prefixo v1 0x81 e aplicar os limites no objeto transactionConfig.

O problema representa uma falha no controle da aplicação, não uma vulnerabilidade de consenso. Do mesmo modo, a situação não indica risco automático aos fundos dos usuários. Programas on-chain enfrentam uma restrição adicional, pois nenhum sysvar ou syscall atual expõe a configuração das mensagens v1. Com isso, esses programas não podem depender da inspeção de instruções ComputeBudget para autorizar ações após a ativação.

Bibliotecas compatíveis com transações v1

As versões mínimas com capacidade de leitura incluem @solana/kit 8.0.0 e @solana/web3.js 3.0.0-rc.3. A lista também inclui Rust solana-* 4.2.x, Python solders 0.29.0 e solana-go 1.23.0. Já a linha web3.js 1.x lê v1 a partir da versão 1.99.0-beta.0. No entanto, essa versão não consegue criar, assinar ou enviar as novas transações.

Usuários do Yellowstone precisam de versões específicas conforme a pilha utilizada. Entre elas estão yellowstone-grpc-proto 12.6.0, plugin Geyser 15.1.1 e cliente gRPC 12.0.0. A compatibilidade também inclui @triton-one/yellowstone-grpc 6.0.0. Antes da ativação, cada equipe deve confirmar a versão aplicada aos seus serviços.

Equipes que criarem transações v1 devem definir explicitamente os limites de computação e dados de contas carregadas. Isso ocorre porque ambos começam em zero. Além disso, elas precisam remover instruções ComputeBudget sem efeito e deixar de usar tabelas de consulta de endereços. Para payloads superiores a 1.232 bytes, a codificação deve usar base64.

A mudança não representa uma migração universal de carteiras. Ainda assim, qualquer serviço que leia, indexe ou patrocine transações de terceiros precisa testar sua compatibilidade. Desse modo, operadores podem evitar interrupções de leitura e falhas silenciosas nos limites de taxas. O trabalho imediato se concentra na infraestrutura que poderá receber transações v1 após a ativação na mainnet.