业务逻辑
目前 KUN 治理挖矿已经开发完成,当前业务逻辑为:
-
活动时间两年(96 周,可调整),共开设48期活动
-
每期时间 2周(可调整)
-
必须满足
活动时间 = 每期时间 * 活动期数
且 活动时间 和 每期时间 必须在活动开始之前决定,中途不可修改
-
对于第 n 期活动,存在三个因素影响发放挖矿奖励:
- 第 n 期最大发放数量 reward
- 第 n-1 期实际锁仓数量 stake
- 第 n-1 期锁仓目标 target
那么第 n 期的实际奖励数量为
(stake / target) * reward
-
对于第 1 期活动,则默认按照最大奖励数量发放,即发放量为 100% * reward
-
对于用户 A,他可得的实际奖励为
锁仓占比 × 当前发放速率 × 当期已锁仓的时长 = 锁仓占比 × (当期实际奖励数量 / 当期总时间) × 当期已锁仓的时间
投票
按照目前的合约逻辑,在锁仓挖矿上线之前,必须制定好的参数为
- 活动时间(例如 96 周)
- 每期时间(例如 2 周)
- 第1期的发放数量,锁仓目标
对于锁仓奖励的参数设置,基于上述设计思想,现有以下两套方案:
方案 1
活动开始之前就确定好每一期的 最大发放数量,实际锁仓数量,锁仓目标。此为当前合约的实现逻辑,只要参数定好,可以即时开启锁仓挖矿。
但是,方案1的缺点是,一但开始挖矿,就不能再做修改,无法根据后续KUN的锁仓情况做调整,缺乏灵活性,需要挖矿的配置参数有很强的预测能力。
方案 2
每期活动进行时可以投票决定后面活动的奖励数量。例如,在第 n 期活动时可以决定
- 第 m 期(m > n)活动的最大发放数量,锁仓目标
此方案较为灵活,但是目前合约不支持该方案。如选择此方案,需要进行开发测试,上线时间待定。
目前对于两种挖矿参数设置,需要社区投票,决定采用哪种形式进行。