acrossbridge offers three practical ways to move tokens between supported chains: a wallet-signed transfer, a gasless signature, or a persistent deposit address. Choose by how the sender can authorize payment, whether the destination needs an exact amount or contract action, and what the live route permits. Relayers deliver the destination tokens before settlement finishes.
When should you use a wallet-signed acrossbridge transfer?
Use the standard wallet-signed route for a one-off transfer when you can pay gas on the origin chain. It gives you a quote for a specified input token, output token, amount, destination chain, and recipient. It also supports destination actions, such as depositing the received tokens into a contract.
First, confirm the token contract on each chain; matching symbols do not establish that you have selected the intended asset. Once the chain, token, and recipient are fixed, enter them in the acrossbridge service and inspect the live amount to be received before signing. Across Bridge quotes vary with destination gas, relayer capital, and pool utilisation, so the displayed amount is more useful than a general fee claim.
The transfer starts when your origin-chain transaction deposits tokens into an Across SpokePool and records the requested destination output. A relayer sees that intent and pays the recipient from its own destination-chain inventory. Think of a local supplier delivering from stock while the intercity invoice settles later: the recipient need not wait for the supplier’s reimbursement. Across later matches the deposit and fill, then settles relayer repayment through bundled, optimistically verified records.
Check the output against the input and the origin transaction’s gas cost. For example, a quote of 998.70 USDC on Optimism for 1,000 USDC sent from Ethereum implies a 1.30 USDC bridge spread, or 0.13%, before origin gas. That spread pays for relayer gas and capital and, where applicable, liquidity provision; an integrated app may add its own fee. When input and output are different tokens, compare their values in a common unit instead of subtracting their token quantities.
For a fixed budget, choose exact input and check the quoted output. If the destination task needs a floor, minimum output sets it; if a contract requires precisely 100 USDC, exact output is the closer fit, subject to the quoted input and execution conditions. For routes with swaps, inspect slippage too: a setting of 0.005 means 0.5%, and a route with both origin and destination swaps can allocate that tolerance across the two legs.
This route is a poor fit when the sender has no origin-chain gas or cannot sign a wallet transaction. Before approval, check the spender, amount, recipient, destination chain, minimum received, and refund address in the transaction flow. If the quote marks the amount below its minimum or outside its instant-fill limit, change the amount or route before depositing.
When does a gasless signature make sense?
Choose a gasless transfer when the sender can sign an authorization but has no native token for origin gas. On supported routes, the sender signs a typed message and a submitter broadcasts the origin transaction. “Gasless” describes what the sender pays upfront in native gas; the quote still has to cover submission and bridge costs.
This option depends on the origin token’s authorization method, such as ERC-3009 or Permit2, as well as route support. A wallet holding USDC but no ETH, for example, may be able to sign for a supported transfer where an ordinary Ethereum transaction would stall. Check the live gasless quote for the exact origin and destination pair rather than assuming that every token accepted by a wallet-signed transfer also works here.
Read the signed amount, spender or authorization target, recipient, deadline, and output before signing. A signature is permission to act under its stated terms, even though no transaction leaves your wallet at that moment. Confirm where an unsuccessful transfer would be refunded: depending on the route and its settings, that may be the origin or destination chain, and the refunded token may differ from the one you expected to receive.
The gasless path does not fit a workflow that needs an embedded destination contract call; use a wallet-signed route that supports the action instead. It also does not solve a missing destination gas balance for work you plan to do after receiving the tokens. If the receiving app requires a separate transaction, budget for that chain’s gas.
When is a persistent deposit address the right choice?
Use a persistent deposit address for recurring payments, automated withdrawals, or a sender that can transfer tokens but cannot complete a new bridge quote and wallet signature each time. The address is tied to a destination token and recipient and can be reused. Access to this method is gated, and supported inputs are specific to each route.
The deciding check is the address response’s supported inputs: origin chain, token contract, minimum and maximum amounts, indicative fee, and fill time. For a withdrawal intended to deliver USDC on Optimism, verify that the exact Ethereum token being withdrawn is listed for that deposit address. Sending a different token or using an unsupported chain is not an alternate route; it can leave funds outside the expected sweep and refund flow.
A persistent address has no per-transfer amount in its setup and does not lock a fresh quote each time someone sends funds. Its indicative fee and arrival time therefore deserve another check near the transfer, especially for a large or time-sensitive payment. The sweep into the bridge adds a step before the relayer fill, so the quoted fast-fill time should not be read as the total time from an external withdrawal request.
This method is less suitable for a single wallet transfer that needs a firm minimum output, an exact output, or a destination contract action. For those tasks, the wallet-signed Across Protocol bridge route gives you transaction-specific terms to inspect. If you do use a deposit address, retain the address configuration and each origin transaction hash so you can match incoming funds to the destination delivery.
What else should you check before sending?
Check the route’s expected fill time, expiry and refund terms, and security assumptions alongside its output amount. These determine whether the transfer meets your task even when the quoted fee looks acceptable.
How fast is the transfer in practice?
Relayer fills on supported mainnet routes commonly take around two seconds after the deposit is observed, but that is an estimate, not a deadline. Origin confirmation, a deposit-address sweep, chain conditions, relayer inventory, and any destination action can add time. If timing matters, use the route’s current expected fill time and confirm the destination fill rather than treating the origin transaction hash as proof of arrival.
What happens if no relayer fills it?
An unfilled intent becomes eligible for a refund after its fill deadline. The origin funds remain in the SpokePool until the refund is processed through a settlement bundle, challenge period, and any required cross-chain message; that can take several hours. Check the refund address and chain before sending, then track the deposit as pending, filled, expired, or refunded. A delayed fill is a reason to check status, not to submit the same transfer again.
What security assumption matters most?
acrossbridge is non-custodial in the sense that the sender deposits into contracts and a relayer supplies its own destination funds; the relayer does not take possession of the sender’s wallet. Settlement uses bonded proposals and an optimistic challenge process, which depends on invalid proposals being detected and disputed. Smart-contract, chain-finality, and token risks still matter. For this transfer, verify the live route, amount received, recipient, refund destination, and gas, then send only when those terms fit the destination task.