|
| 1 | +Here's how to verify the status of a transaction when using an RPC node as an intermediary step to the Polygon zkEVM network. |
| 2 | + |
| 3 | +This guide is for users who send transactions to an RPC node, which in turn relays these transactions to the Polygon zkEVM network. |
| 4 | + |
| 5 | +## Recommended endpoints |
| 6 | + |
| 7 | +After sending a transaction (TX) to the network using the `eth_sendRawTransaction`, use the following endpoints to check the TX status: |
| 8 | + |
| 9 | +1. `eth_getTransactionByHash` |
| 10 | +2. `eth_getTransactionReceipt` |
| 11 | + |
| 12 | +### Using `eth_getTransactionByHash` |
| 13 | + |
| 14 | +When checking the TX status using the `eth_getTransactionByHash`, the result can be either one of the following. |
| 15 | + |
| 16 | +(a) If the result is null, it means either the TX doesn't exist in the network or it was discarded. |
| 17 | + |
| 18 | +(b) If the result contains some data, then |
| 19 | + |
| 20 | +- If the fields `block_num` and `block_hash` are null, it means the TX is still in the pool and is pending. |
| 21 | + |
| 22 | +- If the fields `block_num` and `block_hash` are NOT null, it means the TX was mined. |
| 23 | + |
| 24 | +### Using `eth_getTransactionReceipt` |
| 25 | + |
| 26 | +When checking the TX status using the `eth_getTransactionReceipt`, again the result can either one of the following. |
| 27 | + |
| 28 | +(a) If the result is null, it means either the TX doesn't exist or it is still pending to be mined. In this case, use the `eth_getTransactionByHash` endpoint to check it. |
| 29 | + |
| 30 | +(b) If the result contains some data, it means the TX was already mined. However, |
| 31 | + |
| 32 | +- If the field status is 1 (success), it means the TX affected the state as expected. |
| 33 | + |
| 34 | +- If the field status is 0 (failure), it means the TX has consumed gas used while processing the TX, but hasn't changed the state as expected. |
0 commit comments