Four Checks Before Routing Funds After a Token Alert

After an unverified-token alert, verify the token contract and your wallet’s permissions before routing any funds. A wallet or explorer label is metadata, not a consensus rule: it does not freeze a token or prove that its contract is malicious. The useful question is what happened on-chain. Receiving an unknown token does not by itself grant its contract permission to spend other ERC-20 tokens; an allowance set with approve can let a spender move the approved token with transferFrom.

What does an unverified-token alert establish?

An unverified alert establishes that the service showing it could not confirm the token’s identity or code against its own records. It does not establish that the token is counterfeit, safe, or unsafe. Token symbols and names are not unique, and an explorer’s “verified” source code label only means published source was matched to deployed bytecode; it is not an audit or endorsement.

Start with the chain and contract address, not the token name or logo. Compare the address with the issuer’s or protocol’s official token list, reached independently rather than through a message accompanying the alert. Check the transaction that introduced the token: its hash, sender, contract address and event logs. If the address does not match a trusted listing, do not use that token as the input asset for a swap or bridge.

A pending cross-chain deposit is a separate state from a token warning. AcrossBridge users choosing a next action can compare the AcrossBridge route for a pending transfer. Keep the original deposit hash and its origin and destination chains; a warning on one token does not show whether that deposit has filled.

Which four checks should come before moving funds?

Four checks separate a display warning from a wallet permission or transfer problem. Work from the on-chain record before signing another transaction.

• Step 1: Identify the asset. Match the exact contract address and chain to an authoritative token listing. Treat a matching ticker as insufficient; different contracts can use the same name or symbol.
• Step 2: Inspect your activity. Review recent transactions on the affected chain for approvals, signed permits, transfers, or contract calls you did not intend. A received token transfer is not the same as an approval.
• Step 3: Check allowances. For the relevant token and chain, inspect which spender addresses have permission and how much. If you find an allowance you did not authorize, revoke that specific allowance using a trusted explorer or wallet tool, then confirm the revocation transaction on-chain. Revocation costs a network transaction and does not undo a completed transfer.
• Step 4: Verify the route and status. If you are moving a separate, recognized asset, check the origin token, destination token, recipient, chain IDs and quoted output before signing. If a bridge deposit is already confirmed, check its status using the deposit hash before submitting another one.

How should you route funds if a bridge transfer is pending?

Track the existing deposit before initiating a second route. In Across, the relayer fills a deposit on the destination chain, while protocol settlement and reimbursement follow separately; a pending status means the deposit has not been filled yet. Check the deposit record and destination chain, then look for a fill transaction before deciding that funds are missing.

A pending label is not a failure state, and submitting another deposit can create a second transfer rather than accelerate the first. If the record shows a completed fill, confirm the destination transaction and recipient. If it shows an expiry or refund state, verify the refund transaction on the origin chain before routing the returned funds. Indexers and wallet interfaces can lag behind chain events, so use the transaction hash in the relevant chain explorer to resolve a discrepancy.

Move only assets whose contract identity you have checked. If you find an unauthorized allowance, revoke it before approving a new bridge spender. If you signed a transaction that exposed your recovery phrase or private key, treat the wallet as compromised: create a fresh wallet with a new secret and transfer remaining assets there. A token warning alone does not justify exposing a seed phrase to a supposed support agent or signing a “verification” transaction.

The confirmed facts are the transaction receipt, emitted events, allowance state and destination fill or refund on-chain. The alert’s label, a token’s legitimacy, and an indexer’s current status remain unverified until checked against the contract address and chain records. Route funds only after those records agree.