2026/4/17 · Curve 机制 · 第 1 / 2 讲

2 · Gauge & Bribe

CRV 通胀如何分发到池子与 LP：Gauge 积分会计、Boost、Controller 投票调度与 Bribe 治理市场。

1. 概述与定位

dao-gauges 主要回答的问题是：CRV 的通胀如何被分配到不同池子与不同 LP 用户。

从治理视角看，这一模块处于”参数执行层”：

veCRV 决定谁有投票权。
Gauge 投票决定通胀往哪里流。
LiquidityGauge 与 Minter 负责把通胀变成用户可领取的 CRV。

核心合约角色：

LiquidityGauge：记录用户 LP 供给与时间积分，用于分发 CRV 及其他奖励。
GaugeController：维护 gauge 列表、gauge 权重、type 权重，并协调各 gauge 的 CRV 产出速率。
Minter：按 gauge 记录铸造 CRV。

2. CRV 通胀（Inflation）

CRV 使用分段线性通胀，按年进入新的 mining epoch，年化通胀速率逐步下降。CRV 的”总发行节奏”由通胀曲线控制；“发行去向”由 gauge/type 权重控制。

2.1 分配速率主公式

r'(t) = w_g(t) \times w_t(t) \times r(t)

其中：

$r(t)$ 是全局通胀速率（时间函数）。
$w_g(t)$ 是某个 gauge 的权重。
$w_t(t)$ 是该 gauge 所属类型（type）的权重。
$r'(t)$ 是该 gauge 在时刻 $t$ 可分配的 CRV 速率。

2.2 Epoch 形式

由于通胀按年调整， $r(t)$ 在每个 epoch 内是常数，所以常写成序列记号 $r_n$ 。

r(t) = r_n, \quad t \in [T_n, T_{n+1})

r_0 \approx 22\%

r_{n+1} = r_n \times 2^{-1/4}

3. Gauge 分发数学

这一章回答一个问题：如何在不遍历所有用户的前提下，精确结算每个用户应得 CRV。

3.1 变量定义

$r'(t)$ ：该 gauge 在时刻 $t$ 的 CRV 排放速率。
$S(t)$ ：该 gauge 在时刻 $t$ 的总流动性（总 LP）。
$b_u(t)$ ：用户 $u$ 在时刻 $t$ 的 LP 余额。

用户的累计应得量为：

