> For the complete documentation index, see [llms.txt](https://sodex.com/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sodex.com/documentation/for-developers/developers/valuechain-evm/transaction-finality.md).

# Transaction Finality

Execution and consensus finality are separate from product settlement. ValueChain uses **single slot finality** (2-second slot): a receipt with a block means the transaction is included and will not revert.

JSON-RPC block tags (`latest`, `safe`, `finalized`) and confirmation depth are documented in [Differences from Ethereum](/documentation/for-developers/developers/valuechain-evm/differences-from-ethereum.md#consensus-finality). Do not treat `finalized` as a second wait after the receipt.

## Confirmation stages

| Stage     | Evidence                                                | Meaning                                                                              |
| --------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Submitted | A transaction hash                                      | Identifies the submission; does not prove inclusion or success.                      |
| Included  | A receipt with `blockHash`, `blockNumber`, and `status` | The transaction is in a block and will not revert. `status` is only the EVM outcome. |

A plain SOSO or ERC-20 transfer that does not create a product request is complete at Included when `status` is `"0x1"`.

## Track transaction execution

Query the receipt for the hash you are tracking. For Relayer submissions, follow [Transaction Status](/documentation/for-developers/api-reference/relayer-api/transaction-status.md) first and use any `replaced_by_hash` before querying JSON-RPC.

```bash
curl -sS https://mainnet.valuechain.xyz \
  -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["YOUR_TRANSACTION_HASH"]}'
```

* `result: null`: not included yet. This is not a failure. Query [`eth_getTransactionByHash`](/documentation/for-developers/api-reference/json-rpc/eth-gettransactionbyhash.md): an object without `blockNumber` is still pending; `null` from both methods means this node does not have the transaction (it may have been dropped, or Relayer replaced it).
* Receipt `status: "0x1"`: execution succeeded in the reported block.
* Receipt `status: "0x0"`: execution failed in the reported block.

`status` does not confirm product settlement. Persist the transaction hash and the receipt `blockHash`. Treat a JSON-RPC error as a failed query, not as a failed transaction. Do not resubmit while the first hash is unknown or pending; that can create a duplicate request.