Receipt Query

Overview

A Receipt Query requests the execution receipt for a submitted blockchain transaction, usually by transaction hash. A receipt is normally unavailable while a transaction is pending, and receipt presence does not by itself establish the number of confirmations or economic finality required by a payment policy.

The main risks include assuming null means failure, accepting a reverted transaction, losing track after replacement, and treating early inclusion as final. The receipt can provide block inclusion, execution status, gas use, contract address, and emitted logs depending on the network. The Receipt Query runbook should define who can retry, cancel, replay, reconcile, communicate, and approve an exception.

In production, teams should define ownership and apply canonical transaction hash, null-result handling, block and status checks, confirmation tracking, reorganization handling, and log decoding. Operational metrics for Receipt Query should use stable denominators and separate technical activity from successful business completion.

Useful measures include receipt availability time, reverted transaction rate, missing receipt count, reorganization corrections, and confirmation latency. Receipt Query is closely connected to Transaction Query, Transaction Submission, and Transaction Broadcast. The production boundary for Receipt Query should identify the authoritative system, responsible owner, accepted states, and recovery path.

For Receipt Query, identifiers and timestamps should remain stable enough to trace the technical action to its final business outcome. Monitoring for Receipt Query should distinguish transport success, processing success, and the final external or financial result.

Changes to Receipt Query should be tested against normal, failed, delayed, duplicate, and recovery paths that apply to the operation.