Extend/Top-Up Stake

Users have the option to extend and/or top-up MRHB to their existing stake or to extend the time lock on their stake.

Top-Up

Every user will have a vMRHB that is derived from their staked MRHB and the time left to the expiry of their time lock. Based on these inputs we can allow users to extend time locks and/or add MRHB to an existing stake. Both options would generally be executed by users in order to increase their vMRHB balance or access a higher tier of utility.

We know that vMRHB is derived by multiplying the users MRHB balance by the coefficient for the respective staking period (Time Lock). However, what if a user is 42 weeks and 5 days into their 52-week existing staking period? We do not have a generic coefficient that can derive a new vMRHB balance for the remaining 9 weeks and 2 days of a 52 week staking position. The solution is simple, we derive a time specific coefficient by rearranging the formula as follows:

$$timeSpecificCoefficient = \frac{userExistingvMRHB}{usersExistingStakedMRHB}$$

We can now derive the vMRHB value of any newly added MRHB to a staked position with a given time lock as follows:

$$additionalvMRHB = amountOfNewMRHB * timeSpecificCoefficient$$

Thereon, users’ new vMRHB balance is simply the sum of the existing vMRHB balance and the additional vMRHB balance.math

$$vMRHB = existingvMRHBbalance + additionalvMRHB$$

Extension

What about if a user wants to extend their time lock? If a user extends their time lock, then the vMRHB balance should also change based on the time left on any existing staking period and the increase in the staking period. Let’s say a user has 4 weeks left until the expiry of his/her staking period and decides to extend for another year. We need to deduce a new vMRHB balance for 56 weeks (52 + 4) to expiry. We can do this as follows; establish the total weeks to lock/stake. Which can be done using simple arithmetic.

$$totalWeeksToLock = weeksToExtend + weeksLeftUntilCurrentExpiry$$

We need to ensure that the total weeks to lock/stake doesn’t exceed the max period of 104 weeks otherwise we would need to deduce a coefficient that is outside of our modelling. This could lead to vMRHB balances that require a coefficient larger than the upper 104 weeks bound of 1 and could create some issues. Regardless, we can deduce the users new vMRHB balance for all total days to lock’ less than 104 weeks as follows:

$$additionalvMRHB = existingvMRHBbalance * rewardCoefficientForExtension$$

Whereby the users MRHB staked balance is multiplied by the reward coefficient for the selected extension period to deduce any additional vMRHB balance. The new vMRHB balance is then deduced as follows:

$$newvMRHBbalance = existingbMRHBbalance + additionalvMRHBbalance$$