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

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

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

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

Claimrewards函数

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

从这个函数实现可以看的出，要想取的更多的奖励，变量因素就是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;

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