VE锁仓机制解析：锁1个月与锁4年投票权为何相差48倍

锁1个月和锁4年，投票权差多少？很多人第一反应是“锁4年的票权大概是锁1个月的4倍”，毕竟时间差了48倍，但那是对应锁定期长度本身的倍数。如果按VE（Vote-Maintained Escrow，投票托管）机制来计算，结论是：锁4年获得的投票权约为锁1个月的47到48倍。也就是说，你锁1万个代币4年，等价于别人锁1万个代币1个月之后再乘以48。

这个数字不是产品参数里随手填的折扣系数，它背后是一整套代币经济模型的设计逻辑。理解了这个逻辑，你就理解了为什么Curve在2020年推出veCRV之后，整个DeFi生态里会出现veToken、veNFT、Convex、贿赂市场等一系列衍生玩法，也能明白为什么很多Web3项目在规划代币经济时，第一件事就是纠结“最大锁定期到底设多长”。

这篇文章会从投票权计算公式讲起，对比不同锁仓时长的真实票权差异，然后通过一个最小化Solidity合约和Python模拟脚本，把“锁1个月和锁4年差多少”这个问题从理论落到可运行的代码上。最后，我会结合真实项目中的常见设计和坑，讨论VE机制适合什么场景、不适合什么场景，以及发行方和用户各自应该怎么决策。

如果你正在设计代币经济模型，或者准备参与一个采用VE锁仓机制的项目，这篇文章可以直接当作参考笔记使用。

1. 从“投票权差48倍”说起：VE机制到底解决什么问题

传统质押治理有一个很别扭的地方：用户只需要把代币质押进合约，就能获得投票权，但代币并没有真正被“锁定”，只是暂时不能转账。很多项目早期治理阶段，用户会在投票前买入代币、质押、投完票立刻撤出，甚至用矿池之间的套利策略来反复刷投票权。这样做的结果就是：治理投票的参与者，并不一定是真正关心项目长期发展的人。

VE机制换了一个思路。它不只看你质押了多少代币，还要看你愿意把这些代币锁多久。锁定时间越长，获得的投票凭证veToken就越多。更重要的是，veToken持有的票权并不是恒定不变，而是随时间线性衰减。当你锁了4年，你的票权是满额的；当你只剩下1年到期，票权就只剩下四分之一；当锁定期满没有续锁，你的veToken余额会归零，代币1:1退出。

这个设计解决的核心问题可以概括成一句话：让投票权和退出损失保持一致。

如果一个人锁仓4年，他现在投出去的每一票，都要为自己未来4年的利益负责。他不太可能支持一个“短期拉升后崩盘”的提案，因为他自己根本跑不掉。反过来，一个只锁1个月的人，投票权非常小，即使他想恶意治理，对结果的影响也有限。通过把“时间”这个维度引入治理，VE机制把参与者分成了两类：短期套利者和长期利益相关者，并且长期利益相关者获得更多的治理权重。

从代币经济模型的角度看，VE机制是一种“忠诚度筛选器”。它不是奖励“买得多的人”，而是奖励“愿意被锁住的人”。这种机制天然适合那些已经有真实业务、需要持续治理和参数调整的协议，比如DEX的矿池权重、借贷协议的利率参数、稳定币协议的抵押率等。

2. VE锁仓机制的核心原理：锁时长如何换算成投票权

很多人对veToken的第一印象是“锁仓换积分”，这种理解不够准确。VE机制不是简单的锁仓挖矿，它的核心是投票权与剩余锁定时间成正比。

先明确几个定义：

• VE：Vote-Maintained Escrow，即投票托管。用户将项目代币（比如CRV）锁定到治理合约，换取一个代表投票权的凭证（veCRV）。
• Vote Power：投票权。一个地址拥有的veToken数量，决定了他在协议治理中能投出多大权重的票。
• Max Lock Duration：最大锁定期。项目方设定一个上限，Curve最初设计为4年，其他项目有设2年的，也有设3年的。
• Linear Decay：线性衰减。veToken的票权每天线性减少，直到锁定期满归零。

