# MARHABA INCENTIVIZATION AND REWARD OFFERING
Abstract
MIRO is a staking mechanism that adheres to Islamic financial principles and carries the properties of 'vote to earn' and 'stake for access'. It allows users to earn rewards and participate in governance by staking MRHB tokens, the native currency of the Marhaba ecosystem. The longer a user stakes their tokens, the more voting power they acquire and the larger their pro-rata share of the rewards will be. This system encourages long-term commitment and reduces the number of tokens available for sale, which can help maintain the token's value.
Unlike traditional staking models, MIRO follows the Islamic concept of Ju'alah, where users must complete a task for the Marhaba ecosystem before they can claim any rewards. This ensures that staking is more than just a financial investment; it also supports the growth and development of the ecosystem.
Initially, the rewards for staking will be in the form of treasury allocated MRHB tokens, with 100 million tokens allocated for distribution over a four-year period. However, the ultimate goal is to transition to a model where fees generated by the ecosystem are used to buy back MRHB tokens from the market and redistribute them to stakers.
In summary, MIRO is a unique, Shariah-compliant staking mechanism that aims to benefit both the Marhaba ecosystem and its users. By encouraging long-term commitment, active governance, and growth, MIRO hopes to create a stable and thriving financial environment for all.
# Introduction
MIRO staking mechanism was inspired by some of the ‘vote escrowed’ staking mechanisms that exist in the DeFi space, namely Curve’s veCRV staking model. Albeit, with some clear differences catered to ensure the shariah compliance of the model and relevance within our token economy. MIRO is a fixed staking model that aims to allocate voting power in a manner that favors those users who stake MRHB for longer time periods. A user’s voting power will also determine their pro-rata share of the rewards that will be distributed to users. In a nutshell, the longer you stake, the more voting power you get and the higher your pro-rata share of the reward distribution should be. The key difference between MIRO and other ‘vote escrowed’ staking models is that MIRO staking is based on the Islamic concept of Ju'alah[^1]. Whereby users are required to complete a task/objective for the Marhaba ecosystem in order to claim any monetary benefit offered by the staking mechanism. By locking your MRHB for X amount of time, users are unlocking certain utilities, one of which is the right (and not the obligation) to participate in governance in exchange for rewards.
Initially, the rewards we will distribute will be in MRHB via token inflation. We are allocating 100 million MRHB over a period of 4 years. Ideally, we would want MIRO to follow a fee redistribution model whereby any protocol fees are redistributed indirectly to MIRO stakers through periodic MRHB token buy backs. However, considering the Marhaba ecosystem is not at full fee generating potential we will use token inflation for the first 4 years and then transition into a model where any profit is used to buy back MRHB from the open market and redistribute to MIRO stakers. Depending on the viability of token buy backs and redistribution, it may be the case that the Marhaba DAO carries out the redistribution within some other type of framework.
The main objectives behind MIRO are:
1. Reduce floating supply and sell pressure on MRHB token by unlocking further utility and monetary benefit to MRHB holders.
2. Create an incentivized method of governance whereby MIRO stakers are required to participate in governance in order to earn rewards/protocol profit. Those users who stake for longer will have more voting power than those who stake for shorter time periods.
3. Create a model whereby staking MRHB allows for community driven governance.
4. Unlock certain utilities and benefits across the Marhaba ecosystem in a ‘stake for access’ style mechanism.
5. Transition into a fee redistribution model that captures economic flow of value once the Marhaba ecosystem is at full fee generating potential.
[^1]: Ju’alah is a contract in which one of the parties (the Ja’il) offers specified compensation (the Ju’l) to anyone (the ’Amil) who will achieve a determined result in a known or unknown period. (AAOIFI, 2017, Shari’ah Standard No. 15, 2)
# Design Overview
vMRHB, Reward distribution, APR’s, Utilities & Tier structure and more...
vMRHB is essentially just an arbitrary value contained in the smart contract that represents a user’s voting power. It is derived by multiplying the MRHB amount to be staked by a time specific coefficient.
We will allow users to lock MRHB for 13 weeks, 26 weeks, 52 weeks and 104 weeks. A user will lock their MRHB and receive the following coefficients for the specific time periods:
* **13 weeks**: Coefficient of **0.1**
* **26 weeks**: Coefficient of **0.21**
* **52 weeks**: Coefficient of **0.45**
* **104 weeks**: Coefficient of **1**
Each balance of MRHB locked will be multiplied by its relevant coefficient to deduce a vMRHB balance, which is in essence the users voting power and weighted value used to calculate their pro-rata share of the Ju’alah voting rewards (MRHB emissions).
$$
vMRHB = MRHB \* Coefficient
$$
The idea is that all vMRHB balances will decrease weekly in a linear distribution until the user’s stake reaches expiry. A user with 1000 MRHB staked for a 104-week period will have a starting vMRHB balance of 1000 that will decrease linearly until it reaches close to zero in week 104. (We will explain the reasoning behind this in later sections).
$$
vMRHB\_{ws} = vMRHB\_{principle} \* (1 - \frac{w}{s})
$$
Where ***vMRHB*** Principle is the initial vMRHB balance of the user at week 0.
Where **(S)** is the user’s staking period in weeks.
Where ***(w)*** is the week (1 <= w <= S).
Example
For example, user (A) who has staked 1000 MRHB with a staking period of 52 weeks has a vMRHB balance of 450 vMRHB. By the time the user approaches 26 weeks into his stake period he should in theory have the same vMRHB as user (B) who has just started staking 1000 MRHB for 26 weeks. However, he will still have a slightly higher vMRHB balance even though both users have the same principal and staking period. User (A) will have a vMRHB balance of 225 whereas user (B) will have a vMRHB balance of 210. This is to reward those users who stake for longer. The difference is not colossal and still ensures fairness in voting power and reward distributions for any Ju’alah activity.
Any single user can only have ***one stake per wallet*** meaning that no one wallet can have more than an amount of MRHB staked for a certain time period.
For example, if a user has X amount of MRHB staked for Y time period, they cannot initiate a new stake with a different amount of MRHB and a new time lock/time to expiry.
# 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
$$
# Token Emissions
Token emissions for initial MIRO campaign will be come through inflation using a linear increasing distribution model.
We will release MRHB emissions in a linear increasing distribution rather than a linear decreasing distribution. Although setting a linear decaying distribution would generate a higher APR/vROI initially and incentive quicker lock ups and participation in MIRO, we would risk having a lower APR/vROIas more MRHB enters circulation over the next 2 years from events such as vesting unlocks. A linear increasing distribution is a more sustainable model that is parallel to the amount of MRHB entering circulation, ensuring the APR/vROI is viable over the 4 years. We have designated to use MRHB token inflation to support MIRO rewards before transitioning to a fee-redistribution model. We have decided to emit ***100M MRHB over the next 4 years*** and we can use the following linear increasing distribution:
$$
W{av} = \frac{x}{52y}
$$
Where (***Wav***) is the average amount of MRHB to be emitted per week and (***y***) is the number of years this staking model will be implemented. To breakdown distribution further see formula below:
$$
M{w} = W{av(1-\frac{52y+1-2w}{52y}D{c}})
$$
Where (***Mw***) would be the scheduled number of tokens to mint on Week (***w***)
Where (***y***) would be the number of years.
Where (***w***) would be the week, (i.e. 1 to 208 for a 4-year distribution)
Where (***Dc***) would be the increasing coefficient (0 <= Dc <= 1, the higher the number the steeper the increase in emissions)
### Emissions
On the Thursday of every week (approx 00:00 UTC) MRHB will be sent to the staking contract in line with the scheduled amount derived by the above formula. As we transition into a fee redistribution model the above formulas and schedule will become redundant and the amount of rewards entering the staking contract will become less predictable.
# ROI and Reward Distribution
Pro-rata shares of the weekly rewards will be distributed to eligible users.
As mentioned previously, a user’s vMRHB balance also determines their pro-rata share of the weekly reward distribution sent to the staking contract. Every ***Thursday (approx 00:00 UTC)*** the scheduled number of rewards will be sent to the staking contract whereby each user can see what their expected reward will be if they participate in governance (via executing their voting power). We can compute a user’s expected weekly reward as follows:
$$
V{r} = \frac{Users vMRHB}{Total vMRHB}
$$
Where (VR) is a ratio-based variable used to identify the users vMRHB weight as a percentage of the total vMRHB.
We can compute pro-rata weekly reward for a single user who has a vMRHB balance as follows:
$$
R{w} = V{r} \* M{w}
$$
Lastly, the estimated vROI (variable return on investment) for the user can be computed as follows:
$$
Users {vROI{w}}= \frac{(R{w})(52)}{UsersStaked MRHB}
$$
***The vROI is just an estimation of what a user can expect to receive based on the value of the variables (Mw, Total VMRHB, etc) computed on that day***. *This vROI can change daily as all these variables are constantly changing.*
{% hint style="info" %}
*It is important to note that the **vROI** a user sees when they initially stake is **not** necessarily something they should go by to calculate what they can expect to earn over a year. The vROI calculation is derived by multiplying the users potential reward on a given week (via initialising a stake) by 52 weeks and then dividing by the MRHB Amount to be staked. **The weekly reward and total amount of vMRHB is variable so is the ROI, hence why it is called vROI.***
{% endhint %}
The vROI is designed to favor those who stake for longer periods. If we were to assume that all users had the exact same staking periods, there would be no weighted difference in their pro-rata ratios and every user would have a vROI that follows:
$$
Average { vROI{}} = \frac{52}{MRHB{w} + \xi } (M{w})
$$
Where (***MRHBw***) is the sum of all (**MRHB**) values (sum value of all MRHB deposits included in the staked MRHB mapping for the relevant week (w))
Where (***Mw***) is the scheduled amount of MRHB tokens to be minted for that week.
Where (***Ɛ***) is a small number such that ensures the APR/vROI calculation is not zero due to no deposits being made into the staking contract.
Case Study
If the average/general vROI is 10% we can assume that if all stakers had vMRHB balances deduced with the exact same coefficients (indicating that everyone is staking for the same time period), then the vROI for all stakers would be the same and equal to the average/general vROI. However, if this is not the case and we have users with different staking periods, then the APR/vROI for each user would fall within some range either higher than the average/general APR/vROI or lower.
It is important that a user’s vMRHB diminishes over time as the staking period approaches zero and therefore so does the user's vROI. For example, if we have a total vMRHB of 1 million, a weekly emission of 5K MRHB and a user decides to stake 1000 MRHB for 104 weeks, the estimated vROI range would be calculated as follows:
* Starting vMRHB: 1000 MRHB \* 1 (104-week coefficient) = 1000 vMRHB
* Ending vMRHB: 1000 MRHB \* 0.1 (13-week coefficient) = 100 vMRHB
* Starting Rewards: (1000 vMRHB / 1,000,000 vMRHB) \* 5000 MRHB = 5 MRHB
* Ending Rewards: (100 vMRHB / 1,000,000 vMRHB) \* 5000 MRHB = 0.5 MRHB
Therefore, using the ‘Users vROI’ formula, the users estimated vROI range over the period of 104 weeks would be as follows:
Starting vROI (26%) -> 2.6% at 13 weeks -> ends at 0%
# Utilities and Tiers
Depending on staked amount and time users will be placed into three tiers with each tier having its set of utilities.
We will assign utility and voting power mainly based on the amount of time a user locks their MRHB and the amount of MRHB locked. All stakers regardless of the amount staked will receive the following base utility and be placed into default **"Bronze" tier**:
1. Voting power
2. Access to Ju’alah based voting rewards
3. Access to Shariah Portal
### Special Tiers
Silver
50% LH Fee Reductions
50% Souq Fee Reductions
Entry to NFT Drops
20% Referral Bonus
Entry for Early Access
Gold
75% LH Fee Reductions
75% Souq Fee Reductions
Guaranteed NFT Drops
30% Referral Bonus
Guaranteed Early Access
# User interactions
This is a basic description of how to navigate the complexities of the MIRO portal
1\) A new staking week is initiated every Monday from 00:00 UTC to 24:00 UTC. If a user joins or initiates a stake on any day outside of Monday (signalling the start of a new weekly session) their starting date will be pushed to the next Monday (UTC timezone). For example, if a user initiates a stake on a Wednesday of week 1, their start date will be pushed to the following Monday of week 2 and the first voting session the user can participate in will be on the Friday of week 2. This is done to ensure that the reward distribution is fair for all users that have been staked for week 1. It therefore makes more sense for all users to start their stake on a Monday, albeit if they don’t mind being placed in a queue until the next weekly session then they can stake at any time. Staking on a Sunday of week 1 is a short queue time until monday of week 2.
1 vMRHB = 1 vote. Therefore, any stakes that do not equate to 1 vMRHB will not be eligible to vote and subsequently claim any rewards
2\) Every Thursday evening (Approx 00:00 UTC) the Marhaba DAO will send the scheduled amount of MRHB tokens for that week to the staking contract. Once this is done, a user will be able to see what their ‘Weekly Reward’ would be if they were to exercise their voting power. The voting portal will open up after the MRHB tokens are sent to the contract. The voting portal will be open for 3 days for all users to vote on any approved proposals. Once a user votes, their ‘Weekly Rewards’ for that week will become ‘Claimable’ and can be claimed at any time. If a user fails to vote during this window, then they will forfeit their weekly ‘Weekly Rewards’. Those forfeited rewards will be added to the rewards for the following week to be shared amongst users. Therefore any rewards that are unclaimed are cumulatively added to the following weeks rewards for all stakers to share.
3\) Because people are in different time zones and weekdays will differ for different users depending on where they are, we will use a generic timezone of UTC (GMT+0) and implement an hourly countdown. The countdown will signal the end of a week and the beginning of a new week. It will start at 168 hours and once the week has 72 hours left (friday - monday) until the new week starts the front end will display that the voting portal is open. Once a new week starts there will also be a 24 hour countdown to allow new stakers to join otherwise any new stakers will be placed in a queue for the following week. We will use the following color theme in conjunction with the countdown:
**Green** = new week has started with 168 hours and users have 24 hours to join or they will be pushed to the following week if they still decide to stake.
**Yellow** = when 24 hours have passed and hours remaining until new week is 144.
**Red** = When 72 hours are remaining signaling that rewards have been deposited to the contract and the voting portal is open. After 72 hours a new week of 168 hours will start.
Once the voting portal opens up, a user only needs to place one vote in order to claim their rewards. The user is however free to vote on as many proposals that exist. The user is also free to distribute or allocate their voting power (vMRHB) across as many proposals as they wish. It is advised that users exercise all of their voting power for that week. Each week the users voting power will reflect their vMRHB balance. If the user exercises all of their voting power for that week it will be renewed in accordance with their vMRHB balance for the following week.
A user can **top up** their existing stake with more MRHB and/or **extend** the time lock on their existing stake **only if they have an active vMRHB balance and the voting portal is not open**. vMRHB balances that start in the following week are considered inactive. They become active once we enter into a new weekly session. Top Up/Extend is disabled for the 72 hour voting session. This is to ensure that once voting commences the reward received by users doesn't change.
Both Top Up/Extend will increase a user’s vMRHB balance and in essence their voting power and pro-rata share of the weekly rewards. The reason behind doing this would be due to the decreasing nature of vMRHB and subsequently the users voting power and share of rewards.
\
# Proposals, Voting and Contributions
The voting and governance portal will initially be a rudimentary means of achieving a level of community participation and governance while the project is in its infancy. It will initially just serve the purpose of building community participation, identifying core contributors/participants and laying the foundations for the Marhaba Protocol to transition into a more robust and comprehensive Governance system in the coming years.
1\) Only users with a active vMRHB balance can create proposals
2\) In the early stages all proposals will be filtered by the internal team before being approved for voting.
3\) Not all proposals will be used to drive governance and changes to the Marhaba ecosystem. Proposals can also be used as a means of providing contribution. **Governance points** will be given to those users who provide contribution and support via proposals and community engagement in both the governance portal and Shariah portal. The Marhaba ecosystem wants to identify those users/participants who have backgrounds in Shariah, coding/development, DeFi/Islamic Finance, etc.
4\) There will be a private thread between users and admins such that the Marhaba team can reach out and reward quality and consistent contribution through employment prospects, gifts, merchandise, special invitations etc. The MIRO Portal admins will be responsible for reviewing all discussions and proposals then assigning governance points as they see fit.
5\) The Shariah Portal is another component of MIRO where users can create threads and topics for discussion or requests for support. It will also serve as the place where the majority of Marhaba's Shariah based analysis and content will be uploaded.
\
