How to read a BSC transaction, field by field

To read a BSC transaction, paste its hash into a BNB Smart Chain explorer and check four things first: the status (success, failed or pending), the block and confirmations, the from and to addresses, and the token transfers section. Everything else — gas, nonce, input data and logs — explains how and why it happened.

That is the thirty-second version. The rest of this guide is the long one, written for the moment when a payment “hasn’t arrived”, a swap failed but still cost you a fee, or a support agent asks for “the TxID” and you are not sure what they mean. We will use the layout of BscScan and our own BNB transaction lookup as the reference, but the fields are the same on BSCTrace, OKX Explorer or any other tool in our explorer ranking. They all read the same chain.

What is a transaction hash on BNB Smart Chain?

The transaction hash is the ID of the transaction: 0x followed by 64 hexadecimal characters, for example 0x5c50…e3a1. It is a Keccak-256 hash of the signed transaction, which means it is derived from the content itself — change a single byte and you get a completely different hash. Wallets call it “Transaction ID”, “TxID” or “Tx hash”; it is all the same thing.

Two practical consequences. First, the hash exists the moment your wallet signs, before the transaction is in any block, so a hash alone does not prove anything happened on-chain. You still have to look it up. Second, a hash is chain-agnostic: the same 66-character string can be searched on BNB Smart Chain, opBNB or BSC Testnet, and it will only be found on the network where it was actually sent. If an explorer says “not found”, the first thing to check is whether you are on the right network — a surprising number of “missing” payments are on the testnet or on another EVM chain altogether. (Addresses, by contrast, are shorter: 0x plus 40 characters.)

BSC transaction status: success, failed or pending

The status line is the single most important field, and it has only a handful of possible values. Success means the transaction was included in a block and executed without reverting. Failed (BscScan shows “Fail” with a reason such as “execution reverted”) means it was included and executed, but the code stopped partway and undid all its effects. Pending means the network has seen it but no validator has put it in a block yet. And Dropped & Replaced means another transaction with the same nonce got confirmed instead, so this one will never happen.

One thing “success” does not mean: that you got what you expected. A successful call to a scam token contract is still a success. A transfer of a fake “USDT” that is not the real Tether contract is still a success. The status tells you the code ran; the token transfers section, further down, tells you what actually moved. Keep both in mind and you will avoid most of the classic misunderstandings.

Block, timestamp, confirmations, from and to

Block is the number of the block that contains the transaction. Next to it, most explorers show confirmations — how many blocks have been added on top since. With a block roughly every 0.45 seconds after the Fermi hard fork, confirmations pile up fast: a transaction that is one minute old already has well over a hundred. BNB Smart Chain also has fast finality, which makes a block irreversible in a little over a second, so exchanges that still wait for dozens of confirmations are being cautious rather than technically required to.

Timestamp is the time of the block, not the moment you pressed “send”. Explorers usually show it in UTC and as “x seconds ago”. BSC blocks now also carry a millisecond timestamp, which matters when blocks are less than half a second apart, but the human-readable time is what you quote to a counterparty.

From is always a regular wallet (an externally owned account) — only wallets can sign transactions. To is either another wallet or a smart contract. This is where people trip up most often. When you send USDT, the “To” field shows the USDT token contract, 0x55d3…7955, not your friend’s address. The real recipient appears in the token transfers section. If “To” is empty and the page says “Contract Creation”, the transaction deployed a new contract, and the explorer shows the new address instead.

Value is the amount of native BNB sent along with the transaction. For a plain BNB transfer, that is the payment. For a token transfer or a swap it is often 0 BNB, which alarms people who were expecting to see “100 USDT” there. Nothing is wrong — tokens are not BNB, and their amounts live in the logs, not in the value field.

Transaction fee, gas price, gas limit and nonce

Every operation on BNB Smart Chain costs gas, a unit of computational work. The transaction fee you paid is simply gas used × gas price, shown in BNB and often in dollars. A plain BNB transfer always uses exactly 21,000 gas; a token transfer typically uses a few tens of thousands; a DEX swap through several pools can use a few hundred thousand. At the current network floor of 0.05 gwei, the 21,000-gas transfer costs about 0.00000105 BNB — a tiny fraction of a cent. Our live BSC gas tracker shows what gas costs right now.