投票权的计算公式非常简洁：

votePower = lockAmount * remainingTime / maxLockTime

其中：

• lockAmount：用户锁定的代币数量。
• remainingTime：从当前时间到锁定期结束的剩余秒数。
• maxLockTime：项目设定的最大锁定期秒数。

从公式就能看出两个关键特性。

第一个特性是，锁定期越长，初始票权越高。如果你锁4年，remainingTime / maxLockTime = 1，票权等于全部锁定代币数量。如果你锁1年，这个比值只有0.25，票权是25%。如果你锁1个月，这个比值约0.0208，换算成百分比约2.08%。

第二个特性是，票权不恒定。随着时间推移，你锁定的代币数量没变，但remainingTime在变小，所以veToken余额持续下降。这就是为什么Curve生态里经常看到有人每隔几天就“续锁延长”，目的就是把锁定期重新拉回最大时长，保持票权满额。

为了直观理解，下面这个表格展示了同一个用户锁定10000个代币，在不同锁定期限下获得的初始veToken票权。

这里的4年按1461天计算，因为Curve的最大锁定期设计考虑了闰年因素，实际代码中使用的是MAX_LOCK_TIME = 4 * 365 * 86400的变体，部分版本会多算一天。从表中可以清楚看到，锁1个月只有锁4年的约2%，也就是约48分之一。这是整个VE机制最核心、也最容易被新手忽略的地方。

还有一个需要区分清楚的概念：锁定代币和veToken不是同一种资产。用户锁定的是原始代币，获得的是投票凭证。原始代币在锁定期间不可转让、不可交易，veToken同样不可转让（经典设计），但可以用于投票、参与治理、以及在某些衍生协议中作为抵押品。持有veToken不等于拥有原代币，它只代表治理权益和协议费用分配权益。

3. 为什么“锁得越久，越有动力维护生态”？——博弈视角

理解了投票权公式之后，下一个问题是：这种“时间越长票权越大”的设计，在博弈论上到底聪明在哪里？

先看一个反例。假设有一个项目采用传统质押投票，代币质押后可以随时解锁，投票权按质押数量计算。这时候有一个大户，持有10%的代币，他想通过一个对自己有利但损害协议长期发展的提案。他可以这样做：提案投票前买入大量代币，质押，投票，等提案通过后立刻解锁卖掉。整个过程只承担很短时间的市场价格波动风险，但治理结果已经被扭曲了。这就是典型的“治理攻击”，本质是投票者不承担长期后果。

VE机制改变了这个博弈结构。如果一个用户锁定4年，他在投票后仍然有4年时间处于“被锁定”状态。如果协议因为错误提案而崩溃，他手里的veToken虽然还能锁定，但对应的原始代币价格可能已经归零。也就是说，长期锁定者的利益和协议长期发展的绑定深度，远远超过短期锁仓者。

更微妙的是，VE机制天然压制了无效提案的数量。因为投票权的获取有时间成本，长期锁定者不会愿意花时间去投票给一个逻辑漏洞百出的方案。他们更倾向于把投票精力集中在真正影响协议参数和资产配置的提案上。从治理效率角度看，这是一种自发的“质量过滤”。

再从经济激励角度分析。锁定4年意味着用户主动放弃了这4年内卖出代币的权利。他为什么愿意这么做？因为veToken不只是投票权，在很多项目里还附带协议收入分配权。Curve把交易手续费的一部分分配给veCRV持有者，Convex等衍生项目又把投票权重新打包成可交易的资产。用户锁4年，买的不是某一个时间点的收益，而是一张“长期收益凭证”。只要协议持续产生费用，这张凭证的累积价值就能覆盖锁仓的机会成本。

