往流动性池子里白送一笔钱，听起来只会让留下的人高兴。Curve 的池子确实支持这种操作，官方术语叫 donation：把代币直接按 LP 份额比例分给当前所有流动性提供者，不换取任何凭证。但参数表上紧挨着它的一组配置说明，这件事并没有看上去那么直白：解锁时长默认七天、保护期最长默认十分钟、触发保护的增持阈值默认两成，还有一条对捐赠份额占比的上限。这三道闸门分别在防三种不同的坏情况。
先说为什么捐赠要延迟生效。如果不设延迟，捐赠就成了操纵报价的杠杆：攻击者给某个池子转一大笔钱，池子里的余额瞬间变化，价格公式立刻报出一个偏离市场的价，攻击者在这笔交易里接着按这个被推动的价格完成兑换或清算触发，事后再把没花掉的部分收回。把捐赠拆成七天逐步解锁之后，价格影响被摊到时间轴上，任何一秒钟的余额偏移都不再能靠一笔转账制造，靠捐赠推价格这条路径的性价比被大幅压低。文档里那句完成一笔解锁需要的时间，说的就是这个。
第二道闸门保护的不是价格，而是留下的 LP。假设有人宣布要给某池捐赠一大笔，消息公开但解锁还没开始，理性反应是立刻进池分一杯羹——在捐赠到账前挤进来的人按比例领走一大块，原有 LP 的收益被稀释。合约的做法是：当某一笔 LP 增持的比例超过设定阈值，就把保护窗口延长，让新近大额进场者暂时不能按比例领到这部分捐赠，默认上限是十分钟的延长。这样想靠临时挤进来吃捐赠的策略必须精确到极短的时间窗口，而这正是最贵、最容易失败的时机。
第三条是份额占比上限，限制一笔捐赠能产生的捐赠凭证占总份额的最大比例。它把单次捐赠能扭曲分配的程度钉死在一个范围内，避免任何单一操作把分配表整个改写。三条参数合起来，逻辑一致：允许捐赠这个功能存在，但把它从操纵工具降级成一个慢动作、可预期、按比例可核算的分配机制。
现在把它和另一种改账本的手法放在一起对比，差别就清楚了。弹性供应类代币会在协议触发时调整所有人余额，池子如果按名义余额定价，报价就会跟着被推走；那是账户数字变化直接改变了池子的输入。捐赠则完全不同：它确实改变余额，但改变被拉长、被限制、被加锁，而且不产生任何供捐赠者日后赎回的凭证。理解这一层，才能明白为什么在尽调文档里这两件事要分开看——前者要查代币供应机制，后者要查池子的捐赠参数配置。
对普通 LP，这组参数有两层实用含义。第一，如果你看到某个池子出现捐赠记录，先确认它的解锁时长与保护阈值是什么数值，再判断这笔钱的分配窗口落在哪几天；把未解锁的捐赠当成已到账收益去估算你的账面回报，是最常见的读数错误之一。第二，如果你打算因为一笔即将解锁的捐赠而临时加大流动性，请把保护窗口和燃料成本算进决策：这类进出的实际收益往往抵不上两次调仓的开销，更不用提你在池子里多待的那几天要正常承担价格风险。
项目方视角下，捐赠是一种有约束的激励交付方式：想给 LP 送钱但不想发新的激励合约、也不想让奖励长期锁在某处时，捐赠配合解锁时间是一种把承诺写进链上参数的手段。但反过来说，它的可预期性也正是它容易被误用的原因——一旦 LP 习惯某个项目定期捐赠，停止捐赠本身就成了一个可被提前定价的事件，这类激励结构的退出节奏需要单独安排。
因此对任何装了捐赠参数的池子，读它的顺序建议是这样：先读解锁时长与保护窗口的数值，再查是否已有未完成的捐赠记录，然后核对这些参数是否由治理可改、最近一次改动是什么时候；最后再去看手续费和深度。这个顺序反映一个常识——在 Curve 这类池子里，改分配表的权限往往比改费率的权限更少被讨论，但它对 LP 分配的影响更直接。
本文只讨论机制与参数，默认数值取自官方文档的参数说明，可能随版本变化，不构成收益承诺，本文内容不构成投资建议；提供流动性可能出现费用不足以覆盖损耗的情况，请以链上实际参数为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。