State variables

Last modified: April 22, 2026

To keep notation consistent with the previous sections, we continue to denote the two pool assets by $X$ and $Y$ , even though smart-contract implementations often refer to them as token0 and token1.

We will be interested in the variables listed in the table below. The entries marked by $T$ are tick-indexed variables; that is, a separate value is stored for each initialized tick.

Table. State variables used by the CenturionDEX v3 pool contract

Variable	Notation	Type
Current tick index	$i_c$
Current square-root price	$\sqrt{p}$
Total active liquidity	$L_{\mathrm{tot}}$
Net liquidity at tick $i$	$\Delta L(i)$	$T$
Gross liquidity at tick $i$	$L_g(i)$	$T$
Global fee growth in tokens $X$ and $Y$	$f_g^X,\; f_g^Y$
Fee growth outside tick $i$ in tokens $X$ and $Y$	$f_o^X(i),\; f_o^Y(i)$	$T$

Current tick index

The current tick index $i_c$ is the integer tick index associated with the current market price. Since the price grid is defined by

p(i)=1.0001^i,

the current tick index is given by

i_c=\left\lfloor \log_{1.0001}(p)\right\rfloor.

Thus, $i_c$ identifies the greatest tick whose associated price does not exceed the current price $p$ .

Square root of the current price and total active liquidity

Rather than tracking the real reserves of the pool directly, the CenturionDEX v3 contract tracks the current square-root price $\sqrt{p}$ together with the total active liquidity $L_{\mathrm{tot}}$ . This is sufficient because the corresponding virtual reserves satisfy

x_v=\frac{L_{\mathrm{tot}}}{\sqrt{p}}, \qquad y_v=L_{\mathrm{tot}}\sqrt{p}.

Hence, the pair $(\sqrt{p},L_{\mathrm{tot}})$ completely determines the virtual state of the active portion of the pool. Once these two quantities are known, the swap equations and the local trading geometry are fully determined.

Net liquidity

For each initialized tick index $i$ , the net-liquidity variable $\Delta L(i)$ measures the jump in active liquidity when the price crosses that tick from left to right, that is, from lower prices to higher prices. Accordingly:

if the price crosses tick $i$ from left to right, then

L_{\mathrm{tot}} \leftarrow L_{\mathrm{tot}} + \Delta L(i),

if the price crosses tick $i$ from right to left, then

L_{\mathrm{tot}} \leftarrow L_{\mathrm{tot}} - \Delta L(i).

To illustrate this rule, consider three positions:

P_1:[t_1,t_3], \quad L_1=4,

P_2:[t_2,t_4], \quad L_2=7,

P_3:[t_4,t_5], \quad L_3=3,

where $t_1<t_2<t_3<t_4<t_5$ are initialized ticks. Moving from low prices to high prices, we obtain

\Delta L(t_1)=4, \qquad \Delta L(t_2)=7, \qquad \Delta L(t_3)=-4,

\Delta L(t_4)=3-7=-4, \qquad \Delta L(t_5)=-3.

Thus, the active liquidity increases when a position begins, decreases when a position ends, and changes by the algebraic sum of those effects when multiple positions begin or end at the same tick.

Gross liquidity

For each initialized tick $i$ , the gross-liquidity variable $L_g(i)$ is defined as the sum of the liquidity parameters of all positions that reference tick $i$ as one of their two boundaries.

This variable serves a different purpose from net liquidity. Net liquidity tells the contract how the total active liquidity changes when the price crosses a tick. Gross liquidity, by contrast, tells the contract whether the tick is still needed at all. If the last position that references a tick is removed, then $L_g(i)$ becomes zero, and the tick may be uninitialized.

It is crucial to note that gross liquidity cannot be reconstructed from net liquidity alone. A tick may have zero net liquidity and nevertheless still be referenced by one or more positions.

Example (Net and gross liquidity)

Consider a CenturionDEX v3 pool with four positions:

P_1:[t_1,t_2],\quad L_1=3,

P_2:[t_2,t_4],\quad L_2=4,

P_3:[t_3,t_5],\quad L_3=2,

P_4:[t_5,t_6],\quad L_4=2,

where

t_1<t_2<t_3<t_4<t_5<t_6.

These are the only initialized ticks in the pool.

Moving from lower prices to higher prices, the net-liquidity updates are obtained as follows:

at $t_1$ , position $P_1$ becomes active, so $\Delta L(t_1)=3$ ;
at $t_2$ , position $P_1$ ends and position $P_2$ begins, so

\Delta L(t_2)=4-3=1;

at $t_3$ , position $P_3$ begins, so

\Delta L(t_3)=2;

at $t_4$ , position $P_2$ ends, so

\Delta L(t_4)=-4;

at $t_5$ , position $P_3$ ends and position $P_4$ begins, so

\Delta L(t_5)=2-2=0;

at $t_6$ , position $P_4$ ends, so

\Delta L(t_6)=-2.

The corresponding gross-liquidity values are determined by summing the liquidity parameters of all positions that reference each tick:

$L_g(t_1)=3$ , since only $P_1$ references $t_1$ ;
$L_g(t_2)=3+4=7$ , since $P_1$ and $P_2$ both reference $t_2$ ;
$L_g(t_3)=2$ , since only $P_3$ references $t_3$ ;
$L_g(t_4)=4$ , since only $P_2$ references $t_4$ ;
$L_g(t_5)=2+2=4$ , since $P_3$ and $P_4$ both reference $t_5$ ;
$L_g(t_6)=2$ , since only $P_4$ references $t_6$ .

These values are summarized below:

Initialized tick	$t_1$	$t_2$	$t_3$	$t_4$	$t_5$	$t_6$
Net liquidity $\Delta L$	$3$	$1$	$2$	$-4$	$0$	$-2$
Gross liquidity $L_g$	$3$	$7$	$2$	$4$	$4$	$2$

In particular, notice that

\Delta L(t_5)=0 \quad\text{but}\quad L_g(t_5)=4.

This shows that zero net liquidity at a tick does not imply that the tick can be discarded. The tick $t_5$ is still referenced by two active position boundaries and must therefore remain initialized.

Global fee growth

Because trading fees are stored outside the active liquidity rather than reinvested into it, the protocol must keep separate track of the total fees collected in each token. It does so through the global fee-growth variables

f_g^X,\qquad f_g^Y.

These quantities measure cumulative fees per unit of liquidity in tokens $X$ and $Y$ , respectively. Storing fee growth on a per-unit-liquidity basis is essential: if the contract stored only absolute fee totals, then any change in active liquidity would make it difficult to determine how much of the accumulated fees belongs to a given position.

Fee growth outside a tick

Let $i$ be an initialized tick index, and let

t(i)=1.0001^i

be the corresponding tick price. The tick $t(i)$ partitions the positive price axis into the two intervals

[0,t(i)) \qquad\text{and}\qquad [t(i),+\infty).

Given the current price $p$ , we define the outer interval associated with tick $i$ to be the one of these two intervals that does not contain $p$ . Equivalently:

if $i_c \ge i$ , then the current price is at or above the tick, so the outer interval is

[0,t(i));

if $i_c < i$ , then the current price is below the tick, so the outer interval is

[t(i),+\infty).

For each initialized tick $i$ , the protocol stores

f_o^X(i),\qquad f_o^Y(i),

which represent the cumulative fee growth per unit liquidity in the outer interval associated with tick $i$ , in tokens $X$ and $Y$ , respectively.

For example, consider the tick from the earlier section whose index is

i=77{,}410,

so that

t(i)\approx 2299.882.

If the current price is $p=2450$ , then $p>t(i)$ , and the outer interval is

[0,2299.882).

If instead the current price is $p=2100$ , then $p<t(i)$ , and the outer interval is

[2299.882,+\infty).

Whenever the price crosses an initialized tick $i$ , the outer interval switches from one side of the tick to the other. Consequently, the contract updates the stored outside-fee variables by the rule

f_o^\alpha(i)\leftarrow f_g^\alpha-f_o^\alpha(i), \qquad \alpha\in\{X,Y\}.

This works because the total fee growth is the sum of the fee growth on the two sides of the tick.

When a tick is initialized for the first time, its outside-fee variables are assigned the values

f_o^\alpha(i)= \begin{cases} f_g^\alpha, & i\le i_c,\\[4pt] 0, & i>i_c, \end{cases} \qquad \alpha\in\{X,Y\}.

This initialization convention should not be interpreted as a literal decomposition of previously accumulated fees. Rather, $f_o^X(i)$ and $f_o^Y(i)$ are auxiliary bookkeeping variables whose purpose is to ensure that the future fee share of each position can be computed correctly.