Gas limit is the maximum your wallet allowed the transaction to use; gas used is what it actually consumed. Explorers often show both with a percentage, such as “131,402 / 197,103 (66.7%)”. Unused gas is not charged. If gas used equals the limit exactly and the status is failed, the transaction ran out of gas, and resending with a higher limit will usually fix it.

Gas price is what you offered per unit of gas, in gwei (one billionth of a BNB). BNB Smart Chain supports EIP-1559-style transactions, but with a base fee fixed at zero, so on BscScan you will see “Base: 0 Gwei” alongside a max fee and a priority fee. In practice the effective gas price is what matters. A share of the fees collected in each block is burned under BEP-95, which is why some explorers show a “burnt fees” line.

Nonce is a counter per sending address: your first transaction has nonce 0, the next 1, and so on. The network processes them strictly in order. If nonce 41 is stuck, nonces 42, 43 and 44 will sit behind it and wait, no matter how much gas they offer. That rule is annoying when things go wrong and extremely useful when you fix them, as you will see below. The explorer also shows a transaction type — 0 for legacy transactions, 2 for EIP-1559 ones — which you can mostly ignore.

Method, input data and event logs

When the recipient is a contract, the transaction carries input data: an instruction telling the contract which function to run and with what arguments. The first four bytes are the function selector. 0xa9059cbb is transfer(address,uint256), 0x095ea7b3 is approve(address,uint256). Explorers translate the selector into a friendly method name — “Transfer”, “Approve”, “Swap Exact Tokens For ETH” — using the verified contract’s ABI or a public signature database. On a verified contract, BscScan can also decode every argument, so you can see the exact spender or amount you signed.

Why care? Because the method is where approvals hide. If you meant to buy a token and the method says “Approve” or “Set Approval For All”, you did not buy anything yet — you gave a contract permission to move your tokens. That is normal on a DEX, and dangerous on a phishing site. Our guide to tracking a BNB wallet and its approvals shows how to review and revoke those permissions later.

Event logs are messages the contract emits while it runs. They are how explorers know what happened inside. The most common one on BNB Smart Chain is the BEP-20 Transfer event, whose first topic always starts with 0xddf252ad. Each log lists the emitting contract (the token), the indexed topics (from and to) and the data (the amount). Swaps produce a cluster of logs — transfers in and out of the pool, a Sync, a Swap — and reading them in order is the most reliable way to reconstruct a complicated transaction.

Token transfers and internal transactions on BSC

The token transfers section (BscScan calls it “ERC-20 Tokens Transferred”, our lookup calls it “Token transfers”) is the human-friendly summary of the Transfer logs: which token, how much, from whom, to whom. This is the field that answers “did the USDT arrive?”. Check the token name and its contract address: the real BEP-20 USDT is 0x55d398326f99059fF775485246999027B3197955, and it uses 18 decimals, unlike Tether on Ethereum. Anything else calling itself USDT is a copy. Our BEP-20 token explorer lists the genuine contracts for the big stablecoins.

Internal transactions are a different animal. They are movements of native BNB triggered by a contract during execution — a router paying you BNB after you sell a token, a bridge releasing funds, a multisig forwarding a payment. They are not signed by anyone, have no hash of their own and do not appear in the standard transaction receipt. Explorers reconstruct them by tracing the execution, and BscScan and BSCTrace show them in an “Internal Txns” tab. So if someone says “I sent you BNB from the exchange” and the transaction value is zero, look there. Lightweight explorers that read only public RPC data, including ours, show logs and token transfers but not traced internal calls, so switch to BscScan when you need them.

BNB transaction pending, failed or dropped: what went wrong?

Pending

On BNB Smart Chain, pending is supposed to be a blink. With sub-second blocks, a healthy transaction is usually included within a second or two. If it hangs around, there are three usual suspects. The gas price is below what validators accept — some wallets and bots still hard-code old values, and anything below the network floor may not be relayed at all. There is a nonce gap: an earlier transaction from your address never confirmed, so this one waits behind it. Or your wallet broadcast to a flaky RPC node that never passed the transaction on, in which case the explorer may not know about it at all. BscScan’s own help centre explains that nodes can drop pending transactions from their pool when the fee is too low or pool limits are hit.

