1 · Vote-Escrowed（veCRV）

1. 概述

参与 Curve DAO 治理需要通过 VotingEscrow 合约锁定 CRV 获得 veCRV。

约束

• veCRV 不可转让。
• veCRV 的获得方式是锁定 CRV。
• 最大锁仓期为 $MAX_LOCK_TIME = 4 \text{ years}$ 。
• 投票权随剩余锁仓时间线性衰减。

2. 锁仓与 veCRV 计算

2.1 线性计算公式

2.2 示例（按 1 CRV 计）

3. 数学建模（bias / slope）

3.1 用户投票权

3.2 全局总投票权

3.3 关系与定义

• $B = \sum b_i$ 。
• $S = \sum s_i$ 。
• $W(t) = \max(0, \sum w_i(t))$ 。

3.4 时间差定义

• $\Delta t_i = t - t_i$ 。
• $\Delta t_0 = t - t_0$ 。

3.5 参数含义

• $w_i$ ：用户 $i$ 的投票权。
• $b_i$ ：用户 bias（用户 checkpoint 时的截距）。
• $s_i$ ：用户 slope（每秒衰减斜率）。
• $\Delta t_i$ ：距离用户上次 checkpoint 的经过时间。
• $W$ ：全局总投票权。
• $B$ ：全局 bias（全局截距）。
• $S$ ：全局 slope（全局每秒衰减斜率）。
• $\Delta t_0$ ：距离全局上次 checkpoint 的经过时间。

4. Checkpoint 更新流程

一次 checkpoint 的更新可分为三步：

1. 时间推进（将全局状态衰减到当前时刻）

• $B' = B_{prev} - S_{prev} \times \Delta t$ 。
• $S' = S_{prev}$ 。

2. 叠加用户差量（将用户状态变化合并到全局）

• $\Delta b = b_{new} - b_{old}$ 。
• $\Delta s = s_{new} - s_{old}$ 。
• $B_{new} = B' + \Delta b$ 。
• $S_{new} = S' + \Delta s$ 。

3. 更新到期调度（slopeChanges）

• 先撤销旧调度： $slopeChanges[end_{old}] = slopeChanges[end_{old}] - s_{old}$ 。
• 再写入新调度： $slopeChanges[end_{new}] = slopeChanges[end_{new}] + s_{new}$ 。
• 时间推进跨过某周 $t_k$ 时： $S = S - slopeChanges[t_k]$ 。

5. 按周对齐与 Gas 成本

5.1 按周分桶（week rounding）

为避免为每个“精确到秒”的到期时刻维护状态，VotingEscrow 通常将 unlock_time 向下对齐到整周（例如 $t_k = \lfloor t / WEEK \rfloor \times WEEK$ ）。

对齐后的效果是：到期事件只会发生在离散的周边界 $t_k$ 上。

• slopeChanges 的 key 变为有限集合 $\{t_0, t_1, \ldots, t_n\}$ （每周一个桶）。

• 任意用户的锁仓到期只会影响其所在周桶的 $slopeChanges[end]$ 。

• 由此可以将“全局斜率 $S$ 的跳变”离散化处理。

  5.2 全局补账（补齐 missed weeks）

全局状态不会随时间自动更新。仅当发生交互（例如创建锁仓、增加锁仓、延长锁仓、提取到期锁仓）时，合约才会把全局从上次 checkpoint 的时间推进到当前时间。

推进时按周循环：每跨过一周 $t_k$ ，就应用该周桶的到期调度，使全局斜率发生跳变。

• 记区间开始时（刚过 $t_{k-1}$ ）的全局状态为 $(B_{k-1}, S_{k-1})$ 。
• 在区间 $[t_{k-1}, t_k]$ 内，斜率不变，因此 bias 先按线性衰减推进到周边界：
  • $B_k^- = B_{k-1} - S_{k-1} \times (t_k - t_{k-1})$ 。
  • $S_k^- = S_{k-1}$ 。
• 到达周边界 $t_k$ 后，执行本周到期的斜率跳变（从全局斜率中移除到期部分）：
  • $S_k = S_k^- - slopeChanges[t_k]$ 。
  • $B_k = B_k^-$ 。

其中， $B_k^-, S_k^-$ 表示“应用 $slopeChanges[t_k]$ 之前”的中间量， $B_k, S_k$ 表示“应用之后”的全局量。

5.3 Gas 复杂度直觉

• 时间推进的循环次数约等于“遗漏的周数”，因此成本近似 $O(\text{missed\_weeks})$ 。
• 复杂度与用户总数无关，因为推进只依赖全局桶（每周一个），不需要遍历所有用户。
• 若长时间无人触发全局更新，下一次交互需要补齐较多周桶，单笔交易 gas 可能偏高。

5.4 工程含义（为何这样设计）

• 若不做按周对齐，slopeChanges 的 key 可能是大量离散时间点，状态膨胀且推进成本不可控。
• 按周对齐用可控的时间粒度换取可控的状态规模与可预测的最坏成本。