Skip to main content
El método RPC getTransaction te permite obtener información detallada sobre una transacción confirmada mediante su firma. Esto incluye el slot de la transacción, la hora del bloque, los metadatos (como las comisiones, el estado y los cambios de saldo) y la propia estructura de la transacción.
Evita agrupar solicitudes para mejorar el rendimientoAgrupar métodos de archivo aumenta considerablemente la latencia. No se permiten lotes de más de 100 solicitudes.

Casos de uso comunes

  • Verificación de transacciones: Confirmar que una transacción se haya procesado y comprobar su resultado (éxito o error).
  • Visualización del historial de transacciones: Mostrar a los usuarios los detalles de sus transacciones anteriores en una billetera o explorador.
  • Auditoría y análisis: Examinar los detalles de una transacción, incluidas las instrucciones ejecutadas, las comisiones pagadas y las cuentas involucradas.
  • Depuración de transacciones fallidas: Inspeccionar los campos logMessages e err de los metadatos para entender por qué falló una transacción.
  • Indexación de datos: Extraer información específica de las transacciones para almacenarla y analizarla fuera de la cadena.

Parámetros de solicitud

  1. transactionSignature (cadena, obligatorio): La firma de la transacción codificada en base 58 que quieres consultar.
  2. options (objeto, opcional): Un objeto de configuración opcional que puede incluir:
    • commitment (cadena, opcional): Especifica el nivel de compromiso (por ejemplo, "finalized", "confirmed"). Si no se proporciona, se usa el compromiso predeterminado del nodo (normalmente "finalized").
    • encoding (cadena, opcional): La codificación de los datos de transaction. Valores comunes:
      • "json": Devuelve los datos de la transacción en un formato JSON estructurado (aunque las instrucciones aún podrían estar codificadas en base64).
      • "jsonParsed": Devuelve los datos de la transacción con las instrucciones específicas del programa analizadas en una estructura JSON legible cuando sea posible. Esta suele ser la codificación más útil para el análisis.
      • "base58": Devuelve los datos de la transacción como una cadena codificada en base 58.
      • "base64": Devuelve los datos de la transacción como una cadena codificada en base 64.
      • El valor predeterminado es "json" si Helius no lo especifica, pero el valor predeterminado de Solana podría ser diferente. Es mejor especificarlo.
    • maxSupportedTransactionVersion (número, opcional): La versión máxima de transacción que debe procesar el endpoint RPC.
      • Establécelo en 1 para incluir transacciones heredadas, v0 y v1.
      • Si se omite o se establece en un valor inferior a la versión de la transacción, la solicitud falla con el error JSON-RPC -32015 (Transaction version (1) is not supported by the requesting client). Establécelo siempre en 1. Consulta Compatibilidad con transacciones v1.

Estructura de la respuesta

El método devuelve null si no se encuentra la transacción (por ejemplo, porque aún no se ha procesado o la firma es incorrecta) o si no está confirmada en el nivel de compromiso especificado. De lo contrario, devuelve un objeto con los siguientes campos:
  • slot (u64): El número de slot en el que la transacción se incluyó en un bloque.
  • blockTime (i64 | null): La marca de tiempo Unix estimada (segundos desde la época Unix) en la que se produjo el bloque que contiene la transacción. Puede ser null si no está disponible.
  • meta (objeto | null): Un objeto que contiene metadatos sobre la ejecución de la transacción. Puede ser null si la transacción falló antes de procesarse o si los metadatos no están disponibles.
    • err (objeto | null): Un objeto de error si la transacción falló; de lo contrario, null.
    • fee (u64): La comisión en lamports pagada por la transacción.
    • preBalances (arreglo de u64): Saldos en lamports de las cuentas involucradas antes de que se procesara la transacción.
    • postBalances (arreglo de u64): Saldos en lamports de las cuentas involucradas después de que se procesara la transacción.
    • preTokenBalances (arreglo de objetos | null): Saldos de tokens de las cuentas de tokens involucradas antes de la transacción.
    • postTokenBalances (arreglo de objetos | null): Saldos de tokens de las cuentas de tokens involucradas después de la transacción.
    • innerInstructions (arreglo de objetos | null): Un arreglo de instrucciones ejecutadas como parte de CPI (invocaciones entre programas) dentro de esta transacción.
    • logMessages (arreglo de cadenas | null): Un arreglo de mensajes de registro emitidos por las instrucciones de la transacción y cualquier instrucción interna.
    • loadedAddresses (objeto, opcional): Especifica las cuentas cargadas desde tablas de búsqueda de direcciones para esta transacción. Contiene los arreglos de claves públicas writable y readonly.
    • returnData (objeto, opcional): Datos devueltos por la transacción mediante sol_set_return_data e sol_get_return_data. Contiene programId (cadena) e data (arreglo: [string, encoding]).
    • computeUnitsConsumed (u64, opcional): La cantidad de unidades de cómputo consumidas por esta transacción.
  • transaction (objeto | arreglo): La propia estructura de la transacción. El formato depende del parámetro encoding:
    • Si encoding es "jsonParsed" o "json": Un objeto con message (que contiene accountKeys, instructions, recentBlockhash, etc.) e signatures (arreglo de cadenas).
    • Si encoding es "base58", "base64": Un arreglo [encoded_string, encoding_format_string].
  • version (“legacy” | número | undefined): La versión de la transacción. Puede ser "legacy" para transacciones anteriores o un número (0 o 1) para transacciones versionadas. undefined si maxSupportedTransactionVersion no está configurado y la transacción está versionada. Una transacción v1 también incluye un objeto transactionConfig en su message con el presupuesto de cómputo (computeUnitLimit, heapSize, loadedAccountsDataSizeLimit, priorityFee), que reemplaza las instrucciones del programa ComputeBudget. Su priorityFee es la comisión total en lamports, no microlamports por unidad de cómputo.
Ejemplo de respuesta (codificación jsonParsed):

Ejemplos de código

Consejos para desarrolladores

  • Finalidad de la transacción: Asegúrate de realizar la consulta con un nivel commitment adecuado. Solicitar una transacción que no haya alcanzado el compromiso especificado dará como resultado null.
  • Volumen de datos: El objeto de respuesta puede ser muy grande, especialmente en transacciones complejas con muchas instrucciones o registros detallados. Tenlo en cuenta al procesar los datos.
  • jsonParsed frente a json: Aunque jsonParsed es muy práctico, la compatibilidad con el análisis depende de las capacidades del nodo RPC para programas específicos. Si no se reconoce un programa, sus instrucciones podrían usar como alternativa un formato menos procesado, incluso con jsonParsed.
  • Transacciones versionadas: Establece siempre maxSupportedTransactionVersion: 1 en las opciones de tu solicitud para garantizar que tu aplicación pueda manejar tanto transacciones heredadas como versionadas. De lo contrario, podrías perder datos o encontrar errores con formatos de transacción más recientes.
  • Diferencias entre proveedores RPC: Aunque la API principal es estándar, algunos proveedores RPC pueden ofrecer un análisis mejorado o campos adicionales. Helius, por ejemplo, ofrece un análisis detallado de las transacciones.
Esta guía proporciona una descripción completa del método RPC getTransaction para que puedas obtener y comprender datos detallados de transacciones de Solana.