Pool contract transaction fee logic development

Author of this section: @Fish

this will be achieved. Pool the logic of the fee charged in the contract.

Introduction

in addition to the need to consider deducting fees from users, we should also consider how to allocate fee income according to the liquidity contributed by LP.

First we need Pool two variables are defined in the contract:

/// @inheritdoc IPool
uint256 public override feeGrowthGlobal0X128;
/// @inheritdoc IPool
uint256 public override feeGrowthGlobal1X128;

they represent the fees collected since the pool was created, so why do you need to record these two values? Because LP can withdraw the handling fee at any time, and the time of each LP withdrawal is different, so when LP withdraws the handling fee, we need to calculate his historical accumulated handling fee income.

Calculation of specific values feeGrowthGlobal0X128 and feeGrowthGlobal1X128 is multiplied by the fee FixedPoint128.Q128(2 to the 96 power), and then divided by the amount of liquidity. Similar to the transaction in the previous lecture, multiply FixedPoint128.Q128 in order to avoid accuracy problems, the actual token number will be calculated when the handling fee is finally extracted by LP.

Development

The complete code is in demo-contract/contracts/wtfswap/Pool.sol in.

As stated in the introduction, in Pool.sol the following definition needs to be added:

/// @inheritdoc IPool
uint256 public override feeGrowthGlobal0X128;
/// @inheritdoc IPool
uint256 public override feeGrowthGlobal1X128;

we are in Position also need to add feeGrowthInside0LastX128 and feeGrowthInside1LastX128 it represents the global fee income when LP last withdrew the fee, so that when LP withdraws the fee, we can calculate the income he can withdraw with the accumulated fee income of the pool.

struct Position {
    // 该 Position 拥有的流动性
    uint128 liquidity;
    // 可提取的 token0 数量
    uint128 tokensOwed0;
    // 可提取的 token1 数量
    uint128 tokensOwed1;
    // 上次提取手续费时的 feeGrowthGlobal0X128
+   uint256 feeGrowthInside0LastX128;
    // 上次提取手续费是的 feeGrowthGlobal1X128
+   uint256 feeGrowthInside1LastX128;
}

For example, if the pool feeGrowthGlobal0X128 100, when LP withdraws the handling fee Position medium feeGrowthInside0LastX128 it is also 100, then it means that there is no new handling fee that can be withdrawn from LP.

Next, let's implement the specific logic. First of all, we are in swap method to update the value of the fee after each transaction:

// 计算手续费
state.feeGrowthGlobalX128 += FullMath.mulDiv(
    state.feeAmount,
    FixedPoint128.Q128,
    liquidity
);

// 更新手续费相关信息
if (zeroForOne) {
    feeGrowthGlobal0X128 = state.feeGrowthGlobalX128;
} else {
    feeGrowthGlobal1X128 = state.feeGrowthGlobalX128;
}

Among them FullMath.mulDiv method takes three arguments and returns the product of the first argument and the second argument divided by the third argument.

Then in _Modifyposition add relevant logic in, each LP call mint or burn update the position when the method ( Position ) in tokensOwed0 and tokensOwed1 , record the previously accumulated handling fee and start recording the handling fee again.

function _modifyPosition(
    ModifyPositionParams memory params
) private returns (int256 amount0, int256 amount1) {
    // 通过新增的流动性计算 amount0 和 amount1
    // 参考 UniswapV3 的代码

    amount0 = SqrtPriceMath.getAmount0Delta(
        sqrtPriceX96,
        TickMath.getSqrtPriceAtTick(tickUpper),
        params.liquidityDelta
    );

    amount1 = SqrtPriceMath.getAmount1Delta(
        TickMath.getSqrtPriceAtTick(tickLower),
        sqrtPriceX96,
        params.liquidityDelta
    );
    Position storage position = positions[params.owner];

+    // 提取手续费，计算从上一次提取到当前的手续费
+    uint128 tokensOwed0 = uint128(
+        FullMath.mulDiv(
+            feeGrowthGlobal0X128 - position.feeGrowthInside0LastX128,
+            position.liquidity,
+            FixedPoint128.Q128
+        )
+    );
+    uint128 tokensOwed1 = uint128(
+        FullMath.mulDiv(
+            feeGrowthGlobal1X128 - position.feeGrowthInside1LastX128,
+            position.liquidity,
+            FixedPoint128.Q128
+        )
+    );
+
+    // 更新提取手续费的记录，同步到当前最新的 feeGrowthGlobal0X128，代表都提取完了
+    position.feeGrowthInside0LastX128 = feeGrowthGlobal0X128;
+    position.feeGrowthInside1LastX128 = feeGrowthGlobal1X128;
+    // 把可以提取的手续费记录到 tokensOwed0 和 tokensOwed1 中
+    // LP 可以通过 collect 来最终提取到用户自己账户上
+    if (tokensOwed0 > 0 || tokensOwed1 > 0) {
+        position.tokensOwed0 += tokensOwed0;
+        position.tokensOwed1 += tokensOwed1;
+    }

    // 修改 liquidity
    liquidity = LiquidityMath.addDelta(liquidity, params.liquidityDelta);
    position.liquidity = LiquidityMath.addDelta(
        position.liquidity,
        params.liquidityDelta
    );
}

In the above code, we pass FullMath.mulDiv calculate the final fee that can be withdrawn because the calculation is multiplied. FixedPoint128.Q128 , so you need to divide here. FixedPoint128.Q128 .

This way, when LP calls collect method, you can Position In tokensOwed0 and tokensOwed1 transferred to the user.

One thing to mention, why are we in burn or mint invoked _Modifyposition the fee is calculated in the user, not in the user. swap when you record the handling fee that each pool should receive? Because there may be a lot of liquidity in a pool, if it is recorded at the time of trading, it will generate a lot of operations, which will cause the Gas to be too high. In this calculation, the liquidity held by LP is the "holding" Share of LP, and the method of calculating Token by "holding" (Share) is also used in many Defi scenarios.

Contract Testing

we try to continue in the last lecture test/wtfswap/Pool.ts of swap additional test code in the sample:

// 提取流动性，调用 burn 方法
await testLP.write.burn([liquidityDelta, pool.address]);
// 查看当前 token 数量
expect(await token0.read.balanceOf([testLP.address])).to.equal(
  99995000161384542080378486215n
);
// 提取 token
await testLP.write.collect([testLP.address, pool.address]);
// 判断 token 是否返回给 testLP，并且大于原来的数量，因为收到了手续费，并且有交易换入了 token0
// 初始的 token0 是 const initBalanceValue = 100000000000n * 10n ** 18n;
expect(await token0.read.balanceOf([testLP.address])).to.equal(
  100000000099999999999999999998n
);

looking closely at the above test sample, you will find that the number of token 0 of LP is changed from the original 100000000000n * 10n **18n has become (100000000000n + 100n) * 10n **18n; (Not exactly equal, there will be a little loss in calculation due to the rounding problem). Because The Middle deal swapped in. 100n * 10n **18n token0, which includes a handling fee.

So far, we 've done it all. Pool development of contract logic.

Complete code you can in here. View, the complete test code you can also in here. View. It should be noted that in actual projects, you should write more complete test examples.