> ## Documentation Index > Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Suporte para Transação v1 > "Prepare sua integração Solana para a transação v1: defina maxSupportedTransactionVersion para 1, atualize para um SDK compatível com v1 e leia as taxas prioritárias de transactionConfig." O Agave 4.2 introduz a transação v1 ([SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md)). Assim que o gate de funcionalidades é ativado na mainnet, carteiras e programas começam a enviar transações v1, e qualquer solicitação que busca dados completos de transações deve optar por recebê-las. Esta página cobre o que muda, quais endpoints Helius são afetados e como atualizar seu código. Para a lista completa do Agave 4.2, incluindo tipos de recompensas, semântica de atualização de contas e temporização de slots, veja a [lista de verificação de migração Agave 4.2](https://www.helius.dev/blog/agave-4-2-migration-checklist). ## O que muda na transação v1 Transações legadas e v0 não são alteradas. Para a maioria das integrações, duas coisas sobre a transação v1 são importantes: * **Você deve optar por recebê-la.** Solicitações para dados completos de transações precisam `maxSupportedTransactionVersion: 1` e sua biblioteca cliente precisa de uma versão que possa desserializar v1. * **O orçamento de computação move-se para o cabeçalho da mensagem.** Uma mensagem v1 carrega um objeto `transactionConfig` com `computeUnitLimit`, `heapSize`, `loadedAccountsDataSizeLimit`, e `priorityFee`. Não há instruções de programa ComputeBudget em uma transação v1. O formato de transmissão também muda (um novo byte de versão e assinaturas no final da transação), mas isso só afeta o código que decodifica bytes de transações brutas. Veja [Decode raw transaction bytes](#decodifique-bytes-de-transações-brutas-com-um-parser-compatível-com-v1) abaixo. Em respostas JSON, uma transação v1 relata `"version": 1` e seu `message` inclui `transactionConfig`: ```json theme={"system"} { "version": 1, "transaction": { "signatures": ["..."], "message": { "accountKeys": ["..."], "instructions": [ { "programIdIndex": 3, "accounts": [0, 1], "data": "3Bxs4..." } ], "recentBlockhash": "...", "transactionConfig": { "computeUnitLimit": 200000, "heapSize": null, "loadedAccountsDataSizeLimit": 200000, "priorityFee": 50000 } } } } ``` `"priorityFee": 50000` significa que essa transação paga 50.000 lamports no total. Um campo `null` significa que o remetente não o definiu. Mensagens legadas e v0 omitem `transactionConfig` completamente. ## Defina maxSupportedTransactionVersion para 1 Toda solicitação que retorna dados completos de transações deve declarar a maior versão de transação que pode lidar. Defina `maxSupportedTransactionVersion: 1` em: * [`getTransaction`](/docs/pt-BR/rpc/guides/gettransaction) * [`getBlock`](/docs/pt-BR/rpc/guides/getblock) * [`getTransactionsForAddress`](/docs/pt-BR/rpc/gettransactionsforaddress) com `transactionDetails: "full"` * [`transactionSubscribe`](/docs/pt-BR/rpc/websocket/transaction-subscribe) com `transactionDetails: "accounts"` ou `"full"` * [`blockSubscribe`](/docs/pt-BR/api-reference/rpc/websocket/blocksubscribe) Uma solicitação que omite o parâmetro, ou o define como `0`, falha com erro JSON-RPC `-32015` assim que toca uma transação v1: ```json theme={"system"} { "jsonrpc": "2.0", "error": { "code": -32015, "message": "Transaction version (1) is not supported by the requesting client. Please use \"maxSupportedTransactionVersion\" in your request." }, "id": 1 } ``` Para `getBlock`, uma transação v1 em qualquer lugar do bloco falha em toda a solicitação. Se você ver `-32015` nos seus logs, o projeto já está falhando em transações com versão. ```json getTransaction theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "getTransaction", "params": [ "2id3YC2jK9G5Wo2phDx4gJVAew8DcY5NAojnVuao8rkxwPYPe8cSwE5GzhEgJA2y8fVjDEo6iR6ykBvDxrTQrtpb", { "encoding": "jsonParsed", "commitment": "confirmed", "maxSupportedTransactionVersion": 1 } ] } ``` ```json getBlock theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "getBlock", "params": [ 341197053, { "encoding": "jsonParsed", "transactionDetails": "full", "maxSupportedTransactionVersion": 1 } ] } ``` ```json getTransactionsForAddress theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "getTransactionsForAddress", "params": [ "86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY", { "transactionDetails": "full", "encoding": "jsonParsed", "limit": 100, "maxSupportedTransactionVersion": 1 } ] } ``` ```json transactionSubscribe theme={"system"} { "jsonrpc": "2.0", "id": 1, "method": "transactionSubscribe", "params": [ { "accountInclude": ["86xCnPeV69n6t3DnyGvkKobf9FdN2H9oiVDdaMpo2MMY"] }, { "commitment": "confirmed", "encoding": "jsonParsed", "transactionDetails": "full", "maxSupportedTransactionVersion": 1 } ] } ``` ## Atualize seu SDK antes de aumentar o valor Definir `maxSupportedTransactionVersion: 1` informa ao nó para retornar transações v1. Sua biblioteca cliente ainda tem que desserializá-las. Atualize primeiro, depois mude o parâmetro: | Cliente | Versão mínima com suporte à transação v1 | | ----------------------------------------------- | ----------------------------------------- | | `@solana/kit` | 8.0 | | `@solana/web3.js` | v3 | | Rust `solana-sdk` / `solana-transaction-status` | Uma versão construída em crates Agave 4.2 | | `yellowstone-grpc-client` | 13.3.0 | | `yellowstone-grpc-proto` | 12.6.0 | | `helius-laserstream` (JavaScript) | 0.8.4 | | `helius-laserstream` (Rust) | 0.6.3 | | `helius-laserstream` (Go) | 0.2.0 | Implementações mais antigas `VersionedTransaction.deserialize` em JavaScript lidam apenas com legado e v0 e lançam em um byte líder `0x81`. Protos mais antigos do Yellowstone são anteriores aos campos de mensagem v1, então consumidores gRPC nessas versões nunca veem `transactionConfig`. Para clientes gRPC em Go, regenere a partir dos protos Yellowstone mais recentes e `solana-storage-proto`. ## Leia taxas prioritárias de transactionConfig O código que estima a taxa prioritária de uma transação ao escanear instruções de programa ComputeBudget (`ComputeBudget111111111111111111111111111111`, `setComputeUnitPrice`, `setComputeUnitLimit`) lê toda transação v1 como pagando zero. No v1 os valores estão em `message.transactionConfig`, e as unidades diferem: | Formato | Onde vive a taxa | Unidade | | ---------- | ------------------------------- | --------------------------------------- | | Legado, v0 | Instrução `setComputeUnitPrice` | Microlamports por unidade de computação | | v1 | `transactionConfig.priorityFee` | Lamports totais para a transação | Não porte a matemática legada `price × computeUnitLimit ÷ 1e6` para `priorityFee`. Já é o total. ```typescript priority-fee.ts theme={"system"} import bs58 from "bs58"; const COMPUTE_BUDGET = "ComputeBudget111111111111111111111111111111"; /** Total priority fee in lamports for a `json`-encoded transaction. */ function priorityFeeLamports(tx: any): number { const message = tx.transaction.message; // v1: the header carries the total directly. if (message.transactionConfig) { return message.transactionConfig.priorityFee ?? 0; } // Legacy and v0: derive it from ComputeBudget instructions. let microLamportsPerCu = 0n; let computeUnitLimit: bigint | null = null; let otherInstructions = 0; for (const ix of message.instructions) { if (message.accountKeys[ix.programIdIndex] !== COMPUTE_BUDGET) { otherInstructions++; continue; } const data = bs58.decode(ix.data); const view = new DataView(data.buffer, data.byteOffset, data.byteLength); if (data[0] === 2) computeUnitLimit = BigInt(view.getUint32(1, true)); if (data[0] === 3) microLamportsPerCu = view.getBigUint64(1, true); } // Without an explicit limit, the runtime grants 200,000 CU per non-ComputeBudget instruction, capped at 1,400,000. const limit = computeUnitLimit ?? BigInt(Math.min(otherInstructions * 200_000, 1_400_000)); return Number((microLamportsPerCu * limit) / 1_000_000n); } ``` Filtre em `transactionConfig` (ou em `version === 1`) em vez de na presença de instruções ComputeBudget, já que uma transação legada sem taxa prioritária também não tem nenhuma. ## Decodifique bytes de transações brutas com um parser compatível com v1 Esta seção só se aplica se você consumir bytes de transações brutas, por exemplo, de [preconfSubscribe](/docs/pt-BR/pre-confirmations/preconf-subscribe), [preprocessedSubscribe](/docs/pt-BR/preprocessed-transactions/preprocessed-subscribe), ou uma resposta codificada RPC `base64`. Se você trabalhar com respostas `json` ou `jsonParsed`, ignore. A transação v1 altera o layout do fio de duas maneiras: * **Byte de versão.** Uma transação v1 começa com `0x81` (decimal 129). Uma transação v0 começa com `0x80`. * **Assinaturas movem-se para o final.** Legado e v0 colocam assinaturas primeiro, depois a mensagem. A transação v1 coloca a mensagem primeiro e as assinaturas por último, assim decodificadores `bincode` que esperam um array de assinatura líder falham em bytes v1. Layout byte a byte de uma transação Solana v1: byte de versão, cabeçalho, máscara de configuração, especificador de vida útil, contagens de endereço e instrução, três endereços de 32 bytes, configuração de unidade de computação, cabeçalho de instrução, índices, identificadores, lamports e uma assinatura de 64 bytes no final Para um passo a passo campo a campo do formato de fio v1, veja [Transaction v1 in the Solana transaction versions article](https://www.helius.dev/blog/solana-transaction-versions#transaction-v1). Use um decodificador que entenda o layout v1: * **Rust:** [`agave-transaction-view`](https://docs.rs/agave-transaction-view) analisa legados, v0 e v1 no lugar. [`wincode`](https://docs.rs/wincode), o serializador compatível com bincode usado por SDKs Solana atuais, também decodifica v1 em `VersionedTransaction`. * **JavaScript / TypeScript:** `@solana/kit` 8.0+ ou `@solana/web3.js` v3. Decodificadores personalizados precisam verificar o primeiro byte: `0x81` significa v1 e as assinaturas seguem a mensagem em vez de precedê-la. ## Lista de Verificação 1. Pesquise `getBlock`, `getTransaction`, `getTransactionsForAddress`, `transactionSubscribe`, e `blockSubscribe`, incluindo corpos JSON-RPC brutos e wrappers SDK como `connection.getParsedTransaction`. 2. Atualize para um SDK compatível com v1. 3. Defina `maxSupportedTransactionVersion: 1` em cada chamada encontrada na etapa 1. 4. Substitua a varredura de instruções ComputeBudget por uma verificação `transactionConfig` e trate `priorityFee` como lamports totais. 5. Substitua decodificadores brutos estilo `bincode` por `agave-transaction-view` ou um SDK atualizado. 6. Aumente as dependências de streaming para as versões na tabela acima. 7. Verifique logs para `-32015` após a mudança para confirmar que nada ainda falha. Para um mergulho técnico nas especificações de versão de transações Solana, formatos de fio e exemplos, leia nosso artigo, [Solana Transaction Versioning: Legacy, v0 and v1](https://www.helius.dev/blog/solana-transaction-versions). ## Relacionado Parâmetros, formato de resposta e exemplos para buscar uma única transação. Busque um bloco completo, incluindo todas as transações que ele contém. Histórico de transações filtrado e paginado para qualquer endereço em uma chamada. Todas as mudanças de quebra do Agave 4.2, com etapas de remediação.