# Guide: Read an Ethereum transaction receipt through AirnodeHub

Canonical: https://forkbrief.com/news/314abe4a-c78b-48ed-89ec-3ab9762908d7
Published: 2026-10-18T19:06:47.222Z
Publisher: Fork Brief

A documented dRPC workflow keeps the network, transaction hash and receipt fields together, without treating an API signature as blockchain finality.

An Ethereum transaction receipt answers a narrower question than an explorer page: what receipt does this node return for this transaction hash? AirnodeHub’s dRPC listing provides a documented route for that read, while keeping the response and its provenance together.

Here, transaction receipt means an Ethereum execution record, distinct from the Airnode attestation attached to an API response. An [indexed wallet report](https://forkbrief.com/news/0f683771-c3bb-4367-bef9-9950d2bfb5f3) uses separate balance and history operations.

### Specify the network and the read

The Airnode document exposes a `jsonRpc` operation with `network`, `method` and optional `params`. For an Ethereum receipt lookup, the documented flow uses `network: "ethereum"`, `method: "eth_getTransactionReceipt"` and the existing transaction’s hash as the first entry in `params`.

This is a request pattern, not an executed transaction or a tested result. The network parameter is a dRPC slug. The Airnode document explicitly rejects numeric chain identifiers such as `1` or `0x1` in that field, even though an application may use those identifiers elsewhere.

### Interpret the receipt before describing it

[The Ethereum specification](https://ethereum.github.io/execution-apis/api/methods/eth_getTransactionReceipt/) defines the result as a receipt object or `null`. dRPC’s documentation says a pending or unknown transaction can return `null`; that response does not establish that the transaction failed.

For a returned receipt, retain `transactionHash`, `blockHash` and `blockNumber`, plus `status` when present. The specification defines `status` for post-Byzantium transactions and distinguishes successful execution from failure through that field. A receipt is information about execution in a block, not a promise that an application achieved its intended business outcome.

### Keep the provenance boundary

The Hub’s [dRPC listing](https://airnodehub.api3.org/explore/drpc) is an API3-operated third-party relay. Its signature identifies the Airnode that served the response, rather than an original-provider signature or a guarantee of consensus finality. Keep the operation, inputs, response and attestation together when sharing the result.

The listing was marked Sponsored during early access when checked on October 13, 2026, and the operation was Free. That is current pricing, not permanent free access. A passthrough request using `x-airnode-sign=false` is unsigned. No wallet signing or transaction submission is part of this read-only example.

## Sources

- [dRPC Airnode API definition](https://airnode-drpc.fly.dev/) — API3 AirnodeHub
- [Attestation | AirnodeHub](https://airnodehub-docs.api3.org/airnode/attestation) — airnodehub-docs.api3.org
- [dRPC official Ethereum receipt documentation](https://drpc.org/docs/ethereum-api/transactionsinfo/eth_getTransactionReceipt) — dRPC official Ethereum receipt documentation
- [For API consumers | AirnodeHub](https://airnodehub-docs.api3.org/api-consumers/) — airnodehub-docs.api3.org
- [Ethereum Execution APIs](https://ethereum.github.io/execution-apis/api/methods/eth_getTransactionReceipt/) — Ethereum Execution APIs
- [dRPC integration listing](https://airnodehub.api3.org/explore/drpc) — API3

- [Editorial policy](https://forkbrief.com/editorial-policy)
- [Request a correction](https://forkbrief.com/corrections)