Holder Rewards

Using the potential of the Liquid Proof of Stake, the protocol delegates provided MKL liquidity for the bakers. All the rewards (including all the donated MKL or MKL sent by mistake to the default entry point) received by the pair are distributed between all its liquidity providers.

To make distribution fair, the proportion split between users depends on two measures: user shares in the pool and duration of the providing tokens. The larger the amount and the longer it is kept, the bigger the reward the user should receive. The reward is collected during the 30 days and is linearly distributed throughout the following 30 days.

To come up with the formulas, the following example is considered. Let us suppose that for a certain period the following events take place:

A - Alice initializes exchange, provides initial liquidity and mints the first 1000 shares.

B - The reward period has ended and 400 collected MKL are distributed

C - Bob invests assets and mints 500 shares.

D - The next reward period is finished and 200 collected MKL are distributed.

E - Alice divests assets and burns 800 shares.

F - The next reward period has ended and 500 collected MKL are distributed.

The events A, C, and E have an impact on the total number of shares supplied and, as a result, affects the user’s portions in the pool: if new shares are minted the other portions relative to the total supply reduces, and if some shares are burned, the other shares become more significant.

The events B, D and F are related to reward distribution and depend on how many MKL were collected as baker rewards or donations during the period.

The reward is collected for 30 days and then the reward distributed per second for the next 30-days is calculated. The reward is distributed proportionally among all the shareholders during the period.

Theoretically:

$$secondsPer30Days = 2592000\space(1)\\ rewardPerSec = rewardPerLast30Days / secondsPer30Days \space (2)\\ rewardPerPeriod = rewardPerSec*secs \space (3)\\ rewardPerShare = prevRewardPerShare+ rewardPerPeriod/totalShares \space (4)$$

The user's reward depends on the number of shares as well as the durations of holding these shares. The reward per the period where the shares were constant are calculated as:

$$userRewardPerPeriod = shares * (currentRewardPerShare - userLastRewardPerShare) \space (5)\\ userLastRewardPerShare = currentRewardPerShare \space (6)\\ newUserReward = prevUserReward + userRewardPerPeriod \space (7)\\$$

Therefore the following formulas can be applied for a longer period with multiple durations but a constant total supply and user shares during the period:

$$rewardsPerShare = \sum_{i=1}^n rewardPerPeriod_i / secondsPer30Days \space (8)\\ userReward = \sum_{i=1}^n userRewardPerPeriod_i\space (9)$$

With regards to practical implementation, updating the values every second is impossible. This is why a user's reward is updated on contracts only under the following circumstances:

• If the user’s shares are going to be changed (before share transfers, providing and removing liquidity)

• If the reward is going to be claimed.

Consider the reward per share chart that illustrates its changes with time.

At point A, the reward per share is zero because no reward has been collected yet. During the first cycle, no rewards are distributed as no rewards were collected in the previous cycle. At point B, the rewards per second should have changed, however, in the contract it only occurs at point C when Bob invested more liquidity, incremented the total supply, and updated the contract state. As a result of there being more shares in the pool than according to (4), the stale reward for the second reward per share will increase at a slower pace.

At point D, the curve slightly changes as the reward per second is recalculated based on the rewards collected during the cycle. Theoretically, the curve grows linearly up to point E where Alice divests her shares. 800 shares were burned and as a result, more rewards per account for each share was produced. The rewards per share curve grows even quicker than between point A and C.

The step curve shows the real contract storage.

Considering the user’s reward changes, the total reward grows linearly even after the first cycle has ended. Alice's reward increases linearly between point A and C and fully matches the total reward. However, it slows down after point C as a result of Bob's new shares. After divestment at point E, it grows even slower because Alice's part in the pool is smaller than Bob's.

Bob's rewards start to be assessed at point C because the user doesn't have any shares before and thus can't get any reward. It linearly increases until it reaches point E where its growth speeds up. Since after this point Bob's shares prevail over Alice's, is expected to receive more reward than Alice.