Skip to content

v0.3.0

Compare
Choose a tag to compare
@borispovod borispovod released this 22 Sep 10:31
· 30 commits to main since this release

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.
  • 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 at 0x385068db10693e06512ed54b1e6e8f1fb9945bb7a78c28a45585939ce953f99e.
  • The LP generic was removed from all the methods for the same reason, so a dev needs only to pass X, Y and Curve 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>, not LP<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 and Y need to be sorted according to the new sorting algorithm.
    These methods are (in router.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.