Qué cambia en las transacciones v1
Las transacciones heredadas y v0 no cambian. Para la mayoría de las integraciones, hay dos aspectos importantes de las transacciones v1:- Debes habilitarlas explícitamente para recibirlas. Las solicitudes de datos completos de transacciones necesitan
maxSupportedTransactionVersion: 1, y tu biblioteca cliente necesita una versión que pueda deserializar v1. - El presupuesto de cómputo se traslada al encabezado del mensaje. Un mensaje v1 contiene un objeto
transactionConfigconcomputeUnitLimit,heapSize,loadedAccountsDataSizeLimitepriorityFee. Una transacción v1 no contiene instrucciones del programa ComputeBudget.
"version": 1 y su message incluye transactionConfig:
"priorityFee": 50000 significa que esta transacción paga 50,000 lamports en total. Un campo null significa que el remitente no lo estableció. Los mensajes heredados y v0 omiten transactionConfig por completo.
Establece maxSupportedTransactionVersion en 1
Cada solicitud que devuelve los datos completos de una transacción debe declarar la versión de transacción más alta que puede procesar. EstablecemaxSupportedTransactionVersion: 1 en:
getTransactiongetBlockgetTransactionsForAddresscontransactionDetails: "full"transactionSubscribecontransactionDetails: "accounts"o"full"blockSubscribe
0 falla con el error JSON-RPC -32015 en cuanto encuentra una transacción v1:
getBlock, una sola transacción v1 en cualquier parte del bloque hace que falle toda la solicitud. Si ves -32015 en tus registros, el proyecto ya está fallando con transacciones versionadas.
Actualiza tu SDK antes de aumentar el valor
EstablecermaxSupportedTransactionVersion: 1 indica al nodo que devuelva transacciones v1. Tu biblioteca cliente aún debe poder deserializarlas. Actualízala primero y luego cambia el parámetro:
Las implementaciones anteriores de
VersionedTransaction.deserialize en JavaScript solo procesan transacciones heredadas y v0, y generan un error ante un byte inicial 0x81. Los protos anteriores de Yellowstone son previos a los campos de mensajes v1, por lo que los consumidores de gRPC que usan esas versiones nunca ven transactionConfig. Para los clientes gRPC de Go, vuelve a generarlos a partir de los protos más recientes de Yellowstone y solana-storage-proto.
Lee las comisiones de prioridad desde transactionConfig
El código que calcula la comisión de prioridad de una transacción buscando instrucciones del programa ComputeBudget (ComputeBudget111111111111111111111111111111, setComputeUnitPrice, setComputeUnitLimit) interpreta que todas las transacciones v1 pagan cero. En v1, los valores se encuentran en message.transactionConfig y las unidades son diferentes:
No adaptes el cálculo heredado de
price × computeUnitLimit ÷ 1e6 a priorityFee. Este último ya representa el total.
priority-fee.ts
transactionConfig (o version === 1), no según la presencia de instrucciones de ComputeBudget, ya que una transacción heredada sin comisión de prioridad tampoco las contiene.
Decodifica bytes sin procesar de transacciones con un analizador compatible con v1
Esta sección solo se aplica si consumes bytes sin procesar de transacciones, por ejemplo, desde preconfSubscribe, preprocessedSubscribe o una respuesta RPC codificada conbase64. Si trabajas con respuestas json o jsonParsed, omite esta sección.
Las transacciones v1 cambian el formato de transmisión de dos maneras:
- Byte de versión. Una transacción v1 comienza con
0x81(129 en decimal). Una transacción v0 comienza con0x80. - Las firmas se trasladan al final. Las transacciones heredadas y v0 colocan primero las firmas y luego el mensaje. Las transacciones v1 colocan primero el mensaje y las firmas al final, por lo que los decodificadores de estilo
bincodeque esperan un arreglo inicial de firmas fallan con los bytes de v1.

Byte layout of a transaction v1 with three addresses and one instruction. The signature sits at the end, after the message.
- Rust:
agave-transaction-viewanaliza transacciones heredadas, v0 y v1 directamente.wincode, el serializador compatible con bincode que usan los SDK actuales de Solana, también decodifica v1 enVersionedTransaction. - JavaScript / TypeScript:
@solana/kit8.0+ o@solana/web3.jsv3.
0x81 indica v1, y las firmas aparecen después del mensaje en lugar de antes.
Lista de verificación
- Busca con grep
getBlock,getTransaction,getTransactionsForAddress,transactionSubscribeeblockSubscribe, incluidos los cuerpos JSON-RPC sin procesar y los wrappers de SDK comoconnection.getParsedTransaction. - Actualiza a un SDK compatible con v1.
- Establece
maxSupportedTransactionVersion: 1en cada llamada encontrada en el paso 1. - Reemplaza la búsqueda de instrucciones de ComputeBudget por una comprobación de
transactionConfigy tratapriorityFeecomo el total de lamports. - Reemplaza los decodificadores sin procesar de estilo
bincodeporagave-transaction-viewo un SDK actualizado. - Actualiza las dependencias de streaming a las versiones de la tabla anterior.
- Busca con grep
-32015en los registros después del cambio para confirmar que nada siga fallando.
Recursos relacionados
getTransaction guide
Parámetros, estructura de la respuesta y ejemplos para obtener una sola transacción.
getBlock guide
Obtén un bloque completo, incluidas todas las transacciones que contiene.
getTransactionsForAddress
Historial de transacciones filtrado y paginado para cualquier dirección en una sola llamada.
Agave 4.2 migration checklist
Todos los cambios incompatibles de Agave 4.2, con los pasos para solucionarlos.