v0.3.0
For more info on the v0.3.0 major release, please refer to docs.
Changelog:
- Contracts deployed on testnet.
- All the modules are deployed at the same address as before:
0x43417434fd869edee76cca2a4d2301e528a1551b1d719b75c350c3c97d15b8b9
. - All the pools are currently stored on the Resource Account created during the Liquidswap initialization:
0x385068db10693e06512ed54b1e6e8f1fb9945bb7a78c28a45585939ce953f99e
- As all the pools are stored at the same address, it’s no longer necessary to pass the
pool_addr
parameter as an argument to functions. - The current structure of each pool is as follows:
struct LiquidityPool<phantom X, phantom Y, phantom Curve> has key {
coin_x_reserve: Coin<X>,
coin_y_reserve: Coin<Y>,
last_block_timestamp: u64,
last_price_x_cumulative: u128,
last_price_y_cumulative: u128,
lp_mint_cap: coin::MintCapability<LP<X, Y, Curve>>,
lp_burn_cap: coin::BurnCapability<LP<X, Y, Curve>>,
// Scales are pow(10, token_decimals).
x_scale: u64,
y_scale: u64,
}
- The third generic parameter,
LP
, has been replaced with a new parameter,Curve
. Curve
specifies which liquidity curve is used for the LiquidityPool and can be one of the following:- Uncorrelated:
liquidswap::curves::Uncorrelated
- Stable:
liquidswap::curves::Stable
.
- Uncorrelated:
- New pools no longer require specifying the
LP
parameter, as they all share the same LP coin type:
struct LP<phantom X, phantom Y, phantom Curve> {}
deployed at0x385068db10693e06512ed54b1e6e8f1fb9945bb7a78c28a45585939ce953f99e
. - The
LP
generic was removed from all the methods for the same reason, so a dev needs only to passX, Y
andCurve
types. - All LP generics are currently sorted by default (meaning that they always have the same X and Y sorting order). So, for a pool like BTC/USDT/Uncorrelated, the LP would always be
LP<BTC, USDT, Uncorrelated>
, notLP<USDT, BTC, Uncorrelated>
. - All the pools are currently unique. For example, there can’t be two BTC/USDT pools on different addresses, but there can be two BTC/USDT pools that use different curves.
- This is an important distiction; still, anyone can create a new pool, and it’s still permissionless.
- A new sorting algorithm for generics: the algorithm takes a coin type (meaning the format
address::module_name::struct_name
) and starts comparing struct names. If the struct name is not the same, it returns the result. If it is the same, it continues comparing module names and addresses. Link: https://github.com/pontem-network/liquidswap/blob/main/sources/libs/coin_helper.move#L35 - A number of methods now require the same order of generics that originally defined a pool. It means that coin type arguments
X
andY
need to be sorted according to the new sorting algorithm.
These methods are (inrouter.move
/scripts.move
):register_pool
/register_pool_and_add_liquidity
add_liquidity
remove_liquidity
The rest of the methods, including swaps and getters, work fine with any coin argument order.