What the receipt proves

Canonical inclusion

Minednote checks that a public RPC reports chain ID 56 and returns the transaction and receipt for the requested hash. It compares their block, index and addresses, then checks the hash at that index in the block returned for the block number. An included transaction can succeed or revert.

The confirmation count is the latest observed block minus the receipt block plus one. The report records when the lookup ran and which RPC served it. A chain reorganization can change the result.

Top-level BNB value

The BNB amount comes from the transaction value field, shown in BNB and exact wei. A successful transaction with empty calldata may still interact with a contract. On a reverted transaction, the submitted value did not settle. Internal value movements are outside this view.

The fee uses gas used multiplied by the receipt’s effective gas price. It stays unavailable when the receipt omits that price.

Transfer events

Rows use the standard Transfer signature, two indexed addresses and one 32-byte amount. Each row shows its emitting contract, sender, recipient, log index and raw integer amount. ERC-721-style logs with an indexed token ID are skipped.

A contract can emit the same event signature without changing balances. These rows establish what the receipt records. They cannot certify token identity, ownership or actual balance changes.

Scope and limits

The hash is sent to public RPC providers. The JSON export is made in your browser and stores the observed data, including public addresses. The tool has no wallet connection and sends no transactions.

Reports describe one lookup. They are not finality guarantees, audits, invoice verification or certification of the parties behind wallet addresses.

BNB Chain RPC reference