本文详细介绍了Compound V3奖励机制,重点分析了与MasterChef Staking算法的相似性及不同之处。文章涵盖了奖励的计算方式、合约结构、用户奖励的索取机制以及潜在的安全隐患,并通过多个截图和示例说明了相关的参数与算法逻辑,深入探讨了Compound系统中奖励的逐步累积与发放过程。
Compound issues rewards in COMP tokens to lenders and borrowers in proportion to their share of the a market’s lending and borrowing.
该算法与 MasterChef Staking Algorithm 非常相似,因此读者应该先熟悉这个算法。
与 MasterChef 类似,Compound V3 奖励合约跟踪一个假设的“质押” USDC 自创立以来赚取了多少。在这里,“质押”可以意味着借款或贷款——这两种活动都会获得奖励。
类似于 Compound V3 的 baseSupplyIndex
或 MasterChef 的 rewardPerTokenAcc
,Compound 奖励有 trackingSupplyIndex
和 trackingBorrowIndex
,分别跟踪自创立以来每个 USDC(借出或借入)获得的奖励。
像 MasterChef 一样,单个 USDC 收集到的奖励在更多 USDC 被“质押”时会“稀释”,反之亦然。
与 MasterChef 不同的是,单位时间的奖励是通过不可变变量 baseSupplyTrackingSupplySpeed
和 baseTrackingBorrowSpeed
设置的。治理有权“重新调整”分发的奖励。
用户从 Comet Rewards 中索取奖励,该合约与主要的 Comet 借贷合约是分开的。
如果借款总额或贷款总额低于某些阈值,Compound 不会发放奖励,原因我们将在稍后讨论。
与 MasterChef 一样,奖励不会自动分配,必须在单独的交易中声明。以下截图显示了索取累计的 COMP 代币的前端,标出索取代币的操作(黄色圆圈)。
Comet Rewards 合约不生成 COMP 代币,而是依赖于治理将代币转移到它那里。当前流通中总共有 1000 万个 COMP 代币,所有代币都已铸造。很大一部分供应量由治理持有。定期,COMP 代币从治理金库转移到奖励合约。你可以看到以下“补充”奖励合约的治理交易。
<https://compound.finance/governance/proposals/194> (2023年11月21日)
<https://compound.finance/governance/proposals/164> (2023年6月29日)
奖励合约的主网地址为
0x1B0e765F6224C21223AeA2af16c1C46E38885a40
由于供应量固定,生态系统参与的 COMP 奖励无法无限期继续,除非治理在公开市场上购买 COMP 代币。
在下面的 Etherscan 截图中,我们看到与合约的大部分交易是索取 COMP 代币(蓝色框),并且该合约当前持有 ~73,000 个 COMP 代币(蓝色箭头)。
下面的图应该是 MasterChef 中熟悉的。更多的 USDC 被“质押”时,每个代币获得的奖励就越少,因为每个周期(由 trackingSupplyIndex
和 trackingBorrowIndex
决定)只发行固定的金额。
一个值得注意的变化是,如果供应或借用的 USDC 金额(粉色线)低于baseMinForRewards
(红色文字和虚线)阈值,则 USDC 不会累积奖励,并且在该状态更新中 trackingSupplyIndex
(或 trackingBorrowIndex
)不会增加。
这些变量不是公开的,但可以通过 CometExt 中的 totalsBasic()
公共函数检索。由于 CometExt 是一个单独的合约,Comet 向其发出委托调用,我们无法通过 Etherscan 获取这些值。相反,我们使用来自 Foundry 的 cast 来检索它们,如下截图所示。
baseMinForRewards 在 Comet.sol 的第 86 行 中定义。
如果借出金额少于 100 万美元(1e12 USDC,因为 USDC 有 6 位小数),Compound 不会向贷款者或借款人发放奖励。同样,如果借用的 USDC 少于 100 万美元,则不会累积 COMP 奖励。...
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!