REF Exchange V2 bases on Discretized Concentrated Liquidity (DCL) pool, check paper for details about DCL.

In this article, we discuss some concepts and behavious that are important for users and researchers to have a better understanding of ref-v2.

From Price to Point

For a pool of token X and token Y, the price is defined as How many token Y that can get a unit of token X. For example, a pool of wnear <> usdt, price is similar to near price for usd on those CEX, let’s say 4.05 usdt / wnear. The price of this level is also called decimal price.

Next level is undecimal price. Which means we use undecimal token amounts to compute price. In previous case, wnear has 24 decimals but usdt only has 6, the price comes to 4.05 * 106 / 1024

Next, comes the important part. We need to map this continuous price into discrete one (what we call price point or just point), in a way that let 1.0001 ** point to be the price splitter. Practically, we limit point in a [-800,000, 800,000) range, which can represent an undecimal price range of 1.81e-35 to 6.52e+34, that is 1.81e-17 to 6.52e+52 decimal price range in that wnear<>usdt pool.

Now, each point represent a very small price range, and we use the exact price computed from that point to be the fixed price when swap in this range, which we call it as a constant sum formula model. For example, in previous pool, point -400520 represent a price range of [4.041169… , 4.041573…). And when swap in this small range, we take 4.041169… as fixed swap price.

In a word, we mapping continuous price into small ranges of points. For the curve comprised of those points, we take classic constant production formula for swap. But in those small ranges, we take constant sum formula for swap.

Untitled

From Point to Slot

For those tokens with strong correlation, even a very small price movement will reflect a major change in market. So we allow users to mint liquidity, place order on each point.

But for those pool that hold weak correlation even non correlation tokens, the market price vary frequently and drastically. To get a better perfromance, we group points into slots, and only allow users to mint liquidity or place order on those slot borders.

For example, let’s say take 40 points per slot in previous wnear-usdt pool, we have three conjunctive slot border -400560, -400520, -400480, they represent three conjunctive hunman-readable price: 4.025040, 4.041574, 4.057366. And the current point is -400498, which means a price of 4.050069. Then If Alice want to palce an order that just one step over current price, she can only choose 4.057366. Or to palce order one step below current one, that would be 4.041574. Seems complex? Don’t worry, our frontend would take care all these stuff for users. They can just simply click up or down to have a small adjustment of price.