Skip to content

Latest commit

 

History

History
47 lines (31 loc) · 2.37 KB

File metadata and controls

47 lines (31 loc) · 2.37 KB

Verifying Transactions and Retrieving Logs

This document outlines the two-step process for verifying a transaction's status and retrieving the detailed log events it generated using the Qubic REST API.

Step 1: Verify the Transaction

To check the status of a specific transaction, send a GET request to the /tx/{tx_hash} endpoint.

Command:

curl <API_URL>/tx/{tx_hash}

Example Request:

curl <API_URL>/tx/mfqbthbgkejwbflawtfkolokgxybcgkqwegpfrtcyedkcymuzwrjypleswvn

When you receive the transaction data, pay close attention to these four key fields:

  • transactionIndex: The position of the queried tx in tickData, this position is arranged by tick leader. If this field is missing or equal -1 , it indicates that the queried transaction is not included to the tick.
  • isExecuted: A boolean indicating if the transaction met all requirements and was successfully executed by the smart contract.
  • logIdFrom: The starting ID for the log events generated by this transaction.
  • logIdTo: The ending ID for the log events generated by this transaction.

The range between logIdFrom and logIdTo (inclusive) represents all log events produced by this single transaction. The number of logs can vary depending on the complexity of the smart contract logic.

Step 2: Retrieve Transaction Logs

Once you have confirmed the transaction was executed and have the logIdFrom and logIdTo values, you can fetch the detailed log events.

Use the GET /log/{epoch}/{from_id}/{to_id} endpoint, passing the log IDs from Step 1 into the {from_d} and {to_id} parameters.

Command:

curl <API_URL>/log/{epoch}/{logIdFrom}/{logIdTo}

Example Scenario

Let's use the transaction mfqbthbgkejwbflawtfkolokgxybcgkqwegpfrtcyedkcymuzwrjypleswvn.

  1. Query TX: A developer queries .../tx/mfqbthbgkejwbflawtfkolokgxybcgkqwegpfrtcyedkcymuzwrjypleswvn.
  2. Analyze Response: The response shows isExecuted: true and provides a logIdFrom and logIdTo.
  3. Example: In this scenario, the transaction involved DMIC...WAAK sending 1 coin to QX, which was then returned. This generated two distinct events:
    • Event 1: Coin sent to QX.
    • Event 2: Coin returned from QX.
  4. Query Logs: The developer then calls .../log/{epoch}/{logIdFrom}/{logIdTo} to retrieve the full details of both events, confirming the entire flow of the transaction.