Receipt Query
Pronunciation: rih-SEET KWEER-ee
Also known as: Transaction Receipt Query, Execution Receipt Lookup
Definition
A Receipt Query requests the execution receipt for a submitted blockchain transaction, usually by transaction hash. The receipt can provide block inclusion, execution status, gas use, contract address, and emitted logs depending on the network. 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.
Overview
Meaning and scope
A Receipt Query requests the execution receipt for a submitted blockchain transaction, usually by transaction hash. The receipt can provide block inclusion, execution status, gas use, contract address, and emitted logs depending on the network. 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.
Mechanism and operation
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. The production boundary for Receipt Query should identify the authoritative system, responsible owner, accepted states, and recovery path.
Practical payment example
A merchant retrieves a transaction receipt for a stablecoin transfer. Its parser checks execution status and expected logs, and retains the block reference for confirmation tracking.
Operational checks
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.
Distinctions and limits
The main risks include assuming null means failure, accepting a reverted transaction, losing track after replacement, and treating early inclusion as final.
Related reading
Related definitions: Transaction Query, Transaction Submission.
Example
A merchant retrieves a transaction receipt for a stablecoin transfer. Its parser checks execution status and expected logs, and retains the block reference for confirmation tracking.
Comparison
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.
Key Takeaway
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.
Sources
- Ethereum JSON-RPC API — Ethereum Foundation (2026-08-03)
- Ethereum Transactions — Ethereum Foundation (2026-08-03)
- Bitcoin Core RPC Documentation — Bitcoin Core (2026-08-03)