add vePendle

Author: paris-10

defi/Pendle/vePendle.md

@@ -0,0 +1,149 @@
+## 1. 模型原理及数学描述
+
+### (1) 锁仓与权重计算的核心思想
+
+vePendle 模型本质上是一个 **锁仓机制（Voting Escrow）**，用户通过锁定 PENDLE 代币，获得一个与锁定金额和锁定时长挂钩的非转让投票权。核心目标在于：  
+- **激励长期持有**：通过锁仓延长时间，用户能获得更高的治理权重和奖励；  
+- **权重动态衰减**：随着锁仓时间的流逝，投票权逐渐降低，确保治理权与锁定期限紧密绑定。
+
+最常见的数学公式描述为：
+
+\[
+\text{vePendle 权重} = \text{锁定金额} \times \frac{\text{剩余锁定时间}}{\text{最大锁定时间}}
+\]
+
+其中：  
+- **锁定金额** 是用户投入的 PENDLE 数量；  
+- **剩余锁定时间** = 锁定结束时间 - 当前时间；  
+- **最大锁定时间** 为系统预设的最大锁仓周期（例如 4 年）。
+
+这种设计保证了用户在锁仓期内，其治理权会**线性衰减**，从而鼓励用户延长锁定时间或频繁更新锁仓状态以保持较高权重。
+
+### (2) 权重随时间衰减的动态性
+
+与 Curve 的 veCRV 类似，vePendle 的核心在于动态计算用户的治理权重。假设用户在时刻 \(t_0\) 锁定 \(A\) 个代币，到期时间为 \(T\)（\(T \leq t_0 + \text{max\_lock}\)），那么任一时刻 \(t\)（\(t_0 \leq t \leq T\)）的投票权重可以表达为：
+
+\[
+w(t) = A \times \frac{T - t}{T - t_0} \quad \text{或} \quad w(t) = A \times \frac{T - t}{\text{max\_lock}}
+\]
+
+不同项目可能在公式上有细微区别：
+- 前者把初始锁仓时长作为归一化因子；
+- 后者统一使用最大锁仓时长，使得即使用户锁仓时间不足最大周期，权重也以相同标准计算。
+
+这种线性衰减设计确保了锁仓越接近结束，用户实际拥有的治理权越低；从而在治理过程中，迫使用户“续锁”或更新锁仓以保持较高权重。
+
+
+
+## 2. 代码实现细节与示例
+
+下面给出一个伪代码示例，展示如何在 Solidity 中计算和更新 vePendle 权重。注意这只是对核心逻辑的展示，实际合约会更为复杂，并会考虑安全、重入保护以及高效数据存储问题。
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+contract VePendle {
+    // 锁仓信息
+    struct LockInfo {
+        uint256 amount;       // 锁定的 PENDLE 数量
+        uint256 endTime;      // 锁仓结束时间
+        uint256 startTime;    // 锁仓开始时间（可选，用于更精细的计算）
+    }
+
+    // 用户地址映射到锁仓信息
+    mapping(address => LockInfo) public locks;
+
+    // 最大锁仓时间，例如：4年 = 4 * 365 * 86400 秒
+    uint256 public constant MAX_LOCK_TIME = 4 * 365 days;
+
+    // 事件通知：锁仓或更新
+    event Locked(address indexed user, uint256 amount, uint256 endTime);
+
+    // 用户锁仓函数
+    function lock(uint256 _amount, uint256 _lockDuration) external {
+        require(_lockDuration > 0 && _lockDuration <= MAX_LOCK_TIME, "Invalid lock duration");
+
+        // 计算结束时间
+        uint256 endTime = block.timestamp + _lockDuration;
+
+        // 此处省略代币转移逻辑（如 transferFrom 等）
+        locks[msg.sender] = LockInfo({
+            amount: _amount,
+            startTime: block.timestamp,
+            endTime: endTime
+        });
+
+        emit Locked(msg.sender, _amount, endTime);
+    }
+
+    // 计算当前 vePendle 权重
+    function getVoteWeight(address _user) public view returns (uint256) {
+        LockInfo memory lockInfo = locks[_user];
+        if (block.timestamp >= lockInfo.endTime) {
+            return 0;
+        }
+        // 剩余锁仓时间
+        uint256 remainingTime = lockInfo.endTime - block.timestamp;
+        // 权重 = 锁定金额 * (剩余时间 / 最大锁仓时间)
+        return lockInfo.amount * remainingTime / MAX_LOCK_TIME;
+    }
+}
+```
+
+### 关键点解析
+
+- **锁仓函数**：用户调用 `lock` 函数时，必须指定锁定数量和锁仓时长，系统计算出结束时间，并记录用户锁仓信息。实际应用中，还需要校验用户余额、调用 ERC20 的 `transferFrom` 等操作。
+
+- **权重计算**：`getVoteWeight` 函数根据当前时间动态计算用户剩余锁仓时间，再按照比例返回用户的治理权重。注意使用整型除法时可能存在精度损失，实际实现中可考虑使用高精度数学库或调整单位（例如使用 wei）。
+
+- **状态更新**：用户可以在锁仓期内对锁仓信息进行续锁（延长 endTime）或增加锁定量，系统需设计相应的更新函数，同时调整对应的权重。  
+
+
+
+## 3. 激励机制与治理设计
+
+### (1) 治理权与奖励挂钩
+
+vePendle 模型通常不仅赋予治理投票权，还将奖励分配（如交易费分红、流动性挖矿加成等）与用户的 vePendle 权重挂钩。这样一来，治理权越大，用户在系统中享受的额外收益也越多，从而鼓励用户长期持有和参与治理。
+
+### (2) 防止短期操控
+
+由于投票权随着时间衰减，短期内大量买入 PENDLE 并锁仓虽然可以瞬间获得较高权重，但如果不续锁或延长锁定时间，其权重会迅速下降。这降低了“快进快出”用户对治理的短期操控风险，使治理决策更具持续性和合理性。
+
+### (3) 动态调整与续锁激励
+
+为了鼓励用户延长锁仓期，协议可设计动态激励机制，比如：
+- 在锁仓期接近结束时，通过奖励“续锁”行为（例如额外奖励或投票权加成）来防止大量用户同时解锁；
+- 设计自动续锁功能，让用户在解锁窗口自动选择延长锁仓周期，保持治理权稳定。
+
+
+
+## 4. 潜在风险与优化挑战
+
+### (1) 流动性问题
+
+长期锁仓虽然能提升治理稳定性，但也会降低市场上 PENDLE 的流动性，可能在市场波动时加剧价格波动。解决方案包括设计部分流动性激励措施或支持质押衍生品。
+
+### (2) 解锁窗口集中风险
+
+当大量用户的锁仓期在同一时间到期时，可能导致治理权迅速下降及市场抛压。为缓解此风险，可采用以下策略：
+- **分散解锁时间**：在用户锁仓时引入随机化或限制每个周期内可解锁的比例；
+- **预告机制**：提前通知用户解锁窗口，引导用户续锁或逐步退出。
+
+### (3) 算法复杂度与 gas 优化
+
+实时计算权重可能涉及高频调用，如何在保证精度的同时降低 gas 消耗，是设计时必须考虑的点。常见做法包括：
+- 利用“快照”机制，在治理投票前批量更新状态；
+- 使用“延迟更新”策略，仅在用户交互时计算最新权重。
+
+
+
+## 5. 总结
+
+vePendle 模型通过锁仓获得动态衰减的治理权重，不仅将治理权与长期承诺挂钩，还为激励机制设计提供了灵活空间。其核心技术要点包括：
+- **权重的线性衰减**：通过剩余锁仓时间与最大锁仓期的比例来计算治理权重；
+- **激励机制设计**：锁仓与奖励、治理挂钩，鼓励用户长期持有并参与生态治理；
+- **风险与优化**：面对流动性、解锁集中风险和 gas 成本，设计者需要在安全性、用户体验与系统性能之间找到平衡。
+
+这一模型在技术上借鉴了成熟的 veCRV 思路，同时针对 Pendle 生态的特定需求做出调整，为去中心化金融项目提供了既稳定又灵活的治理和激励方案。