Verify a Bridged ERC-20 Deposit on Both Chains
A bridged ERC-20 deposit is confirmed by matching the source transaction, destination token contract, recipient and amount across both chains—not by a wallet notification.
The Blockheight Editors··3 min read
Verify a bridged ERC-20 deposit by matching the source-chain bridge transaction with the token transfer recorded on the destination chain. A wallet notification or a successful source transaction alone does not confirm that tokens reached the intended address. For Polygon PoS, the timing of Polygon Bridge deposits can help explain why the destination transfer may appear later.
What should you check on the source chain?
Start with the transaction hash on the chain where you sent the tokens. Open its receipt in a block explorer and check that the transaction succeeded, the sender and bridge contract are the expected addresses, and the token amount matches your deposit.
For an ERC-20, inspect the token contract’s Transfer event in the receipt logs. It records the token contract, sender, recipient and amount. A successful receipt means the transaction executed without reverting; it does not by itself prove that the bridge completed the destination-side step.
Confirm the bridge contract address from the bridge interface or its official documentation before trusting a transaction. A lookalike token or contract can produce convincing logs while representing a different asset.
How do you confirm the destination transfer?
Switch the explorer to the destination network and check the receiving address’s token activity. Look for a successful transaction and a Transfer event emitted by the expected destination token contract, with the intended address as recipient.
Compare the amount after accounting for token decimals and any disclosed fee. The raw event amount is an integer; explorers usually display it in human-readable units. A bridge may also represent the asset with a destination-chain token contract that differs from the source token’s address.
Check the recipient’s token balance as a second confirmation. A balance increase at the relevant block supports the transfer record, but a current balance can change if the tokens were subsequently sent or used. Match the event and block first, then use the current balance as a status check.
Why can the two transactions look different?
Bridges coordinate actions across separate chains, which do not share one transaction receipt. A source transaction can lock or escrow tokens while bridge messaging and destination-chain execution happen separately; the destination side may mint a representation or release tokens held there.
Use both transaction records to distinguish a pending bridge operation from a completed deposit. Check:
- The source transaction succeeded and interacted with the expected bridge.
- The destination transaction succeeded on the intended network.
- The destination token contract is the expected representation of the asset.
- The recipient and amount match, allowing for fees and token decimals.
Do not treat a token’s ticker or logo as proof of identity. Different contracts can use the same symbol, and bridge representations can have different addresses from their source assets. The contract address and chain are the useful identifiers.
What should you do if the deposit is missing?
If the source transaction succeeded but no destination transfer appears, check the bridge’s status using the source hash and confirm that you are viewing the correct network and recipient address. Avoid sending a second deposit until you know whether the first operation is pending or failed.
The practical standard is a matching destination-chain transfer from the expected token contract to the intended address. If that record is absent, the bridge’s final status and the reason for any delay remain unconfirmed until its on-chain activity or status page updates.