Skip to content
ChainBrief

News from across Web3

Source or destination swap: what should integrators support?

Source swaps convert before bridging; destination swaps convert after. Integrators should support both when routes require them and rank by net output and execution risk.

The ChainBrief Editors

Source or destination swap: what should integrators support?

In a cross-chain swap, integrators choose whether to convert the user’s token before the bridge leg or after it; the route should follow available liquidity and the asset the bridge accepts. A source swap converts on the origin chain, while a destination swap converts on the receiving chain.

Supporting both lets an integrator cover more token pairs, but the useful choice is the route with the strongest net outcome and a clear completion path.

What happens in a source swap?

A source swap trades the input token on its origin chain into an asset the bridge route can carry, then transfers that asset across. It fits when the user’s token is not accepted by the bridge or when origin-chain liquidity makes conversion there preferable. The transaction can be submitted as one user flow, though execution still depends on multiple steps completing.

This pattern can narrow the bridge leg to assets with broad support, but it adds a source-side trade: its fees and price impact reduce the amount entering the bridge. A route that looks efficient by bridge fee alone may therefore deliver less after the initial conversion. A fuller discussion of ParaSwap’s source and destination swap trade-offs covers the routing decision in more detail; the key integration question is where conversion produces the better end-to-end result.

When does a destination swap fit better?

A destination swap bridges an intermediate asset first, then trades it into the user’s requested token after arrival. It suits routes where the bridge supports the intermediate asset and destination-chain liquidity can provide the final conversion. The user can specify the desired output token without needing to hold the bridge asset themselves.

The trade-off is that final delivery depends on destination-side execution. Integrators need to account for destination liquidity, the conversion’s price impact and the route’s handling if that step cannot complete as quoted. A displayed output should reflect the final token amount after fees and conversion, rather than presenting the bridge arrival amount as if it were the user’s result.

How should integrators compare the routes?

Compare complete routes against the same input amount and requested output. Include the source trade, bridge costs, destination trade where applicable, and any chain gas the user must supply. Ranking by the intermediate asset amount can select a route that looks better before its last conversion but delivers less value at the destination.

  • Compare estimated destination output after route fees and price impact.
  • Show which chain pays gas and which token arrives at each stage.
  • Set output minimums and expose the route’s completion status.

For the interface, keep the user’s intent stable: source token, destination chain and desired output token. The routing layer can select source conversion, destination conversion or both, while the quote explains the steps that choice entails.

Which swap should an integrator choose?

Neither location is a universal default. Source swaps fit when the bridge needs a different input asset or origin liquidity is better; destination swaps fit when the bridge can carry the input and the final token is better sourced after arrival. Some routes require both.

For most integrations, supporting both is the practical choice if the system can compare them and report failures clearly. Where only one path is available, expose its final output and execution assumptions before the user signs. The better route is the one that completes the requested conversion with the strongest net output and a defined recovery path if a later step fails.