Kun治理挖矿方案分析

业务逻辑

目前 KUN 治理挖矿已经开发完成,当前业务逻辑为

  1. 活动时间两年(96 周,可调整),共开设48期活动

  2. 每期时间 2周(可调整)

  3. 必须满足

    活动时间 = 每期时间 * 活动期数

    活动时间每期时间 必须在活动开始之前决定,中途不可修改

  4. 对于第 n 期活动,存在三个因素影响发放挖矿奖励:

    1. 第 n 期最大发放数量 reward
    2. 第 n-1 期实际锁仓数量 stake
    3. 第 n-1 期锁仓目标 target

    那么第 n 期的实际奖励数量为

    (stake / target) * reward

  5. 对于第 1 期活动,则默认按照最大奖励数量发放,即发放量为 100% * reward

  6. 对于用户 A,他可得的实际奖励为

    锁仓占比 × 当前发放速率 × 当期已锁仓的时长 = 锁仓占比 × (当期实际奖励数量 / 当期总时间) × 当期已锁仓的时间

投票

按照目前的合约逻辑,在锁仓挖矿上线之前,必须制定好的参数为

  1. 活动时间(例如 96 周)
  2. 每期时间(例如 2 周)
  3. 第1期的发放数量,锁仓目标

对于锁仓奖励的参数设置,基于上述设计思想,现有以下两套方案:

方案 1

活动开始之前就确定好每一期最大发放数量实际锁仓数量锁仓目标。此为当前合约的实现逻辑,只要参数定好,可以即时开启锁仓挖矿。
但是,方案1的缺点是,一但开始挖矿,就不能再做修改,无法根据后续KUN的锁仓情况做调整,缺乏灵活性,需要挖矿的配置参数有很强的预测能力。

方案 2

每期活动进行时可以投票决定后面活动的奖励数量。例如,在第 n 期活动时可以决定

  • 第 m 期(m > n)活动的最大发放数量锁仓目标

此方案较为灵活,但是目前合约不支持该方案。如选择此方案,需要进行开发测试,上线时间待定。

目前对于两种挖矿参数设置,需要社区投票,决定采用哪种形式进行。

1 Like

方案二的话,大致需要多少时间开发测试呢?

方案一的话,是否支持最大发放数量和锁仓目标这两个参数设置为由其他变量决定的函数?

方案二,确定要开发的话,要到下周能上线,这块主要是需要测试比较多
方案一,这个不支持,只能是设置好为一个固定的值,而且即使是方案二的话,也是在活动时设置为一个固定的值,而不是函数

如果活动总时间改成两周,共开设1期,这样设置,然后每次结束再重启。这样是不是方案一就等于等待改的方案二了?

然后也可以不用再多一周的的测试上线时间?

个人认为,当务之急是在保留参数机动性和系统安全的前提下尽快上线,所以如果我上面说的这种方式成立,那么第一期完全可以先进行参数投票,尽快上线,后面再花时间代码层面慢慢改成方案二的代码。

活动时间和每期时间必须在开始前定好,要改成这个方案仍然需要修改代码,且工作量大于方案二

1 Like