How to verify a bridged token your wallet rejects

If your wallet rejects a bridged token, first check the destination chain’s transaction and token contract; a missing asset display does not prove the bridge transfer failed. Wallets often show only assets their token lists recognize, while the chain records balances under token contracts. A transfer can therefore be complete even when the wallet has no label or price for the asset.

Start with the transaction hash from the bridge interface or source wallet. Look it up on an explorer for the source chain, then use the bridge’s own status page to see whether it has completed the destination step. For a separate account of settlement limits, see this explanation of how a Monero bridge handles settlement limits. A source-chain confirmation alone may show only that assets were locked or burned; it does not establish that the destination asset was minted or released.

How do you tell whether the bridge transfer completed?

Check the bridge’s state transition from source input to destination outcome. In a lock-and-mint design, the source contract holds the original tokens and a destination contract mints a representation. In a burn-and-release design, the source representation is burned and the original asset is released on the other chain. Other bridges use validators or messaging systems to authorize the destination action. The exact contracts and finality rules differ by bridge.

Use the bridge’s official interface or documentation to identify the route and destination token. Then confirm the destination transaction on the destination chain’s explorer. Look for a successful transaction and an event or balance change involving your receiving address and the expected token contract. A completed source transaction paired with a pending bridge message points to settlement delay or a failed destination execution. A successful destination transaction with no wallet display points instead to a network, token-recognition, or indexing issue.

Do not infer token identity from its name or ticker. Anyone can deploy a token with the same symbol. The address and chain together identify the contract you need to check; a contract address on one network says nothing by itself about an asset with the same address or name on another. For non-EVM chains, use the chain’s own asset identifier and explorer fields rather than expecting an EVM-style contract address.

How do you find the right token contract?

Get the destination contract address from the bridge’s official token or route information, or from the destination transaction that the bridge says completed. Check that address on an explorer for the destination chain. Verify that the contract’s token transfers or balance query refer to your wallet address. If the bridge publishes a mapping between the source asset and destination representation, confirm that the mapping matches both networks and the route you used.

Then compare the displayed balance with the contract’s on-chain balance for your account. For an ERC-20 token, the contract’s balanceOf(address) function returns the account’s token balance, while decimals() determines how the integer amount is formatted for display. A token can appear to have the wrong quantity if software uses the wrong decimals. The symbol and name are useful labels, but they do not authenticate a contract.

When the destination balance is present, adding a custom token to a wallet usually tells its interface which contract to query. It does not move funds, complete a bridge message, or establish that the contract is legitimate. On EVM networks, select the destination network first, then import the verified contract address. If the wallet has no custom-token option, the balance can still be checked in the explorer or another read-only interface.

What should you do if the wallet still rejects it?

Classify the failure before taking another action. These checks separate a display problem from a transfer that needs bridge support:

• Source transaction absent or reverted: the bridge input did not complete. Check the source-chain transaction status and any token allowance or call failure before trying again.
• Source transaction succeeded, destination step pending: the bridge has not shown a completed destination action. Keep the transaction hash and route details; do not submit a second transfer to “unstick” the first.
• Destination transaction failed: the bridge may require recovery or a retry through its own interface. A failed execution does not mean the wallet can claim the asset by importing a token.
• Destination balance exists, wallet omits it: confirm the selected network, then import the contract if the wallet supports custom tokens. Refreshing an asset list may help if its indexer is stale.

Never paste a contract address supplied only by a stranger or an unsolicited token message. Check it against the bridge’s official route information and the destination explorer, and compare every character before importing. Importing an asset is generally a display action, but interacting with a counterfeit contract or signing an unrelated approval can expose funds.

The useful distinction is simple: the wallet displays a view of chain state, while the bridge changes state across chains. Verify the destination transaction and contract first. If the on-chain balance is there, the wallet’s rejection is likely a recognition problem; if the destination action is absent or failed, the bridge transfer remains unresolved.