Read the Bridge Call Before You Sign

Before signing a bridge transaction, verify the source chain, the contract receiving the transaction and the actions encoded in its calldata. The wallet signs a source-chain transaction; it does not sign a guarantee that the destination-chain transfer will complete as quoted. A route can combine token approval, a swap and a bridge call, with some instructions nested inside encoded data.

A route quote describes a proposed path, while the transaction is the executable request. For a closer account of how route selection fits together, the fuller explanation of bungee bridge covers that layer. At the signing step, check the wallet’s actual transaction fields against the route you chose; labels such as “bridge” or “swap and send” do not identify what the contract will execute.

Which transaction fields should you check?

Check the chain, sender, recipient contract, native-token value and calldata as one transaction. The chain must be the route’s source chain, and the sender must be the account you intend to spend from. The to address is usually a contract, not the destination wallet: it is the contract that receives the call on the source chain. Compare it with the expected contract address for that chain, using a source you trust.

The value field is the amount of the chain’s native asset sent with the call. If the route uses an ERC-20 token, the token amount will generally be an argument encoded in calldata rather than this field. A non-zero value may be expected when bridging the native asset or paying a native-token fee, but it should match the quoted action. An unexplained recipient, chain or value is a reason to stop and rebuild the route.

How do you decode bridge calldata?

On an EVM chain, calldata starts with a four-byte function selector followed by arguments encoded according to the contract’s ABI. Decode it with the ABI for the contract at the transaction’s to address, then read the arguments rather than relying on a selector lookup alone. A selector identifies a function signature candidate; it does not prove which deployed code will handle the call or that the displayed function label is trustworthy.

Read the decoded call for the token and amount being spent, the recipient, the destination chain, and any minimum output or deadline the route exposes. Bridge contracts often take packed or dynamic bytes that contain instructions for another contract or chain. If the top-level ABI shows an opaque bytes field, a partial decode is not a completed check: inspect the nested payload using the relevant interface, or treat the action as unverified. Multicall and router calls need the same scrutiny at each inner call; a harmless-looking outer function can dispatch several token transfers or swaps.

For a route that swaps before bridging, trace the input token through the swap path and check the minimum amount accepted by the swap. On the destination side, distinguish an estimated receive amount from an encoded minimum: the estimate is a quote, while the minimum is a constraint only if the destination execution enforces it. Some routes encode destination instructions in the source transaction; others rely on a separate message or later execution. Do not infer destination guarantees from source calldata that does not contain them.

What should you check about token approval?

An ERC-20 approval authorizes a spender to transfer tokens from your account, so identify that spender and the allowance amount before approving. The spender may be a router or bridge contract, and it can differ from the transaction’s eventual target. If the route needs an approval transaction first, inspect that transaction separately: its to should be the token contract, and its decoded approve(spender, amount) arguments should match the route’s intended contract and amount.

• Confirm the token contract and amount being approved or transferred.
• Match the spender to the route’s expected contract on the source chain.
• Check whether the allowance is limited to the needed amount or set higher than required.
• Review any permit or authorization signature with the same care as a transaction.

An approval does not itself bridge tokens; it grants permission for a later call to move them. A broad allowance can remain usable after this route, so a precise allowance reduces what that spender can take if the contract or route is later misused. A permit signature can grant similar authority without an on-chain approval transaction, which makes its spender, token and allowance fields just as important to verify.

What can simulation confirm before signing?

Simulating the exact transaction can show whether it would currently execute on the source chain and can expose reverts, but it cannot prove the bridge’s later delivery. Simulate with the same sender, chain, target, value and calldata; changing any of those means you are testing a different request. A successful simulation is a useful consistency check, not a security audit or settlement guarantee.

Before signing, compare the decoded transaction with the route summary: source and destination chains, token in, recipient, amount, fees and any minimum receive condition. Recheck the wallet’s final signing screen after simulation, because a changed quote can produce different calldata. The practical rule is simple: sign only when the contract call and token authority match the action you meant to authorize. A route name is a description; the transaction fields and decoded calls are the instruction.