How to route assets and call a destination contract
Moving funds to another chain is not always the end of a transaction. A lending application needs a deposit credited. A vault needs shares issued to the intended recipient. A trading application may need collateral added to an account.
A destination contract call connects the routed funds to that next action. With Trustware, a supported route can include a destination posthook: an encoded contract call that the routing provider executes on the destination chain using the destination asset.
Your application defines the action and supplies the calldata. Trustware builds and tracks the route. Your wallet or signing infrastructure authorizes the source transaction; Trustware does not hold private keys or take custody of funds.
What is a destination posthook?
A destination posthook tells a supported routing provider which contract to call after funds arrive, which function to execute, and how to fund that call.
For example, an application could route a supported asset from one chain into a vault on an EVM destination chain. Instead of asking the user to bridge, open the vault interface, and deposit separately, the application includes the vault's deposit call in the route request.
This does not mean a plain token transfer automatically becomes a vault deposit. The application must encode the contract's intended function and beneficiary correctly. The provider, rather than the user's wallet, executes the destination call. A contract that assumes the caller is the beneficiary may therefore need a different integration pattern.
Which Trustware integrations support destination calls?
Use the headless SDK or REST API. The prebuilt widget and runTopUp() do not accept destination hooks.
The current documented requirements include:
- An EVM destination chain and a deployed destination contract.
- The contract's ABI and the correct function arguments.
- A supported provider and route for the requested action.
- SDK version 1.1.10 or later when using the headless SDK.
A supported destination chain alone does not establish that every provider can execute every call. Check the actual route and test the destination contract interaction.
See the vault destination guide for the implementation requirements and full example.
How the flow works
1. Define the destination action
Choose the contract, function, beneficiary, funding token, and amount. Encode the call from an ABI you control. Treat the destination contract address as application configuration, not unrestricted user input.
2. Build the route with the call attached
Include hooks.postHook when building the route. Review the estimate for that complete request, not an earlier quote without the hook: the destination call adds execution requirements and can change gas costs or provider selection.
3. Authorize the source transaction
The source wallet or your signing infrastructure signs and broadcasts the route transaction. An ERC-20 source asset may require an approval first, so do not promise one wallet prompt for every flow.
The destination call is executed by the provider, without a separate destination-wallet signature from the user.
4. Track the route and verify the action
Follow the receipt and status flow for your integration. Once routing succeeds, check the destination contract to confirm that the intended action occurred for the correct recipient.
A route result alone is not proof of a credited vault deposit. The vault guide's verification step explains how to check contract state.
Native value and ERC-20 funding are different
The destination function determines how the call is funded.
| Destination function | Funding configuration |
|---|---|
| Accepts the chain's native asset | Attach native value; do not set toApprovalAddress. |
Pulls an ERC-20 with transferFrom |
Set the funding token and toApprovalAddress for the contract that pulls it; do not attach native value for that token funding. |
Destination funding is separate from source-token approval. A source approval authorizes the source-chain provider contract to spend the input asset. toApprovalAddress concerns funding the destination call; it is not another source-wallet prompt.
The destination call options reference explains both mechanisms.
What if the final amount is not known in advance?
For a predetermined destination amount, use fundAmount and ensure the route's minimum output covers it. If the encoded function also takes an amount, keep that argument consistent with the funding amount.
For amount patching, use fullAmount with amountInputPos to identify the static ABI argument that holds the amount. Do not also send fundAmount in this mode.
Patching behavior depends on the provider. Some providers patch at execution using the amount received; others use a quoted minimum or quoted output before the route is built. Do not describe every amount-patching route as using the final landed balance. Read the amount-patching reference before choosing the mode.
What happens if the destination call fails?
Routing value and executing the destination action are separate outcomes. Funds can move even when the intended contract call does not complete.
A fallback address can be supplied through toFallbackAddress, but support is provider dependent. It is not a universal recovery guarantee. Trustware also does not expose a separate destination-call status field, so inspect the destination transaction and relevant contract state before deciding what happened.
Build that distinction into both the interface and the support process. “Route completed” and “vault deposit credited” should not be treated as interchangeable evidence.
Frequently asked questions
Can I use a destination call for something other than a vault?
Yes. The documented pattern also covers destination contracts such as staking contracts, margin accounts, and lending pools. The function, funding requirements, beneficiary handling, and route compatibility still need to be checked for your integration.
Does Trustware sign the transaction for my application?
No. Your wallet or signing infrastructure authorizes the source transaction. The routing provider executes the supported destination call.
Are destination calls available through the widget?
No. Use the headless SDK or REST API. Neither the widget nor runTopUp() accepts hooks.
Does a fallback address guarantee recovery?
No. Fallback behavior depends on the provider that resolves the route. Do not build recovery logic on the assumption that every route supports it.
Build the complete flow
Start with the vault destination walkthrough, then use destination call options for ERC-20 funding, amount patching, and fallback behavior. For backend-controlled integrations, follow the REST API integration pattern.