所以，VE机制并不是一个简单的“时间越长越好”的参数，它是一套让治理参与者的利润函数和协议长期价值曲线对齐的机制设计。它也有代价，就是锁仓流动性差、治理参与率可能偏低。这恰好引出了现实项目中围绕VE衍生出来的一系列设计，比如veNFT、委托投票、投票权租赁市场，这些会在后面的章节展开。

4. 核心公式拆解：锁1个月和锁4年的量化对比

现在我们把公式应用到具体场景，看看“锁1个月和锁4年差多少”在不同维度上的表现。

假设一个用户准备锁定10000个代币，项目最大锁定期为4年，按1461天计算，每天86400秒。

最大锁定期的时间长度是：

MAX_LOCK_TIME = 1461 * 86400 = 126230400 秒

锁1个月的秒数（按30天计算）：

30 * 86400 = 2592000 秒

锁1个月的初始投票权：

votePower_month = 10000 * 2592000 / 126230400 = 10000 * 0.02053 = 205.3 veToken

锁4年的初始投票权：

votePower_max = 10000 * 126230400 / 126230400 = 10000 veToken

倍数关系一目了然：

10000 / 205.3 ≈ 48.7

所以“锁1个月和锁4年，投票权差多少”的准确回答是：大约48倍。注意，这里有多个细节会影响精确数字：一个月按30天算还是按实际天数算，最大锁定期按1460天还是1461天算，都只影响小数点后的小幅波动，不影响结论数量级。

如果用户关心的是“我的票权什么时候会衰减”，可以用下面的公式：

当前票权 = 锁定数量 * (锁定结束时间 - 当前区块时间) / 最大锁定期

举个例子，用户锁4年，已经过去了2年，剩余时间也是2年，那么他的票权从10000衰减到5000。也就是说，哪怕你锁的是最大期限，如果你不续锁，票权也会以稳定的速度下降。很多真实项目的用户会把这当作一个“待办事项”：定期去延长锁定期，把票权拉回满额。

如果动态考虑“一个用户锁6个月，另一个用户锁4年”的实际情况，还要加入一个变量：随着时间推移，锁6个月的用户很快到期退出，而锁4年的用户仍然保持长期票权。所以48倍是初始时刻的静态差异，真实世界里的差异会因为退出机制、续锁行为、代币通胀率的变化而进一步放大。

有一类常见误解是：既然锁4年票权是锁1个月的48倍，那所有参与者都应该直接锁4年。这个逻辑不对。投票权大，不代表实际收益大。需要把机会成本纳入计算。假设一个代币在锁仓期间价值下跌了70%，即使你持有48倍票权，这个票权对应的代币价值也缩水了。VE机制把时间承诺变成了治理权，但没有消除市场风险。更合理的策略是：根据自己对项目长期价值的判断，选择锁定期，而不是盲目追求最大倍数。

5. 用Solidity实现一个最小化veToken合约

理解了公式和量化对比之后，用Solidity实现一个最小化的veToken合约，可以更清楚地看到VE机制在代码层面的运作方式。这个合约不追求和Curve完全一致，但它包含了最核心的三个功能：

• stake：锁定代币并计算初始veToken票权。
• getVotingPower：实时查询某个地址当前的投票权。
• redeem：锁定期满后取回原始代币。

先创建一个Solidity合约文件，路径为contracts/VeToken.sol。

// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; interface IERC20 { function transferFrom(address sender, address recipient, uint256 amount) external returns (bool); function transfer(address recipient, uint256 amount) external returns (bool); } contract VeToken { struct LockInfo { uint256 amount; // 锁定的代币数量 uint256 lockEnd; // 锁定结束时间戳 } IERC20 public immutable token; uint256 public constant MAX_LOCK_TIME = 4 * 365 * 86400; // 4年，按1460天简化，实际项目可按1461天 mapping(address => LockInfo) public locks; mapping(address => uint256) public veBalance; event Stake(address indexed user, uint256 amount, uint256 duration); event Redeem(address indexed user, uint256 amount); constructor(address _token) { token = IERC20(_token); } function getVotingPower(address user) public view returns (uint256) { LockInfo memory lock = locks[user]; if (lock.amount == 0) { return 0; } if (block.timestamp >= lock.lockEnd) { return 0; } uint256 remaining = lock.lockEnd - block.timestamp; uint256 power = lock.amount * remaining / MAX_LOCK_TIME; return power; } function stake(uint256 amount, uint256 duration) external { require(amount > 0, "VeToken: amount must be > 0"); require(duration >= 1 days && duration <= MAX_LOCK_TIME, "VeToken: invalid duration"); token.transferFrom(msg.sender, address(this), amount); LockInfo storage lock = locks[msg.sender]; if (lock.amount == 0) { lock.amount = amount; lock.lockEnd = block.timestamp + duration; } else { // 简化处理：多笔锁定合并时，直接增加锁定数量，并重新设定锁定结束时间。 // 生产环境应采用加权平均或按到期时间分槽存储。 uint256 oldWeightedEnd = lock.amount * lock.lockEnd; lock.amount += amount; lock.lockEnd = (oldWeightedEnd + amount * (block.timestamp + duration)) / lock.amount; } // 刷新当前用户的veToken票权 veBalance[msg.sender] = getVotingPower(msg.sender); emit Stake(msg.sender, amount, duration); } function redeem() external { LockInfo memory lock = locks[msg.sender]; require(lock.amount > 0, "VeToken: nothing to redeem"); require(block.timestamp >= lock.lockEnd, "VeToken: lock not expired"); uint256 amount = lock.amount; locks[msg.sender] = LockInfo(0, 0); veBalance[msg.sender] = 0; require(token.transfer(msg.sender, amount), "VeToken: transfer failed"); emit Redeem(msg.sender, amount); } }

关键逻辑说明如下。

getVotingPower函数是VE模型的核心实现。它读取用户锁定的代币数量、锁定结束时间，用剩余时间 / 最大锁定期的比值乘以锁定数量，得到当前投票权。这里有一个隐含特性：当用户刚完成4年锁定时，remaining接近满值，票权最大；之后每个区块时间增加，remaining减少，票权同步下降。

stake函数中，我做了两件事：调用transferFrom把用户原始代币转入合约，再更新锁定信息。注意，这里的lockEnd计算采用了加权平均方式，而不是简单覆盖。这种处理方式在生产环境中仍然不够精确，因为新锁定和旧锁定的到期时间应该分开管理，但用于理解模型已经足够。

redeem函数只有在锁定期结束后才能调用，而且取回的是原始代币数量的1:1兑换。这意味着veToken本身不兑换原代币，只有锁定期满后自动退出。

为了在本地跑通这个合约，可以用Hardhat编译部署。先在项目根目录执行初始化：

mkdir ve-demo && cd ve-demo npm init -y npm install --save-dev hardhat @nomicfoundation/hardhat-toolbox npx hardhat

创建一个部署脚本scripts/deploy.js，内容如下：

