How to Send Tokens to an Escrow on Another Network

To send tokens to an escrow on another network, use a bridge route that can deliver the required asset and call the escrow contract on the destination chain. A normal token transfer only moves assets within the network where it is sent. Across networks, a bridge has to move or account for value on the source chain, verify that step, then arrange a corresponding action on the destination chain.

The route usually has three parts: your wallet, a bridge contract or service, and the destination escrow. Some routes also use a decentralized exchange to swap tokens before or after the bridge. That extra step can change the amount delivered, so check the route and its fees before confirming. For a closer look at how ParaSwap routing fits around a bridge transfer, see this guide to ParaSwap routing before you bridge.

How does a cross-network escrow transfer work?

A cross-network transfer starts with an instruction on the source chain and finishes with a separate action on the destination chain. The exact method depends on the bridge. In a lock-and-mint route, the source-side contract holds tokens, and a destination-side contract issues an equivalent representation. In a burn-and-release route, tokens are destroyed on one chain and released from reserves on the other. In both cases, a verification step must establish that the source action happened before the destination action proceeds.

Think of it like handing a numbered claim ticket between two counters: the first counter records the deposit, and the second accepts proof before releasing the matching value. The analogy has limits—the bridge’s contracts and verification system determine what counts as proof—but it helps explain why the transfer may not settle instantly. The wallet submits the source transaction; bridge components observe and verify it; then the destination transaction executes or becomes available for execution.

What do I need to check before sending?

Check that the route supports the exact source network, destination network, token, and escrow action. A bridge that can deliver a token to a wallet may not be able to call a contract with the data that escrow requires. If the escrow is meant to receive a deposit for a particular order or beneficiary, its required parameters must travel with the transfer or be supplied in a supported destination step.

Before signing, confirm these details in the route or escrow interface:

• Networks: The selected source and destination must match the escrow’s deployment.
• Asset: Check the token contract and whether the escrow accepts the original token or a bridged representation.
• Recipient and instructions: Verify the escrow address and any order, beneficiary, or deposit data.
• Amount and costs: Review fees, any swap, the estimated amount delivered, and what happens if execution is delayed or fails.

Wallet approval is a separate permission from the transfer itself. When a token requires approval, inspect the spender shown by the wallet and approve only the amount needed if the interface allows it. Then read the transaction summary: the source transaction may authorize a bridge contract, while a later destination action may deposit into escrow.

What happens if the escrow does not receive the tokens?

A source-chain confirmation does not by itself prove that the escrow credited the deposit. The destination step may still be waiting for verification, a relayer, or a manual claim; some routes complete it automatically. Use the route’s status page or transaction records to check both chains, and look for the destination transaction and the escrow’s own deposit record. If a transfer stalls, use the bridge’s recovery instructions and provide the source transaction identifier rather than sending a second deposit.

For most users, the better choice is a route that explicitly supports delivery to the destination contract and carries the escrow’s required instructions. A basic bridge transfer to an ordinary wallet address can move value across networks but may leave the escrow with nothing to associate with the intended order. The key change is that the transfer has two linked stages: source-side custody or burn, then destination-side verification and deposit. Watch the destination transaction and escrow record to confirm the second stage actually completed.