How to Check a Bridge Page Before Connecting a Wallet
A security-first checklist for bridge URLs, supported chains, fees, destination address and confirmation screens.
This article may contain affiliate links. Commercial relationships are disclosed in the affiliate policy.
A bridge page is one of the easiest places in crypto to hand over a signature that cannot be undone. The interface is usually a single button, the domain looks professional, and the transaction it asks you to sign looks like a plain transfer. The checks below take about two minutes and exist because every one of them has caught something real.
The four things to check before you connect
The domain, read character by character. Bridge phishing typically uses a name
that differs from the real one by two or three characters: a missing hyphen, a
pluralised word, a .com where the project uses .xyz. Do not check by glancing —
read the full hostname left to right, and resolve it yourself rather than following a
link from a social post. Bookmark the bridge once you have confirmed it and use the
bookmark from then on.
What chain you are on, and what chain you are actually bridging. Most bridge interfaces show the source chain in a dropdown that defaults to whatever your wallet is currently connected to. If you intend to move USDC from Ethereum but the dropdown reads Arbitrum, you are about to interact with a different bridge contract than the one you researched. Confirm the network badge in your wallet matches the one the page claims.
Whether the destination is an address you control. Bridge UIs frequently offer to send to your own address. If they offer to send anywhere else — a project’s treasury, a referral address, an “airdrop claim” — that is either an error or an attack, and there is no legitimate reason to accept it.
The approval prompt itself. Read the spender. A bridge that legitimately needs to
move your token should name a contract that matches the bridge’s own published
address. An unlimited approval of 0x000...0, or a spender you cannot find on the
project’s documentation page, is a stop sign.
What the transaction should look like
A normal bridge deposit is a transfer to a bridge contract plus an approval. Anything
beyond that — a delegatecall, a token approval to an address you did not verify, a
method name you do not recognise — deserves a second look in the block explorer before
signing. You can decode the calldata after signing as well as before, and if the
decoded call does not match what the interface said it was doing, that information is
still useful: it is the difference between losing a transaction fee and losing the
balance.
After the first bridge, once
Check that the tokens arrived on the destination chain within a few minutes. If they never appear, do not retry the same transaction. Query your source-chain address on a block explorer first, because a bridge that completed but whose receipt is slow is a very different situation from one that silently failed, and only the first is recoverable by waiting.
Why this is not the same as auditing the bridge
Every check here is about the page you are on, not the contracts behind it. A bridge can pass all four checks and still contain a flaw in its custody logic. This procedure reduces the risk that you are signing with the wrong party; it does not tell you whether the bridge’s operators can move your funds. That is a different question and it needs a different kind of research.
One habit worth keeping
Run every new bridge through a second device or a burner wallet with a small balance first. It costs one transaction fee and converts an unbounded risk into a bounded one. If the test deposit arrives correctly, you know the domain, the contracts and the destination handling are what they appeared to be.