Safety Module

The Mana Safety Module (SM) is a core protocol insurance layer designed to protect against deficits ("shortfall events") in Mana’s lending markets. Users stake MANA, receiving stkMANA in return. In the event of a shortfall, up to 30% of the module’s assets can be auctioned off to cover the deficit.

• Staking Module: Users lock MANA token and earn reward (Safety Incentive).

• Auction & Backstop Modules: On a shortfall, an auction mechanism sells off staked tokens, with a backstop pool providing a price floor to protect MANA’s value.

• Cooldown Mechanism: Withdrawals after unstaking are subject to a 20-day cooldown

StakedMana

Contract to stake MANA token, to be connected with a slashing mechanism in the near future in order to secure the Mana protocol, forming the so called Mana SM (Security Module). Holders of Mana tokens stake them in this contract, they receive equivalent amount in stkMANA tokens and start accruing rewards in MANA; rewards previously configured on the father contract ManaDistributionManager by the a trusted EMISSION_MANAGER. Once they accrued MANA rewards, they can claim them at any moment but, to withdraw their staked MANA tokens, they need to activate and wait a cooldown period, and withdraw just after it, during a withdrawal time window.

Logic

This contract allows to do the following:

• Stake MANA tokens to start accruing rewards: through the stake() function. The MANA tokens will be locked in this same contract, and stkMANA tokens will be minted for the user in the same proportion as MANA staked, the state in the father ManaDistributionManager will be updated and the timestamp of the cooldown will be updated too.

• Withdraw staked MANA tokens: if an user has stkMANA, he can call the redeem() function, burning the stkMANA and receiving the same proportion of previously staked MANA. The withdrawal will only suceed if the user in on the withdrawal window after the cooldown period.

• Activate the cooldown period: self-explanatory, calling the cooldown() function and needed to withdraw the staked MANA.

• Claim the accrued rewards: by calling the claimRewards() function, used to update the state and transfer to the user the accrued rewards, consequence of the time he was/is staking.

• Query information about users: about their rewards or cooldown period.

Cooldown period

The main objective of the cooldown period is to avoid situations on the future Security Module when, if an slashing event happens, people starts withdrawing in mass their staked funds, leaving the protocol uncover and removing the utility on the stake itself. To achieve this, the most important condition to be fullfilled on any state update/operation involving the StakedMana contract is that, if a user staking withdraws, he already respected a cooldown period, which leads that movement of funds should only affect "negatively" the cooldown period.

After activation of cooldown, a staker will be able to redeem the minimum balance he will hold between cooldown activation and redeem window.

Example

• Staker A has 100 stkMANA, and activates cooldown.

• After 2 days (so with the current 10 days of cooldown, 8 days left) Staker B sends 200 stkMANA to Staker A, making his balance 300 stkMANA.

• The cooldown period of Staker A remains unaffected (8 days), but he will only be able to redeem the initial 100 stkMANA he has.

• In order to redeem the full current 300 stkMANA balance, Staker A can activate again the cooldown, but this will reset the delay to the initial 20 days.

If the staker activates the cooldown and decides to transfer out part of his stkMANA, that outflow amount will be discounted from what he will be able to redeem once the delay finishes.

If the staker redeems MANA, the cooldown is reset to 20 days.

If the staker claims rewards, the cooldown is not affected.

Slashing

The StakedMana includes the mechanism to facilitate slashing of the underlying by tracking the exchangeRate between stkMANA ↔ MANA.

The slashing itself must be performed by a slashingAdmin which initially will be the governance short executor. The slashing will result in transferring part of the underlying to a specified address and starting the slashing process by setting a inPostSlashingPeriod flag.

While being in post slashing period, no other slashing can be performed. While accounts can exit the pool no-one can enter the pool in that period.

The community can then use (parts of) the funds for recovery. Once the recovery is finished potentially remaining funds should be returned to the pool and mutualized by the remaining stakers.

Once the slashing is officially settled, accounts can reenter the pool and a new slashing can occur.

A full slashing flow could be as follow:

1. The protocol suffers a shortfall of 100’000 DAI, which should be covered by slashing MANA from the SM.

2. The slashing admin (explained later) slashes 2000 MANA , equivalent to ~160’000 DAI, to account for a potential price depreciation of MANA during the time to cover the shortfall. The exchange rate gets updated, as now stkMANA has fewer claims over staked MANA.

3. By some auction mechanism (out of the scope of the SM at the moment), finally only 1500 MANA are required to cover the 100’000 DAI shortfall, so 500 MANA can be returned back to stkMANA stakers.

4. The system holding the 500 MANA (e.g. the Mana Collector, or any escrow contract of an auction) interacts with the SM to return the funds to stakers. The exchange rate is updated, as now stkMANA has recovered some extra claims over staked MANA.

5. The slashing admin marks the slashing action as settled, and the Safety Module returns to its normal functioning.

From the previous flow, it is important to highlight certain new dynamics and roles:

• Slashing admin. The only entity with permission to trigger the slash() function on the Safety Module contract. Taking into account the time constraints required for an efficient slashing (should be fast enough), and also considering that governance is not fundamentally affected by the action, initially to be assigned to the Level 1 (Short) Executor.

  Additionally, the slashing admin is in charge of defining the maximum slashing percentage that can be slashed at once, currently determined by the community as 30%. Additionally, the slashing admin is in charge of defining the maximum slashing percentage that can be slashed at once, currently determined by the community as 30%.

• Running vs Post-Slashing states. Whenever a slashing happens, by definition the Safety Module enters a slightly unbalanced state, as potentially some (or even all) funds could be returned.

  In order to not allow any kind of arbitrage, after slash and until the slashing admin decides to settleSlashing(), the system enters a Post-Slashing state, during which:

  • Staking is disabled. Given that is unpredictable if funds are gonna be returned or not from slashing “leftovers” no extra staking is allowed.

  • Cooldown is disabled. If anybody wants to redeem their assets, no cooldown needs to be respected, as it is reasonable to give a choice to stakers to evaluate if the risk/reward of staying is worth it. Important to clarify that staking rewards keep accruing, so the “pressure” of stakers redeeming will accentuate the rewards of those staying.

  • No extra slashing can be done. In order to respect the maximum slash percentage, it is not possible to slash without settling first the current slashing.

  The Running state is the non-Post-Slashing, so just the “normal” situation of the SM.