> For the complete documentation index, see [llms.txt](https://defi-handbook.gitbook.io/defi-handbook-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://defi-handbook.gitbook.io/defi-handbook-docs/what-is-biswap-and-which-route-type-fits-your-app.md). # What is Biswap and which route type fits your app? Biswap is a cross-chain bridge and swap service, and three route patterns frame an integrator’s decision: canonical bridging, liquidity transfer, and cross-chain swapping. The user may want the same asset elsewhere, faster access to it, or a different destination asset. One request still produces source and destination transactions with separate finality. * Choose by destination asset, settlement model, and liquidity. * Track the two chain transactions as one asynchronous order. * Validate the exact asset and recipient before funding. ### What are the main Biswap route types? The options to distinguish are a canonical bridge, a liquidity-backed transfer, and a cross-chain swap. Ethereum.org’s developer bridge documentation describes lock-and-mint, burn-and-mint, and atomic-swap mechanisms. Those describe how value moves; the options below describe the result your app needs. * **Canonical bridge — same asset, canonical representation.** A source contract escrows tokens; a verified message causes the destination contract to issue or release the corresponding asset. It fits an Ethereum-to-Arbitrum deposit where provenance matters. It does not fit a request for a different output token, and an optimistic rollup exit can take days. * **Liquidity-backed transfer — same asset, earlier payout.** A provider advances destination inventory and later settles the source leg. It fits a time-sensitive transfer with sufficient pool depth. It fails when inventory cannot cover the amount; its spread and counterparty assumptions differ from a canonical withdrawal. * **Cross-chain swap — different asset or network in one order.** The route joins transfer with exchange into the requested output, sometimes through an intermediate asset. It fits a user holding BTC who needs ETH on an L2. It fits poorly when the destination market is thin or exact output must be guaranteed before source confirmation. ### How does a cross-chain swap settle? A cross-chain swap settles through a source payment, a bridge message or liquidity fill, and a destination payout or trade. The route defines when the source leg counts as settled, though a liquidity provider may advance funds earlier. The legs are not automatically atomic: source confirmation does not prove destination delivery. For example, a wallet holding BTC on Bitcoin may need ETH on Arbitrum; that pair must be available when quoted. When it is, use [Biswap](https://biswap.uk) to move the BTC across networks and swap into ETH in one flow. A Biswap cross-chain swap still requires the app to record the Bitcoin transaction ID and verify the Arbitrum receipt separately. A Bitcoin deposit can confirm while destination liquidity disappears or a quote expires. The route may delay the fill or refund the source asset; learn its recovery policy before funding. Key the order to a stable request ID so retrying after a slow receipt cannot create a second funded order. ### What determines cost and delivery time? Cost combines source fees, bridge or liquidity fees, destination gas, and exchange spread or price impact. Compare net destination amounts, not headline bridge fees. Say a quote returns 0.40 ETH with 0.5% slippage tolerance: the minimum is 0.398 ETH, while Bitcoin miner fees are additional. That minimum protects the output only if the route enforces it; it does not cap refund costs. Time depends on source confirmations, message verification or available inventory, and destination finality. Arbitrum’s official bridge documentation says a native withdrawal from Arbitrum One to Ethereum takes at least seven days. A liquidity provider can pay earlier, but this changes the trust and fee model; a low Bitcoin fee rate can leave the source unconfirmed past quote expiry. Biswap supported networks span Bitcoin, Ethereum, BNB Chain, Solana, and major L2s, but network coverage is only the first route filter. Check the exact asset pair and amount at quote time: a network can be available while one pair has no executable path. On Solana, distinguish the wallet address from the token account for the requested mint, and establish who funds account creation if it is absent. ### How should an integrator execute the route? Implement an order that advances only when the corresponding chain evidence appears. Store the quote, source transaction, and destination transaction separately so a timeout cannot be mistaken for a failed transfer. 1. Identify the networks unambiguously, using EVM chain IDs 1 and 42161 for Ethereum and Arbitrum where applicable. 2. Resolve each token to its contract address or mint rather than relying on a shared ticker. 3. Capture a quote for the exact amount and recipient, including expiry, net output, fees, and minimum received. 4. Validate the destination address and any required Solana token account for the chosen mint. 5. Submit the source transaction once under the app’s idempotency key. 6. Persist its transaction ID against the order as soon as the network accepts it. 7. Reconcile the destination receipt against the expected chain, asset, recipient, and minimum output. Start with a small route for the pair your app needs, then exercise an expired quote and delayed source confirmation. Your order states must distinguish unfunded, funded but awaiting fill, and delivered; that distinction determines when a user can safely retry. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://defi-handbook.gitbook.io/defi-handbook-docs/what-is-biswap-and-which-route-type-fits-your-app.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.