If you are integrating liquidity withdrawals, track fees using the pool’s accounting model and the position’s share, because fees can accrue between transactions without a separate claim. The first job is to identify whether a pool keeps fees in its reserves or records them separately; the withdrawal calculation depends on that distinction.
Where do pool fees accrue?
In a constant-product pool that keeps swap fees in its reserves, each trade leaves some value in the pool for liquidity providers. A provider’s share is represented by its fraction of the pool’s liquidity tokens, so the accumulated value is reflected in the reserves when the position is withdrawn.
If you are integrating a v2-style pool on Biswap DEX, first confirm that the specific pool uses this model and read its fee settings from the deployed contracts. Biswap is a useful context for this check because a DEX can expose different pools and services; do not infer one pool’s fee behavior from the product name alone.
Other designs account for fees separately. In a concentrated-liquidity pool, for example, fee growth may be tracked per token and per position; reducing liquidity and collecting owed fees can be separate actions. An adapter that assumes every withdrawal includes every fee can therefore undercount a position’s claim.
How does a reserve-based withdrawal include fees?
For a reserve-based pool, a withdrawal pays the position’s pro-rata share of each reserve at the time the transaction executes. If the position owns fraction s of the pool, the gross amounts are approximately s × reserve0 and s × reserve1, subject to the contract’s integer rounding and any pool-specific rules.
For example, suppose a pool starts with 10,000 A and 20,000 B, and a swap adds 100 A while taking out about 197.43 B at an illustrative 0.30% fee. The pool ends near 10,100 A and 19,802.57 B. A provider who owns 1% at withdrawal receives roughly 101 A and 198.03 B before rounding, rather than the original 1% of the starting reserves.
That change is not a clean fee total: the trade also changes the pool’s token mix and market price. To estimate fees alone, compare the position against a counterfactual with the same trades but no fees, and value both token balances at the same external price. The result depends on the pool’s fee split, trade path, and price movement.
What should an integration measure?
Measure the amount a position can actually withdraw, and keep fee attribution as a separate calculation. On a reserve-based pool, read reserves and total liquidity supply at a consistent block, then calculate the provider’s share using the pool’s actual withdrawal rules. On a position-based pool, read the position’s liquidity, fee-growth checkpoints, and tokens owed according to that implementation.
Biswap integrations should also distinguish gross pool fees from protocol fees, if the pool diverts part of each swap. A displayed swap fee rate may describe what the trader pays, not what liquidity providers retain. Check the contract’s fee parameters and fee destination rather than treating the quoted rate as the provider’s net yield.
How do you implement the withdrawal check?
Use this sequence before showing an estimated withdrawal or recording realized fees:
- Identify the pool contract. Resolve the chain, pair, and pool address from the supported deployment registry.
- Read the accounting model. Determine whether fees remain in reserves or accrue to position-level fee counters.
- Fetch one consistent snapshot. Read reserves, supply, position liquidity, and fee checkpoints at the same block number.
- Calculate the gross claim. Apply the pool’s withdrawal formula and integer rounding to estimate token amounts.
- Separate estimated fees from other changes. Compare against a clearly defined baseline and use the same external prices for both values.
- Simulate the actual transaction. Include any separate collect call, minimum-output settings, transfer behavior, and gas cost in the user-facing result.
A useful edge case is a token that charges a transfer fee or rebases balances. The amount sent by the pool may then differ from the amount received, or the reported balance may shift without a swap. For such assets, base estimates on the pool’s verified token behavior and transaction simulation; reserve arithmetic alone may mislead.
Questions integrators ask next
Are LP fees the same as impermanent loss?
No. Fees are value retained or credited by the pool under its fee rules, while impermanent loss describes how a liquidity position’s value differs from simply holding its deposited assets as prices move. A position can earn fees and still underperform that hold-only comparison. Report fee revenue and price-driven performance separately.
When should an integration update its fee estimate?
Update the estimate whenever the user changes the pool, position size, or withdrawal block. For a live display, refresh the underlying state at a recent block and label the result as an estimate until the withdrawal confirms. For historical reporting, use the transaction’s execution block and actual token transfers to record realized amounts.
Does withdrawing liquidity automatically collect fees?
It depends on the pool contract. In reserve-based designs, the withdrawal normally returns a share of current reserves, which already reflect retained fees. In position-based designs, fees may be tracked separately and require a collect operation. Verify the specific contract’s behavior before presenting one combined “withdraw” amount.
Your next step is to write a pool-specific accounting adapter, then validate its estimate against a simulated withdrawal at the same block. Treat Biswap pools according to their deployed contracts and fee rules, and expose separate figures for withdrawable tokens and estimated fee contribution.
Top comments (0)