The eckoDEX Wrapper

An overview of the Wrapper Contract that allows for advanced swap functions.

The Wrapper is one of the main pieces of eckoDEX, enabling advanced features such as single sided liquidity, boosting KDX rewards, and more. The wrapper contract also works with the alchemist SC for wrapping and unwrapping KDX into other tokens. This is utilized by the Staking program currently.

Wrapper directory

The following are the main files in the wrapper directory:

  • wrapper.pact: The core of the wrapper. Holds the liquidity tokens on behalf of the users, and includes all the logic necessary for implementing the KDX boosted rewards.

  • tokens/kdx.pact: The main contract for the KDX token. A slightly-modified fungible-v2 token with minting and burning capabilities as well as some other minor changes.

  • tokens/alchemist.pact: A module used for wrapping and unwrapping KDX into other tokens that can be redeemed in a 1:1 manner for KDX. Currently used by the staking program (via the tokens/skdx.pact sKDX module).

  • wrapper.repl and simulator.repl: Test files.

The directory also includes the files related to the KDX token (in the wrapper/tokens directory).

The Wrapper contract provides the following functionalities:

  • Boosted KDX Rewards for Liquidity Provider fees

  • Adding liquidity with a single side of the pair

  • Utility functions for the frontend to query LP Stats (fees collected, etc)

The Wrapper works by owning all the liquidity on behalf of users, and keeping track of each user's balance by itself. The functions 'add-liquidity' and 'remove-liquidity' are the main entry points to the contract. In order to differentiate between the entry amounts and the fees accrued, the wrapper keeps track of the initial amount added to the liquidity pool, which can be used to calculate the fees collected for a given point in time.

This is done by calculating what IL the user would suffer without collecting any fees, via the geometric mean of the entry amounts, adjusted to the current reserve prices, for example:

if entry reserves are x and y and the user withdraws x' and y' without collecting any fees, we have: x' = sqrt(x * y * price-of-y-in-x) y' = sqrt(x * y / price-of-y-in-x) = sqrt(x * y * price-of-x-in-y)

These numbers can then be used to subtract the IL-adjusted amount from the actual token amounts stored in the pool to find out how many fees were collected by the user. Calculating the fees this way leads to the fees in both tokens to be "equal in price" that is, fees-x = fees-y * price-of-x-in-y

Single Sided Liquidity

Enabling single sided liquidity is one of the core functions of the Wrapper. To do this, the contract must calculate at the time of swap equal ratios of token A and B, execute a swap, then finally add liquidity. This is done in the following order:

  • Take desired input 'token a'and calculate an equal amount of 'token b' this equation would be simple if we were not taking fees into account as we could just do t/2 (t=total) but for considering fees we will use this: (= (quote (- T x) A B) (compute-out x A B))

  • Complete the swap of 50% token a to token b

  • Provide liquidity on behalf of the user to the pair a b

Last updated