ParaSwap connects two blockchains in one flow, moving an asset and, when needed, swapping it into a token on the destination chain. To deliver a chosen destination token, ParaSwap combines bridging and swapping for the user. A ParaSwap BTC to ETH request still depends on an available route and its quoted terms.
For an integration, three points matter most:
-
Identify assets by chain and token, not ticker alone.
-
Check the amount expected on the destination chain after every fee and swap.
-
Track delivery separately from confirmation of the source transaction.
What is ParaSwap used for?
It is used to move value between blockchains and, when needed, change the asset the recipient receives. An app might let someone start with ETH on Arbitrum and request USDC on BNB Smart Chain. If a route is available, the intended result is USDC on BNB Smart Chain, rather than an ETH balance that needs another swap.
For an integrator, the source asset and destination asset are separate choices. Native BTC on Bitcoin and wrapped BTC on an EVM chain are different inputs, even when an interface labels both “BTC.” Store the chain and token identifier together; a matching ticker does not establish that a route supports either asset.
How do I bridge crypto?
To bridge crypto, choose the asset and amount on the source chain, the destination chain, and the recipient, then submit the source transfer for an available route. That transfer starts a process whose destination delivery happens later. Ethereum.org describes lock-and-mint and burn-and-mint as common bridge mechanisms; other routes deliver assets from liquidity already held on the destination chain.
For a ParaSwap bridge route, make each input unambiguous before the user commits funds. Check the following as one route request:
-
Source network and asset, including whether the asset is native or a token.
-
Destination network and the asset the recipient expects.
-
Recipient address in the destination chain’s format.
-
Amount to send and the minimum acceptable destination amount.
After submission, retain the source transaction hash and follow the transfer through destination settlement. A source-chain confirmation proves that the first transaction landed; it does not prove that the recipient has the requested asset. Your app should report the destination result only when that leg completes.
How can I swap tokens across blockchains?
Choose the token to spend and the token to receive on the destination chain; the route determines which transfers and swaps connect them. It may first swap into an asset the bridge can carry, deliver that asset, and swap again on arrival. Think of a connecting train trip: one itinerary covers the journey, but the transfer between trains remains a separate event.
Say a user starts with 1 ETH on Arbitrum and wants USDC on BNB Smart Chain. The route might bridge an intermediate asset before a swap on BNB Smart Chain produces USDC; ETH itself need not cross the bridge. For a ParaSwap Solana swap, validate the Solana token mint and recipient address using Solana’s rules rather than treating them as EVM token and wallet addresses.
What determines the amount and completion time?
The received amount reflects the source network fee, bridge or relayer charge, destination execution costs, swap fees, and price impact. Compare quotes by the expected and minimum amount of the destination asset. For example, a 50 basis point slippage limit is 0.5%: on a $1,000-equivalent quoted output, that is around $5 of permitted execution drift, apart from separately charged network fees.
Time depends on source-chain finality, the bridge’s verification or liquidity model, and execution on the destination chain. Ethereum.org notes that a canonical optimistic-rollup withdrawal to Ethereum can take roughly seven days; a liquidity-backed route may deliver sooner under different settlement assumptions. I would compare the delivered amount, route model, and expected arrival time together, then use a fresh quote when the user is ready to submit.
What should an integrator handle after submission?
Treat a cross-chain transfer as several states rather than one atomic transaction. Record the chosen chains and assets, recipient, quote expiry, minimum output, source transaction hash, and any route or destination identifier available. Show source confirmation, bridge progress, and destination receipt separately so a pending transfer does not appear complete.
Plan for a destination swap that fails after the bridge leg succeeds. Depending on the route, value may remain as an intermediate asset or require a recovery action; report what actually arrived and on which chain. If the user must sign another transaction, they may also need that chain’s native asset for its network fee.
In practice, build the flow around these steps:
-
Validate the chain, asset, amount, and destination address.
-
Review a current route’s expected output, minimum output, cost, and timing.
-
Track both chains until the requested destination asset arrives or a recoverable state is clear.