Liquidswap applies pool-specific liquidity rules to Aptos swaps and liquidity positions

Swaps and liquidity positions serve different purposes

A swap changes one Aptos asset into another through liquidity already held by a selected pool. The input increases one side of that pool while the contract calculates the available output from its pricing model. The trader pays the applicable pool fee and accepts only an output meeting the transaction’s minimum-output condition.

Liquidity provision creates a different commitment. A provider deposits assets into a curve pool or selected V1 bins and receives an on-chain position record. Trading activity can generate fees for eligible liquidity, yet swaps also change the position’s asset composition. Removing liquidity later returns assets according to the pool state and the position owned at that time, not necessarily the original quantities.

What must align before a Liquidswap transaction can proceed?

The wallet network, asset identifiers, contract family and transaction limits must all match the intended operation.

Before any of that matters, the account needs the input assets and enough balance for the Aptos network fee. A familiar ticker does not prove asset identity because separate assets can display the same symbol. The on-chain type or other asset identifier determines which contract resource the transaction will use.

Pool compatibility comes next. The chosen pair must exist under the selected version and pool design. A V0.5 operation also depends on the stable or uncorrelated curve. A V1 operation depends on a particular bin step and the liquidity available around its active bin. Sparse liquidity can reduce the obtainable output or leave a requested amount unavailable under the chosen limit.

The signed transaction payload sets the commitment boundary. Compare its input amount, route or pool and minimum output with the current quote. The estimated output and pool fee may appear only in the quote rather than as separate payload fields. If any field differs from the intended operation, rejecting the request leaves room to inspect the discrepancy before signing.

Pool versions change the liquidity model

Liquidswap documentation describes two contract families with different pricing mechanics and position records. Treating them as interchangeable can obscure their fee logic, withdrawal mechanics and price exposure.

Two contract families

V0.5 curve pools

V0.5 continues the curve-based design used by earlier contracts. Uncorrelated pools use the constant-product relationship x * y = k, so trades move the reserve ratio and therefore the quoted price. Stable pools use a separate curve intended for assets expected to remain closely correlated. Providers deposit pool assets and receive LP coins representing their proportional share. Burning those LP coins redeems the corresponding reserves and accumulated provider fees under the pool’s state.

V1 liquidity book pools

In V1, each bin holds liquidity at a specific price. The active bin corresponds to the pool’s active price area, and a swap can move across adjacent bins when it exhausts available liquidity. The bin step controls the price interval between them.

Providers choose where to place liquidity rather than holding only one pool-wide share. LB position tokens record ownership within a pool and bin. Fees accrue to liquidity in bins used by swaps, while V1 can combine a base fee with a variable component influenced by pool activity and bins crossed. The displayed pool configuration therefore matters more than a protocol-wide fee assumption.

How does a swap move from quote to settlement?

A swap reaches settlement only after the quoted operation passes its encoded limits and the Aptos transaction completes successfully.

The usable starting state consists of the correct network, identified input and output assets, a selected pool and a current quote. Before signing, compare the transaction request with the current quote, including the intended input, route or pool and minimum output. Signing authorizes that payload; it does not freeze pool reserves or the active bin while the transaction waits for execution.

After submission, the transaction hash identifies the on-chain attempt. A successful status and the resulting asset balance provide the handoff evidence from the swap contract to the account. A pending notification or wallet popup does not establish settlement by itself.

If another trade changes the pool enough to push output below the encoded minimum, the swap aborts rather than settling at the lower amount. Refreshing the pool state produces a new quote for review. The reader can then accept the revised terms, change the input or stop without resubmitting the stale payload.

Open full-size image

Price impact, slippage limits and fees are separate constraints

Price impact comes from the trade’s interaction with available liquidity. In V0.5, the reserve curve changes the exchange rate as the trade changes pool balances. In V1, output can span multiple fixed-price bins, with each crossed bin moving execution to another price level. Deeper liquidity near the active price generally leaves more output available before that movement becomes material.

A slippage or minimum-output setting defines the lowest result the transaction may accept; it does not remove price impact. Pool fees form another deduction. V0.5 stores configurable fee settings for each pool, while V1 uses pool parameters for base and variable fees. The Aptos network fee pays for transaction execution separately, so a complete cost review distinguishes the pool charge, the quoted price movement and the network charge.

Which checks belong before adding liquidity?

The necessary checks are contract version, asset identity, pool design, price exposure and the position record the provider will receive.

Curve-pool providers hold a proportional claim on changing reserves. V1 providers choose bins, so the active price can move away from their liquidity. Those bins stop participating in swaps until the price returns or the provider changes the position. In either model, fee income does not guarantee the combined assets will retain their starting value.

Position decision checklist

• Confirm the pool belongs to the intended contract family and Aptos network.
• Match each asset by its on-chain identifier rather than its displayed ticker alone.
• For V0.5, check the curve type; for V1, inspect the bin step and selected price bins.
• Read the live pool fee, deposit amounts and minimum accepted amounts before signing.
• Identify the LP coin or LB position token expected after successful execution.

Removal follows the same version boundary. V0.5 burns LP coins to redeem a proportional share of both reserves. V1 redeems the bins represented by LB position tokens and applies minimum amounts for the returned assets. A position’s displayed value can change between deposit and removal as trades and market prices alter its composition.

State verification closes the transaction loop

Submission, execution and the resulting account state are separate facts. Only the latter two establish whether the requested change occurred.

A successful swap should have a successful Aptos transaction status and a corresponding output-asset balance change. Adding liquidity should create the version-specific position record, while removal should reduce that record and return assets. A failed status calls for reading the failure reason and current balances before any retry because repeating the same payload may repeat the same constraint failure.

Position identity also deserves a final check. A ticker or collection label can resemble another asset, so the pool and on-chain identifier remain decisive. For example, a V1 LB position links ownership to a particular pool and bin ID.