Posted on behalf of the mStable ProtocolDAO
The full MIP-15 can be accessed here. Technical Specification has been left out in this forum post.
It is proposed to overhaul the MTA staking mechanism with an updated release: Staking v2.
Since mStable’s inception, MTA staking was a core part of the protocol that allows MTA stakers to govern the mStable protocol and earn rewards. The initial staking duration was set to expire on the 1632580257 (Unix timestamp) ~25th September 2021. With this expiration, a new overhauled staking mechanism is proposed to improve upon the lessons learned from the first iteration. Additionally, this is an opportunity to create a more immersive staking experience. Core concepts are delegation, gamified governance, scaled voting and earning power, and a cooldown with an unstaking window for withdrawals to support usage of the collateral in recollateralisation.
The staked token is a non-transferable ERC20 token. Stakers can choose to stake MTA or 80/20 MTA/ETH Balancer Pool tokens.
Since the inception of mStable, MTA staking was at the very core of the protocol. It allows the community to govern mStable itself, earn rewards and potentially earn a share of the revenue in the future. Part of the emission of MTA goes to stakers to incentivise staking and governance participation. The first iteration of the staking contract was successful with the goal that a big portion of the MTA was locked into the staking contract.
However, as the current maximum staking duration expires at 1632580257 (Unix timestamp), a new iteration of that contract is opportune and would allow improving certain aspects detailed in this proposal. These are based on lessons learned from the first staking contract. Additionally, new concepts can be integrated into the staking contract, which would allow for mechanisms to make staking more fun, engaging and reward participation in a unique way.
The core concepts are delegation, scaled voting and earning power, and a timelock with a cooldown period for unstaking. In addition, a new token contract would allow for more interactive governance participation and open up a whole new venue of gamified governance. These and other contract designs are specified in this proposal. Stakers can choose MTA or 80/20 MTA/ETH Balancer Pool tokens. The staked token itself is a non-transferable ERC20 token
This proposal seeks to improve the staking and community experience and increase value for stakers in the long term, fostering a dedicated community around mStable on the way to increasing decentralisation with increased participation that is rewarded. Furthermore, this proposal opens up the possibilities to integrate a gauges system for reward distribution that is planned for an upcoming release.
The option to extend the maximum lockup with the current iteration of the staking contract was considered, but an overhaul of the staking mechanisms was deemed as the better choice since it allows to evaluate the design of the previous staking solution and improve the staking experience with this release. This release addresses the following lessons that were learned from the previous staking contract:
Every change in the protocol and every use of the treasury requires all staked MTA holders to participate in governance. No matter how important, big or small that change is. This requires staked MTA holders to actively participate in the votes on a regular basis. However, not every staker is staying up to date with the latest proposals in mStable. Nor is every staker an active governor and community member that engages regularly in governance discussions. To allow maximum participation rates and to give every staker the chance to inform themselves about the proposal, each vote had to be available for an extended period of time. This had the result to slow down the governance process while not significantly improving participation rates.
Governance votes that require a quick resolution are being avoided due to this slow self-imposed process. Despite the length of the votes to allow for all stakers to participate, voter fatigue is prominent and vote participation gradually decreased over time.
At the very early stage of mStable, governance participation rates were acceptable. Over time, these rates decreased further and further as more proposals were needed to pass governance. At the current state, only around 30-50 voters out of more than 800 actively participate in the votes (4-6%). This shows that the majority of MTA stakers are passive investors and don’t seek to participate in day-to-day or week-to-week governance. On the flip-side, there are also very active community members and stakers who are participating in most of the votes and engage in discussions in the forum and on discord very actively. Staking v1 made no distinction between these two different user groups. Furthermore, no quorum thresholds for voting results could be established, since the participation rate is low and a meaningful quorum would require that the majority of MTA participate and back a proposal.
A key aspect of the old staking mechanism is the decay of voting Power and earning Power (vMTA and pMTA). Both decrease over time. This decay resulted in confusing reward and boost calculations that are not easy to understand and discouraging for new stakers. A boost calculation was supported by the UI for an estimate of the necessary vMTA to receive a certain boost; however, as the vMTA decayed the user needed to adjust the staked amount i.e. increase staked MTA continuously requiring on-chain transactions that can be very costly at times. This caused many incidents in which the users had trouble conceptualizing this mechanism and requiring further assistance in the mStable support channels. A more intuitive mechanism would improve the staking experience for users and evoke a sense of reward rather than discouraging participation due to the decaying of voting and earning power.
To mitigate the previously outlined issues, core concepts of this proposed updated staking contract are
- delegation for mitigating voter fatigue, while engaging active participants
- delegation for the possibility to design more effective governance systems
- static balance with multipliers instead of decaying voting power
- lock up of MTA or 80/20 MTA/ETH Balancer Pool tokens with cooldown and unstake window
- gamified governance with quests that allow earning multipliers to increase voting power and earning power
This new staking release is detailed in the next sections in more detail.
Delegation is commonly defined as the shifting of authority and responsibility for particular functions, tasks or decisions from one person to another. In our case, we want governance votes to shift from passive stakers to active governors. Currently, any staker that does not vote, receives no representation either. The result is that the majority of the vMTA is not used for governance and therefore has no voice.
With this proposal, the delegation would enable a representation for MTA stakers that do not have time or capacity to actively engage in governance. The delegator could shift their voting power to a trusted community member or governor. It would shift the focus away from voting with raw token power and add the element of reputation into the staking mechanism. A delegatee on the other hand that has voting power delegated to, would act on behalf of their delegates and needs to weigh every decision for voting in the light of the broader picture. A delegatee that misbehaves and does not act in the best interest of the delegator, would lose voting power to one delegatee that is more aligned with the interest of the delegator, due to gaining a bad reputation that would shift delegation away to another delegatee. This mechanism allows for a higher participation rate of the staked MTA and a fair representation for all stakers, regardless of time commitment or amount of MTA.
Active members are devoting more time to the governance process, make more informed decisions on what is best for mStable and the ecosystem. This should make governance more meaningful since more of the staked MTA is used for voting. As a next future step, Quorums could be defined to further legitimise proposals with high stakes.
A core concept of DeFi is decentralisation. This necessitates a governance model that allows every holder of MTA to contribute and participate in governance if they choose so. DeFi governance models were mostly influenced by real-life governance processes, this being a representative or direct democracy, and are yet to explore new mechanics that the technology uniquely enables. Smaller stakers that own a relatively small amount are not encouraged in participating, since their share of votes is low and in absence of other incentives are not regarded as meaningful enough.
DeFi is in a unique position to reinvent governance processes by providing users with mechanisms that go beyond mere voting in governance. A neglected aspect of governance is gamification - allowing users to gain a sense of progress while rewarding participation and full-filling tasks with tangible incentives. These incentives come in the form of multipliers that could be unlocked from fulfilling quests. These quests help mStable to guide and mobilize the staker community by incentivizing them with a particular task while also allowing members to earn higher rewards. This way the community can be a powerful driver with supporting the protocol in a meaningful way other than just governance centric participation, such as promoting posts on Twitter.
The way that participation in governance and other actions can be rewarded is via a proposed scaled balance. This balance would be derived from the staked balance that gets scaled up according to the fulfilment of set requirements. One of these requirements is a time derived multiplier. The longer the user stakes, the higher the multiplier. This is a way of encouraging long-term commitment. A long duration of staking has an increasing potential to earn more and therefore is unlikely to be withdrawn.
The other way to increase participation is quest multipliers. These quests can be anything from voting on proposals to more elaborate tasks. This allows committed and active stakers of the community to be mobilized to help the ecosystem for a given cause. Quest multipliers are verified via signatures from the staker and added to the chain via a trusted signer address that aggregates the signatures from the signers and calls a function on the staking contract to mark these quests as completed on-chain.
Both multipliers increase the voting power and the earning power. This allows to distribute more MTA towards active participants and give them a bigger voice when it comes to governance over the protocol.
The new proposed staking contract seeks to address the issues outlined in the previous section and to improve the aforementioned mechanics to create a better staking experience and improved governance processes.
To address those issues, these specifications outline the various mechanics build into the new staking contract.
Before the user commits to staking, the option to delegate their voting power is available. A choice between a minimum of 10 delegates is embedded in the UI to give enough choices for the user. These roles will be filled with prominent community members but are generally open to anyone who would like to actively participate in governance. The delegation is an Implementation of ERC20VotesUpgradeable from OpenZeppelin. The staker can choose to self delegate or delegate to an address at the initial staking operation or any time after the MTA has been locked up. Being able to change a delegation is crucial to avoid the concentration of voting power and to hold delegatees accountable for their votes since failure to participate or malicious participation can be addressed via this change.
The staking and locking of MTA are at the very core of this proposal. It opens up the voting and allows a staker to benefit from reward emissions. Upon staking, the user receives either stkMTA (staked MTA or raw staked balance) or staked Balancer Pool tokens. Like in staking v1, this is a non-transferable token and rewards accrue via the same contract. Unlike the staking iteration v1, this staked token does not decay over time and the rewards are not vested for a period of time. The staked amount in MTA becomes the raw balance that can be further increased with multipliers to receive scaled balance Hence voting power and earning power is based on the scaled balance after each multiplier is factored in.
The scaled balance is calculated as:
with being the raw staked MTA amount, the time multiplier based on the length of staked duration (see table below), and the multiplier for quests.
Governance should be fun to participate in, interactive and not be limited to proposals or voting alone. Therefore, to incentivise participation and engagement, a quest mechanism is included in this release. The stakers scaled balance is increased with the fulfilment of quests. The multiplier increases a staker’s scaled balance as shown in the equation above.
The multipliers for the quests themselves are summed up and divided into 2 different types; for multipliers that are only valid for a limited length of time the so-called season and for multipliers that are added permanently and that don’t expire. The length of a season is set to 9 months and the set
questMaster can start a new season and set the quests from the previous seasons to expire. The
questMaster is the set address that has permission to add new quests and can control the state of the existing ones. This mechanism would allow the staker to earn a multiplier for a predetermined amount of time with a dampening factor in the form of a new season to allow everyone to start fresh on an equal level at the beginning of a new season.
The overall multiplier for the quests can be calculated as:
The range for multipliers, either or can only bet set between . The values are to be chosen conservatively, since they can increase the vote and earning power, especially for permanent multipliers. A quest duration cannot be set lower than 1 day but can be set for an extended amount of time.
To incentivise long-term staking, a time multiplier is applied. This multiplier is dependent on the length of weeks the MTA remains staked:
|less than 13 Weeks||1|
|longer than 103 Weeks||1.6|
For the staked duration, the
weighedTimestamp is used. This means that if the staker locks more MTA after the initial staked amount, the
weightedTimestamp will be recalculated linearly with the relative amount by which the stake increases. The more the user re-stakes, the closer the
weighedTimestamp approaches the current timestamp.
Redeemers must signal their request for a given amount to withdraw by entering a 3 week cooldown period. This period is followed by an unstaking window of 2 weeks during which the requested balance can be withdrawn. Partial withdrawals are possible. If the unstaking window period expires without the staker initiating the withdrawal, a new cooldown period needs to be initialised. During the cooldown, the voting and earning power for the amount that was chosen to be withdrawn is removed as the staker has signalled to exit with that amount. If the staker only partially withdraws his stake, voting and earning with the remainder of the locked amount is unaffected.
To avoid users withdrawing early and potentially exploiting the governance process with e.g. purchasing MTA for a short-term only, swaying a vote and thus consequently unstaking, an early withdrawal is charged based on the following equation:
With as the weeks since the user has staked. For the
weightedTimestamp is used, which would affect the staked duration if the staked amount increases. After week 48 the fees would be 0% for all withdrawals. The maximum fee is 7.5% for staking shorter or equal to 3 weeks. The graph below shows the gradual decay of the fee until it crosses 0% after 48 weeks.
Both the cooldown and unstake window and the early withdraw fee act as a backstop to early withdrawals in situations when the protocol experience a stress event. Initially the
collateralisationRatio is set to 100% and the
slashingPercentage is set to 0. But this can be changed in the future by governance and the staked MTA could then be used for recollateralisation.
Only whitelisted contracts can call specific functions within this contract, in particular for staking and unstaking. This is in order to avoid tokenised wrappers that could potentially circumvent the unstaking procedure and create a secondary market for staked MTA. Contract addresses can be whitelisted via MCCP, if governance deems that the intention of the wrapper contract is a net benefit to mStable.
Pending no significant changes to its content, this proposal will be taken to snapshot vote on Monday, 6th September 2021. Voting will be open for a 5 days window to give adequate time for a concurrent discussion. Governors can change their vote at any time should the discussion sway their decision. We look forward to hearing what MTA token holders have to say and seeing how they cast their votes.