Liquidswap liquidity position use and monitoring
Updated on
Liquidswap liquidity becomes usable when a provider can connect each deposit to its recorded position, current pool state and eventual withdrawal rights. On Aptos, that evidence differs by contract family. V0.5 curve pools issue LP coins for a proportional pool claim, while V1 assigns LB tokens to liquidity held in specific price bins. A practical routine therefore starts with the correct pool model, preserves the position tokens and confirms each state change on-chain. Monitoring then follows the evidence appropriate to that model, rather than relying on an estimated return or a stale interface view. The provider checks the committed on-chain state before deciding whether a failed transaction or changed pool condition calls for another transaction.
A usable position is confirmed by committed token records, then monitored against the pool state governing fees, composition and withdrawal.
Choose the position model before committing capital
A position is usable only when its contract family matches the intended monitoring and exit method. V0.5 curve pools use LP coins as proportional claims on pooled reserves. V1 uses LB tokens tied to a particular pool and bin. These records are not interchangeable, so the model chosen at deposit determines the proof needed for later management.
The provider selects the assets, authorizes the call, retains the position tokens and keeps access to future Aptos transactions. The router applies supplied minimums and, for V1, the permitted active-bin movement. Pool contracts perform the state transition, while Aptos records the committed outcome. A user interface may assemble a proposed transaction and read position data. The wallet signature and ledger record identify the action that actually occurred.
Pool identity deserves the same attention as the visible pair. V1 can distinguish pools by their asset types, pool identity and bin step. V0.5 also separates its stable and uncorrelated curve pools. A ticker pair without the corresponding contract details does not establish which position will receive the deposit.
What confirms a successful liquidity deposit?
A successful deposit has a committed transaction marked successful, new position evidence and balance changes consistent with the submitted call. A transaction hash only proves submission until the network commits an outcome. A closed wallet prompt or refreshed screen does not establish whether the liquidity call executed.
For V0.5, the resulting evidence is an LP coin balance associated with the selected curve pool. In V1, each LB token amount represents a liquidity share in a specific pool and bin. The account may receive several LB token records when liquidity spans several bins. The mint can also return input coins the chosen bins did not use.
Match the sender, contract family, pool identity and full asset types to the intended deposit. Then compare the input balance changes with the issued position tokens and any returned amounts. If the first call already committed, repeating it creates another state change. It does not repair or complete the earlier position.
V1 monitoring follows fixed bins and a moving active bin
Every V1 bin holds liquidity at its own price, while the active bin identifies the pool’s present price point. An existing LB token remains associated with its recorded bin as the active bin moves. Monitoring therefore compares held bin IDs with the active bin instead of expecting the position record itself to migrate.
In V1, liquidity earns swap fees only when its bin is used by swaps. A position outside the active trading path may remain valid without supporting the latest swaps. Trading through the selected bins can also change the position’s asset composition. If activity passes beyond the supplied range, the remaining liquidity may become concentrated in one of the two assets.
That state does not automatically require a transaction. The provider may retain the bins, redeem part or all of them or establish a separate range after reassessing the pool. Each change requires a new authorization. Merely viewing the position cannot reposition liquidity, alter its limits or move ownership.
How should a position check handle a shifted active bin?
When the active bin shifts, compare it with the desired bin and rebuild the transaction if the difference exceeds the configured tolerance. Assume a hypothetical V1 pool has desired active bin 8388608, nonzero allocations for bins 8388607 through 8388609 and a two-bin tolerance. The hypothetical X and Y quantities follow the pool’s side rules. The minimum accepted X and Y amounts and timing are hypothetical too. A final check before approval finds active bin 8388609, a one-bin move within tolerance.
The provider signs the router call, and the active bin remains 8388609 at execution. Because that value is one bin above the desired 8388608, the router shifts every target bin up by one. A successful commitment issues LB tokens for bins 8388608 through 8388610, and any unused X and Y coins return to the account. The provider stops after confirming the successful status, pool, asset types and adjusted bin IDs.
On a separate hypothetical attempt with the same desired bin and two-bin tolerance, the active bin moves from 8388608 to 8388611 after the transaction is built. That three-bin move exceeds the tolerance, so the router aborts the mint and creates no LB position. The provider reads the new active bin before rebuilding the range, tolerance and minimums. If the revised distribution no longer serves the intended price area, the provider stops without resubmitting.
Monitoring separates ownership from estimates
A durable monitoring record separates proof of ownership from the pool readings and estimates used to value the position. Four groups of data answer different questions:
- Position identity includes the contract family, full asset types, pool or collection identity and the V1 bin step.
- Ownership evidence is the account’s V0.5 LP coin balance or its V1 LB token amounts and bin IDs.
- Activity evidence includes the active bin, the held bins and swap use affecting those bins.
- Transaction evidence records committed success, emitted events, balance changes and gas used.
A dashboard value is a derived view, not a separate claim on pool assets. It may use delayed indexed data or a valuation assumption different from another interface. Those display differences do not alter the LP coins or LB tokens held by the account. Reading the same pool identity and account on each check avoids mixing unrelated positions.
Fee parameters, bin activity and asset composition can change after a screenshot or estimate was produced. A narrow group of V1 bins can leave the trading path as the active bin moves. A V0.5 position instead continues to represent its proportional curve-pool share. This difference determines which state change deserves attention.
Review the position when held bins leave active use or its token mix no longer fits the intended job. Estimated returns alone cannot prove fee accrual, ownership or withdrawal value. The provider decides whether the changed state warrants another signed transaction.
Withdrawal ownership and recovery boundaries
Withdrawal uses the position proof created by the corresponding contract family. V0.5 burns the appropriate LP coins to redeem the proportional pool assets. V1 burns selected LB tokens to release the associated liquidity and collected fees. Minimum X and Y output amounts can bound the V1 redemption; the call aborts when its actual outputs fall below those limits.
The redeemed mix follows the pool state at execution rather than the original deposit quantities. This matters after swaps change reserve proportions or consume liquidity across V1 bins. An estimate prepared earlier is not a reservation of either output asset.
A failed removal should be diagnosed from its committed status, VM result, pool identifiers, token ownership and supplied minimums before another signature. If the transaction succeeded but an interface has not refreshed, the account’s committed balance changes and remaining position-token balances show what was redeemed. Repeating a successful withdrawal attempt could redeem another share.
Control remains with the account holding the position proof. Moving LB tokens transfers the represented claim without withdrawing the underlying liquidity. Losing access to an account or sending position tokens to an unintended address is not reversed by the pool contract. Unless the transaction is sponsored, the acting account also needs APT for gas. Once a selected share is burned and its output balances are committed, that share has exited even if a stale interface still displays it.
Liquidswap liquidity: the short answers
May one V1 deposit spread liquidity across several bins?
Yes. A V1 liquidity call can provide a vector of bin IDs with separate X and Y allocations for those bins. A successful mint returns LB token amounts associated with the bins that accepted liquidity. The pool identity, bin step and individual bin IDs together distinguish the resulting position.
Can an integration call the V1 core pool instead of the router?
Yes, but the core pool does not provide the router’s slippage protections. A direct integration must implement its own checks around liquidity minting and burning. The router path carries minimum token amounts and active-bin movement limits into the call, allowing the transaction to abort when those boundaries are exceeded.
Why must V1 coin types be sorted before a liquidity call?
Liquidswap V1 requires coin generics in its canonical order, including at the router layer. A call with the types reversed can abort before changing the position. Integrations should derive the order from the complete Move types rather than their ticker symbols or their visual order in an interface.
Is one fixed APT reserve enough for every future withdrawal?
No fixed APT amount covers every future position action. Gas depends on the transaction and the network parameters applied when it executes. Unless a transaction is sponsored, the account must have enough APT to submit the later mint, partial removal or full withdrawal call.
Are V0.5 LP coins accepted by a V1 removal call?
No. V0.5 LP coins and V1 LB tokens are position proofs issued by different contract families. A V0.5 withdrawal burns the matching curve-pool LP coins, while a V1 removal burns LB tokens associated with particular bins. One proof cannot be substituted for the other.
How are two-sided inputs distributed across V1 bins?
Both X and Y can be supplied together at the active bin. Bins away from it accept only the asset allowed on their respective side of the active price. The distribution must follow the pool’s canonical X and Y ordering, and unused input amounts can return to the account after a successful mint.