Liquidswap introduced V0.5 through separate contracts for Aptos swaps and liquidity

Liquidswap introduced V0.5 as a separate Aptos deployment because its original V0 package used immutable contracts. Released in March 2023, V0.5 changed the arithmetic behind swaps while keeping much of the existing automated market maker (AMM) structure. Adopting that release required targeting its contracts and pools; publishing new code could not replace the original deployment.

A router can add transaction checks around an existing core. A new core deployment establishes separate pool identities, so an integration must keep its contract calls and liquidity accounting on the same version. Aptos Explorer flags Liquidswap's Aptos releases as potentially defunct; current interface availability is uncertain.

Existing V0 liquidity remains attached to its original pool even when a Liquidswap interface begins using V0.5 for new pools.

Pool contracts, routers and scripts carry different responsibilities

The Aptos AMM separates pool accounting from transaction preparation. The core handles reserves and LP issuance, while routers and entry scripts handle calls from an account.

The core holds reserves and LP accounting

A V0 pool resource stores both token reserves and the capabilities that mint or burn liquidity provider (LP) coins. Its Move type includes the underlying coin types and curve. Those LP coins represent a claim on that specific pool. Pool functions enforce pricing and accounting rules when other modules call them. Several routers can therefore use the same core without each holding separate reserves. The contract package identifies the logic, while the resource account identifies where that deployment stores its pools and LP coin module.

Routers add checks and scripts provide transaction entry points

The V0 Router v2 wraps the core with controls such as a minimum amount received. Entry scripts for swaps and liquidity additions or removals take a signer and numeric amounts, withdraw the relevant coins from that account and call the router. These functions can combine related operations within one transaction. The entry point for creating a pool and adding its first liquidity does exactly that. A router release therefore concerns how an integration reaches the core, even when the underlying pool package stays unchanged.

Router v2 belongs to the V0 integration family. Its version number does not identify the V1 core release.

Why did the V0.5 release need a new deployment?

V0.5 required a new deployment because the V0 package's immutable policy prevented replacing its published Move code.

Aptos package policy determines whether a published package can accept replacement code. Compatible upgrades must preserve existing storage layouts and public interfaces. An immutable package blocks code replacement. Liquidswap chose the latter policy for V0, which meant arithmetic changes needed another deployed package. Editing a source repository or preparing a corrected build could not alter the old package.

V0.5 was deployed on Aptos mainnet and testnet. Its release retained most of the original smart-contract logic, giving integrations familiar operations with new deployment identities. The release also brought forward earlier router fixes into its default router.

Immutability keeps the published code unchanged, including any flaws that the code contains. Improvements take effect through a new target, while an integration that retains the old target retains its old implementation.

V0.5 changed arithmetic while retaining the original pool model

V0.5 used Move's native u256 support for stable-swap arithmetic and constant-product checks.

Stable-swap calculations became cheaper to execute

Stable swaps calculate exchanges along a curve for correlated assets. Their calculations need wider intermediate values than ordinary coin balances. Native u256 arithmetic reduced execution gas for these calculations compared with V0. This change concerns the machinery that evaluates a swap, while reserves and the chosen curve still determine its economic outcome.

The reduction also made checked stable-swap router functions and on-chain quote getters more practical in V0.5. Computation costs and the fee that a pool charges concern different parts of a swap. A cheaper calculation does not determine the current pool fee.

Initial liquidity received a precision fix

Initial liquidity calculations determine LP issuance when a pool receives its first deposit. V0.5 corrected a precision issue in those calculations. The fix applies to the V0.5 implementation; it does not recalculate deposits that the V0 code already processed.

Does a frontend update migrate an existing V0 pool?

No, updating the frontend does not itself transfer a V0 pool's reserves or replace its contracts. The March 2023 rollout changed the interface to create new pools through V0.5. It also called for stable-pool liquidity to move gradually. New-pool creation and movement of existing liquidity therefore concerned different actions. A familiar interface could expose the new deployment while an older position still belonged to V0.

V0 router changes, V0.5 pools and V1 require different integrations

Maintaining a V0 integration, adopting V0.5 and integrating V1 involve different dependencies. A V0 router update can continue using the original pool core. V0.5 requires its own deployment references. V1 introduces a liquidity book model and bin-based position accounting, making it a separate integration task.

View full-size image

V1 concentrated liquidity divides reserves across price bins and uses liquidity book (LB) position tokens instead of the original LP coins. Those changes affect integration data and ownership accounting. Changing a package address alone cannot supply the missing bin and position logic. V1 also requires sorted coin types, including at the router level.

Release dependencies must match the deployed core

An integration needs a source revision that matches the package it actually calls. Development branches can contain changes beyond a deployed release. V0's immutable deployment cannot acquire those changes because a dependency points at newer source code. Pinning a release controls the code used for compilation; it does not publish or replace contracts.

Matching also extends to entry scripts and LP coin types. The original router package and LP coin module are separate dependencies. Combining a V0 core reference with V0.5 pool or LP references does not create a compatible integration. Shared operation names do not make those dependencies interchangeable.

For applications that quote swaps and build transactions, both operations need the same selected version. The V0/V0.5 TypeScript SDK exposes that choice alongside separate module and resource-account settings. A rate calculated from one deployment's reserves does not describe another deployment's pool.

V0 pool fee settings and reserves can change through functions already defined in the immutable code. The package fixes the available operations, while each pool supplies its current values. An integration that relies on those values must read the selected pool's state. A pool's quoted behavior can change even when its published contract code stays unchanged.