const hre = require("hardhat"); async function main() { // 这里使用一个本地Mock ERC20地址，实际部署时可替换为真实代币地址 const mockTokenAddress = "0xYourMockERC20Address"; const VeToken = await hre.ethers.getContractFactory("VeToken"); const veToken = await VeToken.deploy(mockTokenAddress); await veToken.waitForDeployment(); console.log(`VeToken deployed to: ${await veToken.getAddress()}`); } main().catch((error) => { console.error(error); process.exitCode = 1; });

运行部署命令：

npx hardhat run scripts/deploy.js --network localhost

部署之前需要先编写一个最简单的Mock ERC20合约，或者直接使用Hardhat自带的ethers提供临时代币。实际测试时，可以先用OpenZeppelin的ERC20预设合约。

这个最小化合约展示了一个重要规律：veToken票权不是一次性铸造的积分，而是根据实时剩余时间计算的动态余额。生产环境里还需要考虑checkpoint机制、代币快照、投票权委托、veNFT拆分等复杂功能，但底层的数学逻辑不会变。

6. 用Python量化模拟：票权随时间如何变化

为了更直观地看到“锁1个月和锁4年”在不同时间尺度下的票权差异，可以用Python跑一个简单的模拟脚本。这个脚本不依赖任何区块链环境，只复现投票权公式，并打印不同锁定期对应的初始票权和相对比例。

创建一个文件ve_sim.py：

# 文件路径：ve_sim.py def voting_power(lock_amount, lock_days, max_lock_days=4 * 365): """ 按剩余锁定时间线性计算票权。 这里简化使用天作为单位，实际链上使用秒。 """ if lock_days <= 0: return 0 if lock_days >= max_lock_days: return lock_amount power = lock_amount * lock_days / max_lock_days return power lock_amount = 10000 max_lock_days = 4 * 365 + 1 # 按1461天算 locks = [ ("1周", 7), ("1个月", 30), ("6个月", 180), ("1年", 365), ("2年", 730), ("4年", max_lock_days), ] print(f"{'锁仓时长':<8}{'初始票权':<12}{'相对4年比例':<10}") print("-" * 40) for name, days in locks: power = voting_power(lock_amount, days, max_lock_days) relative = power / lock_amount * 100 print(f"{name:<10}{power:<14.2f}{relative:<12.4f}%")

运行方式：

python ve_sim.py

预期输出如下：

锁仓时长 初始票权 相对4年比例 ---------------------------------------- 1周 47.90 0.4790% 1个月 205.34 2.0534% 6个月 1231.98 12.3198% 1年 2498.29 24.9829% 2年 4996.71 49.9671% 4年 10000.00 100.0000%

从模拟输出可以看到几个规律。

第一，锁1个月的票权只有锁4年的约2%，也就是48分之一左右。这个数字与上一节的手工计算基本一致。

第二，票权增长是线性的，每增加一天锁定期，票权就线性增加。如果有一个用户锁3年，他的票权是75%；如果他对项目信心增加，愿意再多锁1年，票权直接提升到100%。这种线性模型的好处是易于理解、易于在链上计算。

第三，如果按“时间价值”的视角看，锁定4年释放的票权倍数是48倍，但实际需要付出的是48个月的流动性锁定。这个比值并不是线性对称的，因为锁4年意味着你要承担4年的价格波动风险。简单说，锁4年的用户需要更强的信念，否则1个月之后市场下跌，他既不能卖出，又只能获得相对4年锁仓用户的低比例票权，非常被动。

这份模拟脚本可以扩展成更复杂的模型，比如加入代币通胀率、veToken总量增长、用户分批锁仓策略，甚至可以加一个到期后自动退出的模拟。对于代币经济模型设计者来说，这种Python脚本比直接读公式更有体感，因为它能快速回答“如果锁定期从4年缩短到2年，票权差异会怎么变化”这类问题。

7. veToken在真实项目中的常见设计与边界问题

VE锁仓机制在技术实现上并不复杂，真正复杂的是它在真实项目中被不断改造和扩展出来的各种衍生设计。了解这些设计，能帮你判断一个项目到底是在认真使用VE机制，还是只是挂了个“锁仓换票权”的名字。

Curve是veToken模型的发明者。用户锁定CRV代币获得veCRV，最大锁定期为4年，veCRV不能转让。veCRV持有者可以投票决定Curve矿池的流动性激励分配，同时也能获得协议交易手续费的一部分。这个设计在Curve生态中运转得相当成功，但也暴露了一个问题：锁仓4年意味着资金流动性极差。

Convex的出现就是为了解决这个问题。Convex允许用户存入CRV并铸造cvxCRV，cvxCRV可以交易、可以参与Curve投票。它本质上把Curve的veCRV锁仓权力打包成一种可流动的资产，相当于给“锁定”这件事找到了一级和二级市场。这段历史说明，VE机制有一个天然矛盾：锁定时间越长，投票权越大，但沉淀资金的流动性也越差。如果项目方不做任何流动性补偿，用户参与意愿会大幅降低。

另一个重要衍生设计是veNFT。一些项目将veToken改造成NFT形式，每个锁仓位置都有独立的到期时间，用户可以转让整个veNFT。这样做的好处是：veToken本身变成了一种可交易的资产，用户可以“卖掉自己的剩余票权”，而不是一直等到锁定期满才能退出。在部分项目中，用户甚至可以把veNFT拆分成多份出售，相当于把未来票权变现。这类设计与Curve早期的不可转让veCRV相比，灵活度更高，但也带来了一些治理风险：如果veNFT被大量集中到少数人手里，治理权可能高度集中。

委托投票和贿赂市场也是VE生态的重要环节。一些项目允许veToken持有者不亲自投票，而是把票权委托给其他地址，于是出现了“投票权租赁”市场。另一个方向是“治理贿赂”，项目方可以激励veToken持有者把票投给特定方向，VE票权因此有了一个市场价格。

从项目方的角度出发，设计VE机制时最需要关注的几个边界问题包括：

• 锁定期上限的设定。4年适合Curve这种已经形成稳定业务和收入预期的协议。新项目如果业务模式还没验证，锁定期设太长会劝退用户。2年到3年更常见。
• 票权递减速度。如果项目希望保持活跃治理，可以把最大锁定期缩短到1年，让票权衰减更快，促使参与者频繁续锁。
• 是否允许veToken转让。允许转让能提高流动性，但可能被巨鲸用来短期集中票权，形成治理垄断。
• 投票权如何参与实际决策。单纯把票权做出来但没有实际治理场景，VE就只是一个虚荣指标。好的VE项目会把投票权映射到真实参数：矿池权重、借贷利率、白名单、费用分配等。

边界问题里最容易被忽视的是“到期退出后再质押”的循环。一个用户锁4年，到期后取回代币，然后决定是否再锁新一轮。此时如果项目已经上线3年，用户的决策依据已经完全不同。很多项目会在锁定期满之前很久就观察到veToken总量下降，因为用户提前计算了续锁性价比。为了维持veToken总供应量稳定，项目方需要引入额外的激励，比如持续的费用分红或veToken质押奖励，否则治理参与率会自然衰减。

从技术实现看，Curve的veCRV合约还有一个设计细节：它在记录用户余额时会使用checkpoint机制，把投票权和时间戳一起存储，避免在一个区块内多次操作时发生计算错误。对于任何要复刻veToken合约的团队来说，checkpoint不是可选项，而是生产环境必备项。后面的章节会专门提到这一点。

8. 常见问题与排查思路

在实际开发或使用VE锁仓合约时，开发者经常遇到以下几类问题，这里整理成排查表。

在这些问题中，最容易踩坑的是第一类“前端VE余额为0”。很多新项目不是合约代码有问题，而是前端没有正确理解veToken余额是动态计算的，直接读取了veBalance变量，导致stake后在同一个交易内没有刷新。最小化合约中我们维护了一个veBalance映射作为缓存，但生产环境更推荐直接调用getVotingPower实时计算，避免缓存不一致。

另一个高发问题是锁定期计算。Solidity中使用block.timestamp获取当前区块时间，不同链的出块时间会影响用户感知的锁仓时长。比如在以太坊上，几秒的区块时间误差可以忽略；但在一些出块时间不稳定的链上，前端计算倒计时时应该以合约返回的lockEnd为准，不要用本地时间自行推算。

9. 最佳实践：发行方和用户分别应该怎么设计或参与

VE锁仓机制不是万能药，它有明确的适用边界。对于代币经济设计者来说，最重要的是先回答三个问题：协议有没有真实治理需求，用户有没有长期锁仓意愿，veToken票权对应什么实际利益。这三个问题的答案，决定了VE机制是否适合这个项目，以及锁定期该设多长。

如果项目方决定采用VE机制，下面几条经验值得纳入设计文档。

第一，至少设置2年以上最大锁定期。1年的锁定期会让票权差异过小，用户没有“锁时间”的动力，VE机制就退化成普通质押。Curve用4年建立了强绑定关系，2年是兼顾参与率和长期绑定的折中点。

第二，为veToken持有者提供持续收入来源。Curve的veCRV能分享交易手续费，Convex的cvxCRV能分享Curve治理激励。如果veToken只是一个投票空壳，没有真实收益，用户不会愿意锁定4年。这个收入不一定是交易手续费，也可以是新代币激励、协议收入分红，甚至是参数提案的贿赂转移价值。

第三，把veToken的治理权落到具体、可调整的参数上。投票如果只是选“社区基金使用方向”这种宽泛主题，veToken用户很难感受到自己票权的实际价值。更合理的配置是：矿池流动性权重、利率参数、白名单准入、费用分配比例等，让每张票都能直接影响用户收益。

第四，考虑veNFT化或至少可转让的退出机制。完全不可转让的veToken会严重降低参与率。很多用户没有信心锁4年，但如果市场能交易veNFT，用户可以随时把剩余票权卖出，相当于给锁定资产提供二级市场流动性。这样既能吸引保守用户，又不破坏长期绑定的核心逻辑。

第五，合约实现必须有checkpoint机制和良好的事件设计。checkpoint是防止一个区块内多次更新余量时出现积分重复计算的关键。事件字段至少要包含user、amount、lockEnd、vePower，方便前端和数据分析工具使用。

对于参与VE锁仓的用户，核心建议是不要单纯追求“锁4年拿最大倍数”。你需要先评估自己的资金使用需求和风险承受能力。如果你是可以持有代币3年以上不看价格的长期建设者，锁4年没问题；如果你只是短期看好项目，锁1到2年更合理。实际操作中，很多人会采用“分批锁定”策略：一部分锁2年，一部分锁4年，一部分不锁用于灵活交易。这样既保留了一定的流动性，也能享受一部分VE高倍票权。

参与项目投票时，还要注意一个容易被忽略的点：不要在锁定期马上结束前投票。因为锁定期结束时veToken票权接近0，如果你的veNFT即将到期，你的投票权重已经非常低。很多活跃用户会在投票前先执行“延长锁定期”，把剩余时间拉回最大值，增加自己的票权，然后再投票。这是一条非常实用的链上操作技巧。

10. 总结

回到最初的问题：锁1个月和锁4年，投票权差多少？答案是约48倍。这个数字来源于VE机制的核心公式——投票权等于锁定代币数量乘以剩余锁定时间除以最大锁定期。锁1个月的剩余时间只占4年总时长的约2%，所以票权只有2%左右，而锁满4年的用户获得100%票权。

这个看似简单的线性公式，改变了治理博弈的底层结构。它让投票权不再只是“钱的信号”，而是“钱加时间的信号”。愿意锁4年的用户，在投票时会自动站在协议长期价值的一边，因为他的退出成本已经通过锁仓沉淀在协议里。这正是VE机制能够在Curve之后被大量DeFi项目复刻和改造的原因。

如果你正在设计代币经济模型，建议先从最小化的veToken合约开始跑通流程，确认你的投票权公式、锁定期、到期赎回逻辑都符合预期，再逐步增加veNFT、委托投票、checkpoint等复杂功能。如果你只是用户，想参与一个VE项目，先搞清楚项目最大锁定期、veToken的收益来源、以及你的资金锁仓周期。笼统地说“锁得越久越好”是不对的，但理解了48倍这个数字之后，你至少知道为什么长期锁定者能在治理中获得这么高的权重。