Biswap
Biswap matches token and network choices with available trading routes
Biswap uses the chosen tokens and networks to request a route for an exchange. Exchanging different tokens on one chain uses same-chain liquidity. Selecting another destination chain requires bridge routing, with swaps where the path needs them. Availability also depends on the amount, liquidity, and route settings. A token appearing in a selector does not establish an executable route.
The desired asset and its destination network describe the intended receipt together. A familiar ticker on another network can represent a different token contract. The integrated routing provider’s quote identifies the proposed output and the execution requirements for delivering it.
Can I swap tokens without changing networks?
Yes. Tokens on the same supported network can use an available swap route without a cross-chain bridge. The routing engine still needs liquidity for the selected assets and amount. Moving the output to another network changes the request, even when the destination asset has a familiar name. A same-chain quote cannot establish delivery on that other network.
Source balances and token identities define the starting asset
The starting asset belongs to a particular network, so the selected source chain must match the balance available to the sending wallet. For contract-based tokens, the contract address identifies which asset the route spends. Symbols help navigation, while chain and contract details distinguish the actual token. Matching address strings on different networks do not establish interchangeable balances.
Connecting a wallet does not move assets between chains. A balance displayed under another network remains a different starting point for routing.
The destination token determines the requested output
Choosing a receiving network and a destination token specifies the requested output, including the asset’s identity on that chain. A bridge can transport an intermediate asset, and a destination swap can convert it into the requested token. Those functions can sit inside one proposed route. The asset the bridge moves therefore need not match the final asset shown in the quote.
Swap components and wallet transactions follow different boundaries
The number of operations in a route does not necessarily equal the number of transactions the wallet must sign.
A combined source transaction
A routing step can combine a source-chain swap and bridge action in one transaction. Token approval can add an earlier authorization transaction when the contract needs an allowance. Approval permits spending; the sending transaction triggers the route. These actions have different effects even when the interface groups them within one trading flow.
Destination execution
The selected path determines whether delivery includes a conversion or asks the wallet to execute a later swap.
Conversion within bridge delivery
The provider can allow a destination swap within the bridge’s destination transaction. Availability depends on the bridge and route. Permission to include destination calls does not establish that every proposed path will use one.
A separate destination swap
Some routes require another user-signed swap after bridging. That step uses the amount actually received and may need its own approval. It also requires the applicable gas for the destination-chain transaction.
From token selections to a route proposal
A route proposal applies to a particular source amount and a defined destination asset on a selected network. The choices describe the requested exchange before any authorization. Changing an asset, amount, or network calls for another quote.
| Selection stage | Effect on the route | Required input or condition |
|---|---|---|
| Match the source asset | Identifies the token and chain supplying the exchange. | The sending wallet’s balance and its network. |
| Define the destination | Sets the requested output token and receiving chain. | The exact asset and network intended for receipt. |
| Set the input amount | Defines the quantity the router must price. | Source-token units and the intended quantity. |
| Obtain a quote | Returns a proposed path when routing constraints allow one. | Complete selections and sufficient route liquidity. |
| Inspect proposed actions | Identifies combined operations and any separate destination swap. | A returned proposal with its execution requirements. |
| Keep or revise the selection | Retains a matching proposal or requests a quote for changed inputs. | Acceptable output, charges, and required wallet actions. |
| Before authorization | The proposal describes a path for the defined request. | It does not establish transaction execution or delivery. |
A proposal ending with the bridged asset fits an intended receipt of that asset. A request for a different destination token requires a path producing that token, possibly through a final swap.
A supported connection differs from a priced route
A supported connection describes a possible path, while a quote evaluates the requested amount against current liquidity and routing constraints. The provider can list connected chains and tokens without returning a usable quote for a particular request.
Insufficient liquidity, temporary bridge or exchange unavailability, and amount restrictions can prevent a quote. Wallet or contract limitations can also matter. Changing the amount may change availability because the exchanges and bridges must support that quantity. A missing quote therefore does not establish that the token has no supported connections.
Price-impact thresholds can also hide routes. Widening slippage tolerance addresses a different constraint and cannot create liquidity or restore an unavailable bridge.
An intermediate asset can differ from the requested output
A cross-chain route can return the bridged asset when its final destination swap cannot execute within the allowed conditions. Insufficient liquidity or price movement beyond the permitted slippage can cause this outcome. Bridge delivery can therefore complete without producing the exact destination token originally selected.
In the provider’s status system, DONE with the substatus PARTIAL calls for reading the actual destination outcome. For a failed final conversion, it can indicate receipt of the bridged asset. Other route-specific partial outcomes exist, so the label alone does not identify the received token or amount. Confirming the source transaction does not, by itself, establish which asset arrived on the destination chain.
Earlier pools and legacy balances have separate roles
Earlier V3 exchange deployments included BNB Smart Chain, Ethereum, Base, and Arbitrum. These were networks hosting the AMM’s liquidity pools. Cross-chain route coverage follows the integrated router’s supported exchanges and bridges, with availability determined for the particular request.
The older earning and governance products closed during the platform’s shift toward trading. A consolidated withdrawal interface covers remaining V2 liquidity, V3 positions, and BSW Investment Pool assets. A legacy position remains distinct from spendable wallet tokens. For a legacy balance, withdrawal is the relevant operation; a swap quote addresses tokens available for a new exchange.
Questions and answers about Biswap
Can a Biswap route use different sending and receiving addresses?
The routing API accepts a destination address separate from the sending address. A quote request defaults to the sending address if it omits a recipient. The destination address must fit the receiving network. Choosing a different recipient in Biswap also requires the interface to expose that control.
When can a native coin avoid source-token approval?
On Ethereum Virtual Machine (EVM) networks, a native source asset does not require an ERC-20 spending approval. The sending transaction still initiates the route. A path with a manual destination swap can have separate authorization requirements after arrival, so the source-side exception does not remove every possible wallet action.
Are raw quote amounts already expressed as whole tokens?
Raw amounts in the routing API use each asset’s smallest units. The token’s decimal precision converts that integer into a readable token quantity. Comparing raw source and destination integers without their separate decimals can misstate the exchange rate. Read the displayed input and output in their respective token units.
Does disabling destination calls exclude all destination swaps?
Disabling destination calls in the provider’s API prevents swaps or other contract calls inside the bridge’s destination transaction. It does not disable separate swap transactions on the destination chain. The setting controls one execution method, so its effect differs from excluding every route containing a destination swap.
Which route filters can remove an otherwise supported path?
The routing API can restrict the bridges and exchanges eligible for a request. Excluding a tool can remove paths relying on it, even when the selected tokens and networks are generally supported. These provider-level configuration options are distinct from market liquidity, which can block a quote without any tool exclusion.
Is destination gas automatically included with the selected output token?
Gas provision depends on the route and the asset received. A receipt of the destination chain’s gas asset can fund later transactions. For other outputs, the routing API has a separate option requesting conversion of a specified token amount into destination gas. Selecting an output token alone does not establish that conversion will occur.
How can a wallet’s Solana transaction support affect a route?
The routing API accepts the maximum Solana transaction version the client can sign. Its transaction response identifies the version actually built, which may be lower than the requested maximum. The setting applies only when Solana is the source chain. It does not govern transactions sourced from other networks.
Last updated ·