# rss3 stake 源码分析了下

By [clicknft](https://paragraph.com/@clicknft-2) · 2022-05-12

---

持仓几千刀这币，最近跌的有点惨，前2天又出了stake,全仓stake进去了，所以也得看下合约源码，是否案例

（下面排版本来在word的，直接粘贴过来了）

Stake里面只要是有distributeRewards和mint里面的\_correctPoints

![](https://storage.googleapis.com/papyrus_images/83a39bcf0d9b888bc17751cb59686a2f58be542d4ba431613e6473a60c5f7105.png)

**Mint staked token**的时候 ，shares是负数，**burn**的时候是正数

先看distribute函数，参数就是每秒奖励的数量乘以上次奖励到现在过去的时间，可以发现这里面的 pointsPerShare 会有更新，这里更新了，上面的correct里面的值就会有影响

getTotalShares 就是staked rss3的 totalsupply函数，（竟然用了函数指针的形式）

pointsPerShare  那这个值就是一个累加+的结果，每份share可以得到的奖励,，例如当前过了1分钟，这1分钟，系统会奖励5个token，然后系统stake了100万rss3的话，那就是5/100w,由于系统没小数，所以需要给他乘一个很大的数，这样就不会丢失数据，因为这只是算份额，不是真实发奖励了，所以没问题，可以在拿奖励的时候，再除掉这个很大的数。

另外，由于是累加，这个值目前看是只会越来越大

越晚stake,pointsPerShare 累计的多大，上面的correct points里面更新的值就是一个越小的负数，例如早的人是 -0.1,晚stake的是 -0.5

![](https://storage.googleapis.com/papyrus_images/b8ae574e476b340dba2ac4b492cd651fcb89da40ddcb8100a6af37107e59eb4b.png)

  

Claimrewards函数

里面的prepare会调用这个withdrawableRewardsOf函数返回这个account当前所有的可领取奖励数（包括已经claim的），返回 这个后，再减掉以前领取掉的奖励（有个变量a1记录），就是rewardAmount了。withdrawableRewardsOf这个函数也会更新a1这个变量

![](https://storage.googleapis.com/papyrus_images/d2507de9e61b9cbde44ca5ab69f8858836341225897e3d9066b95c154a671206.png)

从这个函数实现可以看的出，要想取的更多的奖励，变量因素就是pointsPerShare

和pointsCorrection

这2个变量了。但如果2个staker不管起始时间，只看claim的时间，其实仓位的pointsPershare是一样的，那区别应该就只能在后者的变量里面了，后面这个pointsCorrection变量按上面stake分析，其实它存的是一个负数，那由于他越晚stake,他这个里面的值越小（虽然绝对值大，但是负数），那这整个公式算下来，2个不同时间开始stake的地址，如果他们同时claim的话，越早stake的人得到的claim越大份

  

pointsPershare是保证越长时间，stake奖励越多，所有人都一样，但后面的负数变量就会负越大，公式得出来的结果奖励就越小。

  

所以结论是stake时间越长，奖励越多，即使stake的人多了之后，只是增速减小了而已。因为对于一个已经stake的账号，在公式里面

        return

            ((pointsPerShare \* getSharesOf(account)).toInt256() +

                pointsCorrection\[account\]).toUint256() / POINTS\_MULTIPLIER;

  

后部分的值不会再变，而前部分只会越来越大

---

*Originally published on [clicknft](https://paragraph.com/@clicknft-2/rss3-stake)*