Biswap
Biswap limit orders in the one-way V3 liquidity model
Biswap limit orders used one-way V3 liquidity to exchange tokens under a selected price condition. Filled amounts stayed converted when prices reversed, while volatility could leave part of an order unfilled. The design offered a 0% trading fee and limited orders to pairs available in its automated market maker, or AMM. An AMM used pool liquidity and mathematical pricing rules to exchange tokens. Order placement, partial execution, and collection described different states of the same trade. Biswap later shifted its main interface toward cross-chain trading, so the original placement controls belonged to a different interface from the later legacy withdrawal tools.
Contents
In short: The V3 design kept filled amounts converted after price reversals, while unfilled input remained a separate part of the order.
Pool liquidity and order liquidity contributed differently to execution
The V3 AMM combined concentrated pool liquidity with one-off order liquidity, connecting the market’s available tokens to two different purposes: ongoing liquidity provision and a selected token conversion.
Liquidity within a price interval
Concentrated liquidity meant allocating tokens to a chosen price interval. A regular pool position participated while its range matched trading prices. Its trading-fee income depended on activity and its share of active liquidity. Those properties described liquidity pools; they did not turn every pool position into a limit order.
Price terms and order quantity
A limit order specified the desired conversion through a selected pair, price, and quantity. Selecting the pair identified the input and output tokens. Price governed eligibility for execution, while quantity bounded the amount the order sought to convert.
A range also contained multiple possible execution prices. Its upper boundary did not automatically equal the average price received across a sale. The average reflected the execution prices for the filled portion.
One-way conversion preserved filled tokens after reversals
Filled V3 limit-order amounts stayed in the received token when the market price reversed. Reusable range liquidity could exchange tokens back as trading retraced the interval. The one-way order mechanism preserved the completed conversion, so its owner did not need to withdraw immediately to prevent that reversal.
Order setup preceded execution and collection
The original V3 workflow linked wallet access, token permission, and order creation before market execution, with collection following conversion. These were process stages, not a fixed count of wallet transactions.
| Stage | What happened | V3 order conditions |
|---|---|---|
| Wallet connection | The owner connected a wallet and opened Limit. | The V3 order interface. |
| Pair selection | The order identified the tokens to exchange. | A trading pair available in the V3 AMM. |
| Price and quantity | The order specified conversion terms and requested size. | The selected pair and intended trade direction. |
| Token approval | The wallet authorized the required token use. | Approval covered the relevant assets, without establishing a fill. |
| Order creation | The created order appeared in My Orders for status review. | Placement alone did not establish market execution. |
| Market execution | Eligible trading converted the filled amount. | The price condition applied; execution could remain partial. |
| Collection | The owner withdrew the converted output. | Proceeds represented the filled portion. |
Why could reaching the price condition leave an order partly unfilled?
Volatility could leave only part of the requested quantity converted, so reaching a chosen price condition did not establish full execution of the order.
The converted portion
A partial fill represented a completed exchange of some input tokens. The original requested size could therefore exceed the amount actually converted, even though the order had already participated in trading.
The remaining input
The unfilled portion retained its identity as input. A chart showing the target price could not establish how much of the order had filled.
Input and output quantities also used different token units. Adding their raw amounts did not produce a meaningful total token balance. A partially executed order required keeping the remaining input quantity separate from the received output quantity.
The zero trading fee covered the exchange charge
The V3 order design offered a 0% trading fee, separate from the fee tiers applicable to regular swaps and the network cost of blockchain transactions.
Gas paid for processing onchain transactions. Token approval, order placement, and withdrawal required gas whenever they involved a blockchain transaction. The network determined that cost independently of the advertised exchange charge.
The no-slippage description concerned the order’s price terms. Slippage means execution-price movement relative to expected terms. Choosing a price condition still left execution dependent on market activity, and a partial fill remained possible. Price control did not supply an all-or-nothing execution rule.
Available V3 pairs bounded the order market
Only trading pairs available in the V3 AMM belonged to this limit-order model. Cross-chain routing later connected exchanges and bridges under different conditions. An asset appearing in a routed-swap selector did not establish a V3 limit-order market for that asset. The pair requirement applied before the price and quantity settings could describe an eligible order.
Later interface changes affected access to legacy holdings
Biswap later refocused its main trading interface on cross-chain swaps and introduced dedicated tools for legacy withdrawals. Those tools handled existing holdings, a different task from placing new orders with the original V3 controls.
An initial withdrawal tool targeted V3 liquidity. A later consolidated interface listed V2 liquidity, V3 positions, and Investment Pool assets. A pool position and a limit order remained different records, even when both involved V3. Access to these withdrawal tools does not establish current access to the original order-placement controls.
Things people ask
Did V3 limit-order trades contribute to Biswap’s total trading volume?
V3 limit-order trades contributed to Biswap’s total trading volume alongside Exchange activity.
Was a V3 AMM limit order the same as a perpetual futures order?
A V3 AMM limit order exchanged tokens, while a perpetual futures order belonged to a separate derivatives product. Margin, leverage, and reduce-only controls described that other trading context.
Could an earlier V3 contract upgrade stop an existing limit order from executing?
Superseded AMM V3 contracts stopped executing limit orders during an earlier upgrade. That restriction applied to the replaced deployment. It did not establish the status of every V3 contract, and the V3 label alone did not distinguish retired contracts from their replacements.
Would retaining the received token preserve its purchase value?
Retaining a filled order’s received token did not preserve that token’s market value. One-way execution prevented reverse conversion through the order mechanism. It provided no fixed resale price or protection against later price movements in the asset received.
Which networks formed Biswap V3’s protocol scope?
Biswap V3’s protocol scope included BNB Smart Chain, Ethereum, Base, and Arbitrum. That list described protocol deployments. A particular limit order still required an available V3 AMM pair in its own deployment; the network list did not establish identical markets everywhere.
Last updated ·