Failed or reverted

A failed transaction is final: it is in a block, forever, with a red label. The contract ran and hit a require or revert, so every state change was undone — except the fee. On PancakeSwap the classic reasons are PancakeRouter: INSUFFICIENT_OUTPUT_AMOUNT (price moved beyond your slippage), EXPIRED (the deadline passed) and TransferHelper: TRANSFER_FROM_FAILED (missing approval, not enough balance or a token with transfer restrictions). “Out of gas” means the gas limit was too low. For tokens that fail every time you try to sell, read our guide to checking a BSC token for honeypots before you spend another cent on gas.

Dropped & Replaced

This status means a different transaction with the same nonce from the same address got confirmed first. Usually that is you: you pressed “Speed up” or “Cancel”, and the wallet sent a replacement. The BscScan explanation of dropped transactions covers the edge cases. The important part is that only one of the two can ever execute, so a dropped transaction never “comes back” and charges you twice.

How to speed up or cancel a stuck BSC transaction

The nonce rule is your rescue tool. Because only one transaction per nonce can be confirmed, you can overwrite a stuck one by sending another with the same nonce and a higher gas price. Here is the sequence we use.

1. 1

   Confirm it is really stuck

   Open the hash in an explorer. If it shows Pending for more than a minute, or the explorer cannot find it at all, check the nonce: every earlier nonce from your address must already be confirmed.

2. 2

   Find the nonce of the stuck transaction

   The nonce is on the transaction page, and in MetaMask under the transaction details. Write it down — the replacement must reuse exactly this number.

3. 3

   Speed up: resend with a higher gas price

   In MetaMask or Trust Wallet tap Speed up. The wallet re-signs the same transaction with the same nonce and a higher fee. Nodes usually require at least a 10% higher gas price to accept a replacement.

4. 4

   Or cancel: send 0 BNB to yourself with the same nonce

   Tap Cancel, or manually send a 0 BNB transfer to your own address using the stuck nonce and a higher gas price. Whichever lands first wins; the other becomes Dropped & Replaced.

5. 5

   Check the result on the explorer

   Search your address, not the old hash. You should see the replacement confirmed with that nonce. Only then send new transactions, so you do not create another nonce gap.

MetaMask documents both buttons in its help article on pending transactions; to set the nonce by hand you first enable custom nonce in its settings. If the stuck transaction is already confirmed or failed, there is nothing to cancel — a mined transaction cannot be reversed by anyone, including validators and explorers. And if your wallet shows “pending” but no explorer has ever heard of the hash, the transaction never reached the network: clearing the wallet’s activity data and resending is usually enough. Before you retry, double-check that your wallet is on the right network with the right settings — our MetaMask setup for BNB Smart Chain lists the chain ID and explorer URL.

Proof of payment: why screenshots are not proof

Here is the uncomfortable truth about screenshots of explorer pages: they are pictures. Editing the amount, the recipient or the status in a browser takes a few seconds with the developer tools, and fake “payment confirmed” images are a staple of marketplace and OTC scams. If someone sends you a screenshot, ask for the hash and look it up yourself. If you are the one paying, send the hash or a link the other side can open.

That is exactly what our transaction lookup is built for. Search any BNB Smart Chain hash and the result has a permanent share link, a native share sheet and buttons for Telegram, WhatsApp and X. The Copy payment receipt button copies a short plain-text proof — status, amount, sender, recipient, time, confirmations and the link — so the receiver can verify it in one tap. Nothing is stored and no login is needed; the receipt is only a convenient wrapper around public chain data, and the link inside it is what makes it trustworthy.

A good receipt check takes ten seconds: the status is success, the token contract is the real one, the recipient is the address you expect (compare the first and last six characters, not just the first four), and the confirmations keep rising. If all four hold, the payment is final. If you want a second opinion, open the same hash on BscScan or BSCTrace — the data will match, because every explorer reads the same public ledger. Developers who want to do the same check programmatically can read the receipt over JSON-RPC, as shown in our BNB explorer API guide, and the underlying transaction model is described in the ethereum.org transactions docs, which apply one-to-one to BSC.