Liquidity-fill routes deliver destination tokens from a solver’s inventory, while lock-and-mint routes release or issue a representation after cross-chain verification. Choose by the asset you need on arrival, the route’s quoted output and fill time, and whether you accept solver liquidity risk or a longer verification path.
Lock-and-mint routes preserve a bridge’s asset mapping
A lock-and-mint route escrows tokens on the source chain and releases corresponding tokens on the destination, or burns a representation there when funds return. It suits assets with a reliable, recognized mapping across both networks, and can avoid relying on a market maker to hold the destination asset. It does not fit when the token representation is unsupported or the destination needs a different asset.
If you need the transaction sequence and fields for a how fermi swap lock-and-mint routes work, that guide covers the route itself. Here, the choice is whether that route’s settlement model makes sense for your transfer: check the destination token’s contract or mint, the minimum and maximum amount, and the route’s expected completion time before signing.
The key trade-off is settlement dependency. A lock-and-mint transfer waits on source-chain finality and the bridge’s verification or message delivery before destination release; delays or failed delivery can leave funds pending until the protocol’s retry, recovery, or refund path completes. Use this type when receiving the mapped representation matters more than receiving a liquid substitute quickly.
Liquidity-backed fills trade inventory for speed
A liquidity-backed route uses a solver or relayer to pay the destination recipient from funds it already controls, then settles its claim against the source deposit later. This suits time-sensitive transfers and routes that need a swap into another destination token; it is less suitable if that route has thin inventory, a poor quote, or strict amount limits.
Across illustrates the relayer model: the user deposits an intent, a relayer calls the destination fill using its own tokens, then a settlement process validates fills and repays relayers. deBridge’s DLN uses a related solver model with a different order lifecycle: a solver fulfills the requested destination amount, sends an unlock message, and claims the source assets. These are distinct mechanisms, so compare the actual route rather than treating “solver” as one uniform guarantee. Across’s intent lifecycle and deBridge’s protocol overview describe those flows.
For an Across quote, compare the output after fees, expectedFillTime, minOutputAmount, and route limits. Its fee total can include relayer gas and capital costs plus an LP fee shaped by pool utilization and repayment location; values move with conditions, so query again immediately before signing. Most fills are designed to be fast, but an estimate is not a deadline. Across documents the fee components and quote fields.
- Output amount: compare the destination amount after all route and swap fees.
- Minimum output: set the least you will accept; reject a quote below it.
- Expected fill time: treat it as an estimate, not a settlement guarantee.
- Amount limits: check minimums and maximums for the selected route.
Native burn-and-mint routes fit USDC transfers
For USDC, Circle’s CCTP burns native USDC on the source chain and mints native USDC on the destination after an attestation. It suits transfers where native USDC status matters and both chains support the chosen CCTP path; it does not handle arbitrary tokens or remove the wait for verification.
This differs from a wrapped-token bridge: there is no destination pool of already minted USDC being paid out against a later source claim. The transfer depends on the burn being finalized and the attestation and destination mint completing. Fast paths, where available, can shorten the wait but introduce their own capacity and fee constraints. Verify the supported chains, transfer mode, and current fee in the interface you use. Circle’s CCTP documentation describes the protocol and supported transfer flows.
Compare complete routes with the same transfer
Suppose you want to move 1,000 USDC from Arbitrum to Solana and arrive with spendable native USDC. A lock-and-mint option is relevant only if its destination token is the representation you intend to hold. A liquidity-backed route may deliver sooner, while CCTP can preserve native USDC status; compare live quotes for the exact source amount, recipient, and destination asset before choosing.
On each quote, check token identity as well as ticker, since “USDC” alone does not establish that two contracts or mints represent the same asset. For a swap route, include the destination swap’s price impact and slippage floor in the output comparison. A failed fill, insufficient liquidity, expired quote, unsupported recipient format, or mismatched token decimals can change execution or trigger a refund path. The same checks apply when a fermi swap route is among your options: compare its final destination asset and executable output, not only the displayed bridge fee.
My practical rule is to decide the required destination asset first, then compare fresh quotes for that exact asset and amount. If two routes are close, choose the one whose token mapping and failure recovery you can verify on-chain.