Paraswap’s cross-chain model is an intent-settlement flow, not a conventional lock-and-mint bridge. That distinction matters when you are moving value between EVM networks: the route can deliver the token you actually want on the destination chain, while a traditional bridge usually moves a particular token representation and leaves the swap for later.

The useful way to think about Paraswap in 2026 is as execution infrastructure around the transfer, not as a new canonical asset issuer. Its Delta-style cross-chain orders let a user specify the source asset, destination network, desired output asset, recipient, and minimum acceptable result. Settlement agents compete to fulfill that order. The bridge component, destination liquidity, execution costs, and price protection are therefore parts of one quoted outcome rather than three separate transactions a user has to assemble.

Lock-and-mint is collateral accounting

Lock-and-mint transfers lock the canonical asset on the source chain and mint a corresponding representation on the destination chain. A user depositing an ERC-20 from Ethereum into a bridge contract does not make the original tokens disappear; they remain escrowed. The destination contract creates a bridged version whose supply is intended to match that locked collateral.

The reverse trip is burn-and-release. The bridged token is burned on the destination chain, a message or proof establishes that burn on the source chain, and the original collateral is released. Polygon PoS makes this pattern especially concrete: a withdrawal burns the child token on Polygon, then the withdrawal is finalized through the checkpoint and exit process before the Ethereum-side asset can be released.

These are not really rival mechanisms for the same direction. They are the two accounting legs of a collateral-backed bridge. Calling a Polygon-to-Ethereum withdrawal “burn-and-release” tells you something important: the asset you hold on Polygon is a representation that must be retired before the locked Ethereum asset can come back.

Why the distinction changes the Paraswap route

A conventional bridge transfer asks, “Which version of this token can I carry across?” A cross-chain intent asks, “What should arrive for this wallet?” That is a better question when the goal is to use liquidity on the other side.

For example, suppose you hold USDC on Ethereum and want WETH on Polygon. A lock-and-mint path may first produce a particular bridged USDC representation on Polygon, after which you still need a Polygon swap. That representation may have shallower liquidity than native USDC, and the final trade can be worse than the bridge quote suggested. Curve Finance can be excellent for a local stablecoin conversion where the relevant pool is deep, but Curve is not the mechanism that proves a cross-chain deposit or releases source-chain collateral.

A Paraswap cross-chain order can instead price the full objective: source USDC in, Polygon WETH out. The settlement route may use a bridge, a market maker, destination liquidity, or a combination. The important user-facing control is the stated output and minimum received amount, not an assumption that every transfer involves minting a wrapped token.

Use Paraswap when the supported source-and-destination pair can quote the asset you want to receive.

What it works with—and what it will not take

Paraswap’s cross-chain flow is EVM-focused and route-dependent. Support is determined by the selected source chain, destination chain, and token addresses, not by a token ticker alone. Ethereum, Polygon, Arbitrum, Optimism, Base, BNB Chain, Avalanche, and Gnosis are examples of networks in its wider execution environment, but a network being available for swaps does not mean every asset can be sent to every other network.

It will not turn an arbitrary ERC-20 into a bridgeable asset merely because that token has a pool somewhere. It also will not accept non-EVM assets such as native Bitcoin or Solana tokens, substitute one USDC contract for another without a supported route, or make an unsupported destination token appear by wrapping it. Check the quoted token contract, not just the symbol: native USDC, older bridged USDC variants, and wrapped ETH are economically familiar but technically different assets.

Hop Protocol illustrates the narrower bridge model well. It supports defined assets and chain combinations, using bridge-specific liquidity and representations to make supported transfers faster. That can be the right tool when its supported asset is exactly what you need. It is not a universal answer for long-tail tokens, nor does it eliminate the need to inspect the destination asset you receive.

The decision that actually matters

Choose a canonical lock-and-mint route when preserving the canonical bridge relationship is the priority and you are comfortable with its finality path. Choose a Paraswap cross-chain order when the practical objective is a specific spendable asset on the destination chain and the quote covers that pair. Compare the final output, minimum received amount, expected settlement conditions, token contract, and destination gas situation—not just the displayed bridge fee.

The edge case worth catching is a successful transfer that leaves you unable to transact. Receiving USDC on Polygon without POL for a follow-up transaction, or receiving a thinly traded wrapped variant instead of the asset your target protocol accepts, is operationally different from receiving usable funds. Before signing, confirm the recipient address, destination token contract, and whether the route includes any gas abstraction or whether you must pre-fund the destination wallet.

FAQ

Does a cross-chain Paraswap order always mint a bridged token?

No. The order describes a desired outcome; the settlement path can use bridge mechanisms and destination liquidity without making the user manage an intermediate bridged representation.

Is burn-and-release safer than lock-and-mint?

They are usually complementary stages of the same collateral-backed bridge. The relevant security question is which contracts, message-validation system, and finality assumptions secure that bridge.

Can I use any token supported by a local Paraswap swap?

No. Local swap support and cross-chain support are separate. The source-to-destination quote must explicitly support both the source asset and the destination token address.