How to Read a Bridge Transaction on a Block Explorer Step by Step

26 September 2026

You can read a bridge transaction on a block explorer by finding the source-chain transaction, identifying the bridge contract call, then locating the corresponding destination-chain transaction using the bridge's own log data or a bridge-specific explorer. The exact steps differ slightly by bridge design, but the pattern is consistent across lock-and-mint and message-passing bridges.

Why a bridge transaction is not one transaction

A cross-chain bridge moves value from one blockchain to another. No single transaction exists on both chains. Instead, there are two linked transactions: one on the source chain that locks or burns tokens, and one on the destination chain that mints or releases them. The bridge software (or its validators) reads the first event and triggers the second. A block explorer shows you the source transaction; your job is to find its counterpart.

Step 1: find your source transaction

You already have the source transaction hash if you initiated the bridge. If not:

• From a wallet: Check your wallet history on the source chain. Most wallets show the transaction hash.
• From a bridge UI: Many bridge interfaces show a "View on Explorer" link after you submit. Click it.
• From a bridge status page: Some bridges (like Stargate or Hop) have a status page where you paste the source hash and see both sides.

Open the block explorer for the source chain (Etherscan for Ethereum, Arbiscan for Arbitrum, etc.) and paste the hash. You will see a standard transaction page.

Step 2: Identify the Bridge Contract Call

The transaction will show a "To" address. That address should be the bridge contract. If the bridge uses a proxy pattern, the "To" address is the proxy contract, and the "Interacted With (To)" field (if shown) is the implementation contract.

Look for:

• Method name: Common names include swap, send, bridge, deposit, lock, burn, transfer. If the method is something generic like multicall or execute, the bridge logic is inside the call data.
• Value: The amount of the native token (ETH, MATIC, etc.) if you bridged the native gas token. For ERC-20 tokens, the value field will be 0, and the token transfer will appear as an internal transaction or a separate ERC-20 transfer event.

Scroll down to the Logs section. This is the most important part.

Step 3: Read the Bridge Events in the Logs

Block explorers show logs as a table of indexed and non-indexed parameters. Each bridge emits a specific event when a transfer is initiated. Look for events named something like:

• Transfer (if the bridge uses a wrapper token)
• Deposit or DepositWithdraw
• MessageSent or SendMsg
• CrossChainTransferInitiated

The exact name is bridge-specific. The key data you need is almost always in the first indexed parameter or the event's data field:

• Destination chain ID: A numeric identifier for the target chain (e.g., 42161 for Arbitrum, 10 for Optimism).
• Recipient address: The destination wallet address.
• Amount: The bridged amount, often in the token's smallest unit (wei, gwei). You may need to divide by 10^decimals to get the human-readable number.
• Nonce or sequence number: A unique ID for this transfer within the bridge's system. This is your best tool for finding the destination transaction.

Some bridges encode the recipient and amount inside the data field of a generic MessageSent event. If the data is long hex, the bridge likely uses a message-passing protocol (LayerZero, Wormhole). You may need a bridge-specific explorer to decode it.

Step 4: Find the Destination Transaction

You have three ways to locate the destination transaction:

Method A - Bridge-specific explorer: Many bridges run their own explorer or status page. Paste your source transaction hash there. It will show the destination chain, destination transaction hash, and current status (pending, confirmed, failed). This is the fastest method.

Method B - Search by nonce or sequence: Some bridges post the nonce in the source event. If the destination chain's bridge contract logs the same nonce on the destination side, you can search the destination explorer for that nonce using the bridge contract's event logs. This is tedious and usually unnecessary if Method A works.

Method C - Search by recipient and time: If you know the destination address and approximate time, open the destination block explorer, paste the destination address, and look for an incoming token transfer from the bridge contract within a reasonable time window. This works but can be slow if the address has many transactions.

Step 5: Confirm the Destination Transaction

Once you find the destination transaction hash, open it on the destination chain's explorer. Verify:

• The "From" address is the bridge contract (or a relayer address, depending on design).
• The "To" address is your destination wallet.
• The token and amount match what you sent.
• The status is "Success."

If the destination transaction does not exist after a reasonable time (minutes for most bridges, up to 7 days for optimistic rollup bridges), the transfer may be stuck or failed. Check the bridge's status page and see the article on stuck bridge transfers.

What to Do If You Cannot Find the Destination Transaction

• Check the bridge's status page for any ongoing issues or maintenance.
• Verify the destination address is correct on the source chain explorer's event logs. A wrong address means the funds are lost unless the bridge has a recovery mechanism.
• Confirm the source transaction succeeded. If it reverted, no bridge event was emitted, and no destination transaction will appear.
• Wait. Some bridges batch transfers or have a delay. Optimistic bridges require a challenge period.

If all else fails, contact the bridge's support or check their documentation for a manual claim process. Many message-passing bridges require you to call a "claim" or "receive" function on the destination chain if the relayer did not deliver the message automatically.

Back to bridges