1. 为什么需要动态费率

当池子状态在短时间内发生大幅变化时，如果系统还来不及吸收这些新信息，就可能让 LP 承受被抽取价值的风险。Likwid v2.2 针对这个问题引入了原生动态费率引擎。它的目标不是消灭所有 MEV 或套利，而是在交易把池子状态推离协议受限价格参考较远时，让这类扰动性的价格移动付出更高成本。

2. 当前 v2.2 的设计

费率引擎直接实现于协议自身的数学库中：

• SwapMath.getPriceDegree：比较实时 pair reserve 与 truncated reserve，衡量本次交易隐含的价格变化幅度。
• SwapMath.dynamicFee：以池子的基础 LP 费率为起点，当价格偏离程度足够大时提高实际费率。
• PriceMath.transferReserves：让 truncated reserve 随时间逐步更新，而不是立刻追到新的 pair 状态。
• MarginState.priceMoveSpeedPPM：定义截断参考能够多快追上实时状态。

这样一来，Likwid 在协议内部就建立了一条参考价格带，无需依赖任何外部扩展提供者，也能对市场波动作出反应。

3. 费率如何上升

从高层来看，这套流程大致如下：

1. 从池子配置的基础 swap fee 开始。
2. 估算本次交易会把 pair reserve 拉离 truncated reserve 多远。
3. 如果偏移很小，则继续使用基础费率。
4. 如果偏移显著，则在计算最终输入输出金额之前，以非线性的方式提高有效费率。

其直接效果是：对储备扰动越大的交易，边际手续费越高；而靠近受限价格参考的小额低冲击交易，成本则更低。

4. 为什么 truncated reserve 很重要

动态费率系统依赖协议同时维护两种价格视图：

• Pair reserve：表示池子当前可执行的实时状态。
• Truncated reserve：表示一个只能按设定速度向实时状态靠拢的受限参考。

当实时状态相对受限参考发生剧烈偏离时，池子通过提高费用，使突发性的大幅价格移动交易不再像固定费率模型下那样便宜。

5. 对用户与集成方的影响

这套设计带来几项直接后果：

• 大额扰动储备的交易会支付更高费用
• 保证金开仓与平仓在需要经过池子 swap 引擎时，也会继承这套费率逻辑
• 费率行为完全属于池子原生能力，可以直接从 vault 与数学库层理解

6. 结论

Likwid 的动态费率策略是 v2.2 协议的原生组成部分。它由储备状态、截断价格参考以及协议可控的移动速度共同驱动。