I_u(t) = \int_0^t \frac{r'(\tau)\, b_u(\tau)}{S(\tau)}\, d\tau

3.2 全局积分（单位 LP 累计奖励）

定义全局积分 $I_{is}(t)$ ，表示每 1 单位 LP 自合约部署以来可累计的奖励刻度：

I_{is}(t) = \int_0^t \frac{r'(\tau)}{S(\tau)}\, d\tau

由此，用户积分可以从全局积分直接映射。定义以下增量记号：

$\Delta I_{is}^{(k)} := I_{is}(t_k) - I_{is}(t_{k-1})$ ：全局积分在区间 $[t_{k-1}, t_k]$ 的增量。
$\Delta I_u^{(k)} := I_u(t_k) - I_u(t_{k-1})$ ：用户积分在同一区间的增量。
$b_u^{(k-1)}$ ：用户在区间起点 $t_{k-1}$ 的 LP 余额（区间内保持不变）。

核心映射关系（增量形式）：

\boxed{\Delta I_u^{(k)} = b_u^{(k-1)} \cdot \Delta I_{is}^{(k)}}

用户在某区间的奖励增量 = 用户在该区间起点的余额 × 全局积分在该区间的增量。

当区间取无穷小时，得到连续微分形式：

dI_u(t) = b_u(t)\, dI_{is}(t)

3.3 合约状态映射

上述积分量在合约中有直接对应的存储变量：

integrate_inv_supply：全局单位流动性积分，即 $I_{is}$ ，作为”全局计价尺”。
integrate_fraction：用户累计应得份额，即 $I_u$ ，记录用户”在计价尺上的累计位置”。

3.4 结算触发机制（事件驱动）

用户余额只在交互时变化，因此只需在以下事件点结算增量，不必连续更新每个账户：

用户执行 deposit 或 withdraw
$r'$ 发生变化（gauge 权重变化、mining epoch 切换）
用户主动调用 user_checkpoint

每次事件触发时，合约：

先将全局积分 $I_{is}$ 推进到当前时刻。
再用旧余额 $b_u^{(k-1)}$ 乘以积分增量，累加到用户的 integrate_fraction。
最后更新余额。

3.5 守恒性证明

对所有用户在同一时刻求和：

\sum_u dI_u = \sum_u b_u\, dI_{is} = S\, dI_{is} = r'(t)\, dt

全体用户奖励增量之和恰好等于该 gauge 的排放增量，保证”按份额分配”与”总排放”严格一致，不存在泄漏或超发。

3.6 与 Vote-Escrowed 的结构对比

两个模块采用了对称的”全局状态 + 局部增量”设计模式：

维度	Vote-Escrowed	Gauge 分发
全局量	全局投票权 $W(t)$ （bias/slope）	全局积分 $I_{is}(t)$
局部量	用户投票权 $w_i(t)$	用户积分 $I_u(t)$
更新时机	用户 checkpoint / 锁仓变更	用户存取 / 权重变化
设计目标	避免遍历用户计算衰减	避免遍历用户结算奖励

二者共同点：都把复杂的逐用户连续过程，转化为”全局状态 + 局部增量”的可维护模型，使链上成本由事件频率驱动而非用户总数驱动。

4. Boost 机制（veCRV 与 LP 奖励联动）

文档给出的 boost 形式为：

b_u^* = \min\left(0.4\, b_u + 0.6\, S \frac{w_i}{W},\ b_u\right)

参数说明：

$b_u$ ：用户原始 LP 余额。
$b_u^*$ ：用于分配 CRV 的有效工作余额（working balance）。
$w_i$ ：用户 veCRV 投票权。
$W$ ：全网 veCRV 总投票权。
$S$ ：gauge 总 LP。

直觉：

没有 veCRV 时，主要按 LP 份额分。
veCRV 越高，working balance 越接近上限，CRV 产出可被放大（常说最高约 2.5x）。
veCRV 到期后，kick 可触发用户 checkpoint，移除其过期 boost。

5. Gauge 投票与 Controller 调度

5.1 投票生效与冷却

用户可将 veCRV 分配给多个 gauges。
新投票通常在”下一个周 epoch”生效，而非立即生效。
单一 gauge 的投票修改有冷却期（文档写为 10 天）。

5.2 Controller 的状态设计

GaugeController 维护：

vote_points：每个 gauge 的 bias/slope 点。
vote_bias_changes、vote_slope_changes：未来周边界的计划变更。
vote_user_slopes：用户-每个 gauge 的投票斜率、已用 power、锁仓到期等。

工程目的：

把”随时间衰减 + 到期跳变”离散到周边界处理。
将更新成本与”经过了多少周”相关，而非与”多少用户同时存在”相关。

6. Bribe 与治理市场（与 veCRV 页面的衔接）

dao-gauges 官方文档重点在 Gauge/Emission 机制本身；Bribe 更偏生态层博弈。

可把 Bribe 放在本节作为”机制外层”理解：

协议方希望自身池子获得更高 gauge 权重，会向 veCRV 持有者提供额外激励（Bribe）。
投票者在”基础 CRV 排放收益 + 外部 Bribe 收益”之间做组合决策。
因此，Gauge 投票会演化成一个连续的治理市场。

与 Curve - Vote-Escrowed（CN） 的关系：

ve 页面解释”投票权从哪里来、如何衰减”。
本页解释”投票权如何影响 CRV 去向与收益分配”。

后续可扩展（按你需要再加）：

常见接口速查（working_supply、working_balances、claimable_tokens、user_checkpoint、kick）。
与 RealFi 的映射对比（是否周对齐、boost 公式、分发会计模型差异）。