Use a smart contract wallet as the destination when you need its on-chain controls; choose a plain token delivery unless an action must run on arrival. A smart contract wallet is an account managed by code, such as rules or multiple signers. Across relayers can send supported tokens to its address without asking the wallet to sign or be online.
A relayed fill can send tokens straight to a smart wallet
Yes, a smart wallet can receive a fill when its address is the destination on the destination chain. A relayer is a service that pays to deliver the output tokens first, then settles with the protocol later. For a basic transfer, the destination contract transfers tokens to the recipient address; the wallet does not need to call or approve anything.
Across’s Intent Lifecycle documentation describes the fill as a relayer calling the destination chain’s SpokePool with its own tokens. The deposit names the recipient and output token, so check that the wallet address is correct on that chain and that the token is one your wallet can use.
Choose a callback only when the wallet must act on arrival
A callback lets a contract do something when the tokens arrive, such as deposit them into another contract. It requires a recipient contract that supports Across’s handleV3AcrossMessage function, which receives the relayer’s message. A normal smart wallet may not support that function, so sending a message to it can make the fill fail.
For a recurring transfer, keep the recipient as the smart wallet and leave the message empty unless you have verified its callback support. If you are deciding between a basic fill and an on-arrival action, which acrossbridge transfer type fits explains how to choose a transfer path; the same choice affects how many steps your destination needs.
Across’s Embedded Crosschain Actions guide describes a different pattern: the fill calls a designated handler contract, which then runs the requested action. That can save a separate transaction, but adds a contract call that must succeed. A reverted call can prevent the fill from completing in that transaction.
Price the destination behavior you will actually use
A plain delivery usually has fewer moving parts and less destination work. A callback adds execution work for the relayer, so its gas cost can affect the quote and whether a relayer is willing to fill. Compare quotes using the same destination, token, and action you plan to submit; a quote for simple delivery may not reflect a callback’s cost.
For repeated transfers, I would check these details before sending:
- The wallet address is valid on the destination chain, and the intended token is supported there.
- The wallet is already deployed if the destination action needs its code to run.
- The recipient supports handleV3AcrossMessage if you provide a message.
- The quote includes the same recipient and action as the final transaction.
- The fill deadline leaves time for a relayer to complete the transfer.
A common mistake is to reuse a successful externally owned account setup for a smart wallet and add a message without checking the receiving code. An externally owned account is controlled directly by a private key; it cannot run a contract callback. Fix this by quoting a plain transfer first, then test the callback path with a small amount before making it part of a frequent workflow.
Track the fill and keep recovery simple
After sending, track the deposit until its status shows filled; that confirms the relayer completed the destination step. Across documents pending, filled, and expired states, and an expired deposit may be eligible for a refund. A wallet balance alone can be a poor signal if the wallet address or token differs from the one you expected.
When speed and fewer steps matter, a direct token delivery to a verified smart wallet is usually the simpler setup. Add an on-arrival call only when avoiding a separate transaction is worth the extra compatibility check and gas. Before acting, ask yourself: does the wallet only need to receive the tokens, or must it execute something as they arrive?