Build with Singularity · How-to guide
Inspect a transaction after a timeout
Use this task when a client has submitted a transaction but you do not know whether its intended effect happened. Keep the original signature and inspect that operation before creating a replacement payment.
Starting point: the first signature from the signed transaction or submission response, the endpoint/network you used, and the intended recipient and amount or application effect. The commands use Bash, curl, Node and the public CLI. No signing key or funds are required for these reads. If you only completed the offline quickstart, nothing was submitted and there is no live receipt to find.
Keep the identity and check the endpoint
Retain the signed bytes, signature, operation identifier and submission time in your application record. A timeout says the client stopped waiting; it does not establish failure. A newly signed message with a new blockhash has a new transaction identity and can create a second payment if the first succeeded. Transaction identity, retry semantics.
Select the same intended network and a node with the relevant history. Check getHealth, getVersion and getGenesisHash using the readiness procedure. Those initial probes apply to ordinary transaction inspection too. An unhealthy or wrong-network endpoint cannot resolve the uncertainty reliably.
Retrieve the receipt with the public CLI
Use the executable selected during CLI installation. Enter the saved signature when prompted; do not enter a private key.
CLI=./singularity-tools/node_modules/.bin/singularity
RPC=https://rpc.entropytoorder.xyz
read -r -p 'Saved transaction signature: ' SIGNATURE
"$CLI" tx "$SIGNATURE" --endpoint "$RPC"CLI 0.3.0 calls eto_getTransaction and displays the hash, status, runtime, height, time, sender, recipient, value, fee and any logs. Check that these match the operation you intended. Lookup implementation, display and error behavior.
Read the status row. A retrieved receipt with status failed still makes the CLI exit with code 0. The exit code describes successful retrieval/display, not successful transaction execution. A missing receipt exits with code 1 and reports that the chain has no transaction with that signature; request errors also fail the command.
This behavior was executed on Linux with CLI 0.3.0, Node 22.22.2 and npm 9.2.0 on 8 September 2026. A local read-only mock returned missing, failed and successful receipts. The CLI displayed all three as described and sent only eto_getTransaction requests. These checks establish client behavior, not a live payment result.
Inspect the exact status response when needed
The standard status method is useful when a client needs a machine-readable execution result. Build the JSON using the same SIGNATURE variable rather than hand-editing quotes:
node -e 'console.log(JSON.stringify({jsonrpc:"2.0",id:1,method:"getSignatureStatuses",params:[[process.argv[1]]]}))' \
"$SIGNATURE" > signature-status-request.json
curl --silent --show-error --max-time 15 "$RPC" \
-H 'content-type: application/json' \
--data-binary @signature-status-request.jsonInspect result.value[0], and check a top-level JSON-RPC error before interpreting it.
| Response | Meaning | Next action |
|---|---|---|
Top-level error | The lookup failed | Preserve the code/message and resolve endpoint, parameter or service failure. |
value[0] is null | This node has no matching receipt, or the signature input was malformed | Check the copied signature, endpoint identity, history and expected application state. |
Status object with err:null | The receipt records successful execution | Inspect transaction details and the intended application effect. |
Status object with non-null err | The receipt records failed execution | Read the error/logs and applicable fees or nonce changes before deciding on a new operation. |
| Request times out | Observation remains incomplete | Keep the original identity and retry bounded reads after checking service health. |
The inspected node labels every found receipt confirmationStatus:"finalized" and uses confirmations:null. This handler does not expose a gradual processed → confirmed → finalized history. Malformed base58 or a signature with the wrong decoded length also produces a null entry. Receipt-backed status.
Resolve the operation before replacing it
A missing receipt is not proof of failed execution. Reconcile the intended application effect, endpoint history and original transaction validity before signing another operation. If the outcome remains unknown, record it as unknown and keep the original signature attached to the incident.
An exact-byte retry preserves transaction identity and remains subject to replay protection and blockhash validity. Whether to retry or build a replacement is an application decision, not something this read-only task performs. Durable-nonce transactions need their own nonce-account analysis. See transaction lifecycle for these mechanisms and fees and limits for retained execution costs.
Complete the task with one recorded outcome: successful execution and its checked effect; recorded execution failure; or an unresolved result with the precise evidence gap. If the operation requires crash durability or foreign assets at a destination, continue to durability barriers or HILSA settlement. A local receipt does not establish those later boundaries.
The fresh public endpoint probes at 2026-09-08 01:44 UTC returned an upstream HTTP 521 error, so this pass did not claim a live positive receipt. See the dated availability record.