[MRC-47] Migration to Mars v2 on Osmosis Mars Outpost

Proposals MRC (Mars Request for Comment)
1

Summary

The objective of this proposal is to migrate the Mars Protocol from its current version to v2. In the next few sections we’ll highlight the most important aspects of this upgrade and the risks associated with the migration.

Code:
Full Fledged Credit Accounts - Rover
New Liquidations Mechanism - Red Bank & Rover
Pyth Circuit Breakers - Red Bank

Audits:
Rover
Red Bank

Full Fledged Credit Accounts

Mars’ ultimate vision is to replicate in DeFi the success of Centralized Crypto Exchanges. What has led these, arguably, to become most successful products in crypto have been two things:

  1. One simple UX: To perform most crypto activities such as (Spot, Margin, Perps, Launchpad, etc.)
  2. Capital Efficiency: Every asset in an account can act as collateral, enabling cross-collateralization of position - which ultimately results in massive capital efficiency

Mars aims to achieve the same two goals in DeFi with the introduction of its Credit Accounts primitive.

How can this be achieved?

First, credit accounts are flexible and allow leverage to be added to any DeFi primitive. Effectively, when a DeFi primitive is whitelisted in a credit account, users are immediately able to interact with that primitive using leverage. This means that a user could for example take on leveraged spot positions on a DEX, or perform Leveraged Yield Farming, Leveraged Staking / Leveraged Vaults by using their credit accounts.

Second, positions held in credit accounts are cross-collateralized by default. What this means is that any position within an account can be used as collateral to open and guarantee the solvency of other positions within the same account. For example, a margin long trade could be used as collateral to open a leveraged lp position on Apollo Vaults, all within the same UI. Without the credit account as the middleware connecting both primitives (tokens traded on Osmosis DEX and LP positions in Apollo vaults), this transaction wouldn’t be possible since there’d be no underlying mechanism to ensure the solvency of the position. Cross-collateralization naturally translates into more capital efficiency, more use cases and a better UX.

A beautiful and intuitive UX can be built on top of credit accounts - as now users can interact with any DeFi primitive on-chain in a super capital efficient manner.

–

On Mars, credit accounts are currently used in a very limited way. They’re the engine that allows for leveraged yield farming within the Farm section of Mars. On Mars v2, however, they will be used for much more. Specifically, credit accounts will allow users to lend, borrow, trade, stake and yield farm. All with leverage, in a cross-collateralized manner and under a single, unified experience.

In Mars v2, users will finally be able to use the full power of cross-collateralization of credit accounts and be able to perform the following things:

  1. Spot trading
  2. Margin Trading
  3. Lending / Borrowing
  4. Levered LPing (via Apollo Vaults)
  5. Levered Staking

New Liquidations Mechanism

One of the most critical upgrades of Mars v2 relates to its new liquidations mechanism. Within Mars (and generally within DeFi lending products), the liquidations mechanism is the fundamental component that guarantees (or intends to) the solvency of the system. As such, its importance cannot be overstated.

Generally, liquidation mechanisms consist of the set of rules and processes that determine when and how risky positions should be closed (or liquidated) and the incentives for outside parties to do so.

Currently, Mars uses a simple liquidations mechanism where the Close Factor (CF)* and the Liquidation Bonus** are fixed. The way this mechanism works is, whenever a position becomes liquidatable (i.e. its Health Factor drops below 1), any third party can repay a portion of the debt of that position (determined by the CF) to receive a portion of the collateral of the same position. The difference between the value of the collateral received and the value of the debt repaid is determined by the Liquidation Bonus (LB). Let’s explore an example:

  • Assume there’s a position with 100 ABC tokens as collateral and 200 XYZ tokens as debt.
  • Assume the value of ABC drops and the Health Factor of the position drops below 1.
  • As soon as that happens, any third party (commonly known as liquidators) can repay a portion of the debt to receive a portion of the collateral.
  • The portion of the debt that the liquidator can repay is determined by the CF. If the CF is 50%, then the liquidator will be able to repay a maximum of 100 XYZ tokens, or 50% of the total XYK tokens.
  • As an incentive to perform this task, the system offers the liquidator a portion of the collateral worth more than the debt repaid in return. This value is determined by the LB. For example, if the LB is 10% and the value of the debt repaid is 1,000 USD, then the liquidator would receive 1,100 USD worth of collateral for liquidating the given position.

While this mechanism has served Mars well, we believe it offers significant improvement opportunities for the protocol. These improvements relate to:

  • Capital efficiency:

    • Since the LB isn’t market driven but rather needs to be defined a priori, the LB needs to be set aggressively such that under any condition it offers a significant incentive for liquidations to happen. A large LB translates into borrowers being punished more than they need to and more value leaking away from the protocol and towards liquidators.
    • A similar situation happens with the CF. Given that it needs to be defined a priori, it should be set conservatively such that it offers security under any potential future scenarios. A larger than needed CF punishes borrowers and further leaks value from the protocol.

  • Systemic Robustness:

    • Cascading liquidations: As this system tends to lead to higher than needed LB and CF, it is more prone to produce liquidation cascades. The reason for this is that a higher LB and CF lead to a higher value of the liquidated user’s collateral offered to the liquidator and thus, can lead to a larger value of collateral being liquidated on the market. This in turn can have a negative price impact on the collateral’s price and lead to further liquidations (i.e. a liquidations cascade).
    • MEV: Given that as soon as the HF of a position drops below 1 the whole LB is offered to third parties, this system tends to lead to liquidators competing for the same liquidation opportunity at the same time, which may lead to congestion and other negative externalities on the network.

  • Flexibility: As the LB is inflexible and needs to be set a priori, it could happen that the LB offered isn’t significant enough for a position to be closed. If this happens, the position won’t be closed and can lead to the system accruing bad debt.

The new liquidations mechanism incorporated into Mars v2 intends to improve upon each of these points. The way it does so is by implementing a dynamic methodology for determining the LB and CF. Let’s explore.

In the new liquidations mechanism, the LB isn’t static but rather changes with the HF of the position. All else equal, the lower the HF of a position, the higher the LB offered to liquidators will be. This mechanism, pioneered by Euler, intends to recreate a Dutch Auction where, instead of time determining how the LB increases, the HF does. Let’s explore a simplified example of how this model could work*:

  • Assume we have a position with some collateral and some debt.
  • Assume we have parameterized the liquidations system such that the LB increases linearly as the HF decreases (i.e. for every 1pp the HF drops, the LB increases by 1pp).
  • Now, imagine the price of the collateral drops and the HF decreases to 0.99. At that moment the LB would be 1% (1-0.99).
  • 1% doesn’t seem to be enough incentive for liquidators as no liquidations happen at that time.
  • After some time, however, the HF drops to 0.97. At that moment, the LB offered would be 3%.
  • As 3% is enough for a liquidator, a liquidation happens at that level.

*Note that this example follows a specific parametrization of the system. If parametrized differently, the results might be different. What will tend to be the same across all parametrizations though, is the inverse relationship between the HF and the LB.

The exact formula for calculating the LB under the new mechanism is as follows:

Liquidation Bonus = min(intercept + (slope * (1 - HF)), maxLB*)

maxLB* = max(min(CR - 1, maxLB), minLB)

Where:

  • CR is the Collateralization Ratio of the position, defined as the value of the assets divided by the value of the debt.
  • HF is the Health Factor of the position.
  • Intercept and slope are governance defined parameters that determine how the LB increases as the HF decreases.
  • maxLB and minLB are governance defined parameters that determine the maximum and minimum values the LB can have.

Now let’s explore how the CF is determined under this model. Within this new system, the CF will be determined dynamically using a parameter known as the Target Health Factor (THF). The THF is a governance defined parameter that determines the ideal HF a position should be left at immediately after the position has been liquidated. The CF, in turn, is a result of this parameter: the maximum amount of debt that can be repaid to take the position to the THF. For example, if the THF is 1.05 and a position gets liquidated at HF = 0.98, then the maximum amount of debt a liquidator can repay (in other words, the CF) will be an amount such that the HF after the liquidation is at maximum 1.05. Notice that, in a similar vein to the LB, all else equal, the lower the HF of a position, the higher the CF will be. This makes sense since the HF is the best proxy we have for the riskiness of a position. As such, the riskier a position, the higher the CF allowed when liquidating it.

So, how does this system improve upon the points described above?:

  • Capital efficiency:

    • The LB is determined dynamically as a function of the HF. If we assume that the HF of a position will tend to drop gradually, then this mechanism will tend to gradually increase the LB offered to liquidators as the HF decreases. If this happens, then we generally expect liquidations to happen at the lowest possible LB that generates a profitable liquidation. Thus, this system will likely lead to lower LBs (and better conditions for borrowers) and less value leakage for the protocol.
    • The CF methodology also has the potential to lead to better capital efficiency. In particular, the lower the THF chosen, the lower the CF will be and the more capital efficient the system will be. The lower the THF, however, the less margin of safety the liquidation gives the position after liquidation. Thus, there’s a balance to strike here between capital efficiency and margin of safety when determining the THF.

  • Systemic Robustness:

    • Liquidations cascades: As covered above, this system is likely to lead to lower LBs and CFs. All else equal, this means lower values of liquidated collateral and thus, a lower risk of liquidation cascades. Furthermore, this system is likely to lead to fewer liquidations overall. Under this system, for instance, a position that hovers around HF = 1 might not offer a sufficient LB for immediate liquidation. In time, such positions could become healthy again, meaning that fewer liquidations were even needed. This property also leads to a decreased risk of liquidation cascades.
    • MEV: As mentioned above, if the LB increases gradually, the most efficient liquidator will tend to liquidate first. If that’s the case, this has the potential to lead to no congestion issues at all, since the most efficient liquidator will tend to liquidate alone, without any competition from more inefficient liquidators.

  • Flexibility: Under this model, the right LB doesn’t need to be determined a priori. Rather, it will be set by a market-driven mechanism where the final LB will depend on market conditions at that specific point in time. This solves for the arbitrariness of having to define a fixed LB a priori for any and all future market scenarios.

As with most decisions in DeFi, the implementation of this new mechanism comes with tradeoffs. The most important one is that it’s a more complex mechanism. This additional complexity might translate into unforeseen issues at both the economic (incentives) and smart contract levels. Furthermore, this migration implies moving from a relatively battle-tested mechanism to a completely new implementation. These risks mean that there is increased potential for hacks, exploits, economic manipulations, and smart contract bugs, which could result in loss of funds for both current and future depositors, with no remedy, recovery or refund mechanism to the adversely affected users.

Pyth Circuit Breakers

Instead of naively absorbing the feeds received from Pyth, Mars v2 implements two new circuit breakers intended to mitigate potential price manipulation attacks. These circuit breakers will activate whenever the volatility of a certain feed is extremely high or there’s too much uncertainty over the real level of a certain price. Whenever any of these filters triggers, the transaction will be invalidated*. The circuit breakers are the following:

  • EMA: In addition to the spot price, Pyth offers an Exponential Moving Average (EMA) with each price feed. The EMA is a single price that aggregates the spot price and historical prices for a certain asset, where “the most recent samples receive the most weight, and samples further back in time get exponentially less weight the farther in the past they are.” Given this characteristic, the EMA is significantly more resistant to manipulation than the spot price. This is the reason we incorporate the EMA as a circuit breaker. The way we incorporate it is as follows:

    • First, we set some bounds above and below the EMA (i.e. Upper Bound = EMA + 15%; Lower Bound = EMA - 15%).
    • Then we check whether the spot price is within those bounds.
    • If it is, the transaction is valid.
    • If it isn’t, the transaction is invalidated.

  • Confidence Interval (CI): Pyth offers a CI with each feed that informs on the level of certainty that the publishers of that feed have on the reported price. All else equal, the larger the CI, the lower the certainty of publishers on the real spot price of the asset. As such, the rationale for incorporating this circuit breaker is obvious. The way it’s implemented is as follows:

    • If the ratio between the CI and the EMA is above a certain threshold, the transaction is invalidated.

Both the magnitude of the EMA bounds and the Confidence Interval threshold are governance defined parameters.

*Note that there are some exceptions on what transactions are invalidated by circuit breakers triggering. These exceptions are: liquidation, deposit and repay transactions. The reason for the exceptions is that we want to always guarantee liveness for these transactions. For liquidations because solvency of the system is a paramount concern and circuit breakers could lead to halting liquidations. For deposit and repay transactions because we want to allow users to always be able to save their positions from liquidation, even when certain circuit breakers are activated. There’s one final exception, and it’s for withdraw transactions from accounts with no debt.

These circuit breakers trade off liveness for security. For a lending protocol, we believe this is a worthwhile tradeoff. However, users should be aware that when these new circuit breakers are triggered they won’t be able to interact with the protocol (including borrows, withdrawals and so on). This could lead to temporary or permanent loss of funds or value, including the inability to sell assets while prices or market conditions are deteriorating. While we don’t expect this to happen often, it is definitely a possibility.

Additionally, as with the new liquidations mechanism, these new circuit breakers might lead to unforeseen issues at both the mechanism and smart contract levels.

MARS V2 IS PRESENTED ON AN AS-IS, WHERE-IS BASIS, UNDER A GPL V3 LICENSE. NO REPRESENTATION, WARRANTY, GUARANTY, OR PROMISE REGARDING THE OPERATION OR RESULTS OF OPERATION OF MARS V2 IS BEING OR WILL BE OFFERED BY ANY ENTITY OR INDIVIDUAL. MARS V2 WILL BE OPERATED BY VALIDATORS ON THE APPLICABLE NETWORKS, AND NOT BY THE SOFTWARE DEVELOPERS–OPERATIONAL AND EXECUTION QUALITY MAY VARY AND VALIDATORS COULD SEEK TO FRONT-RUN OR MANIPULATE OR CENSOR TRANSACTIONS, OR OTHERWISE EXPLOIT VALUE FROM USERS. REVIEW THE CODE AND APPLICABLE NETWORK ENVIRONMENT(S) YOURSELF OR WITH THE ADVICE OF A PROFESSIONAL ADVISOR. USE MARS V2 AT YOUR OWN RISK.

SOME OR ALL FEATURES OF MARS V2 MAY NOT BE LEGAL TO USE IN CERTAIN JURISDICTIONS, INCLUDING IN THE UNITED STATES WITH RESPECT TO LEVERAGED TRANSACTIONS. NO PERSON IS SOLICITED TO USE MARS V2 OR RECEIVING AN OFFER TO ENTER INTO ANY TRANSACTION, THROUGH THIS PROPOSAL OR OTHERWISE. USERS ARE RESPONSIBLE FOR ENSURING THEIR OWN LEGAL COMPLIANCE AND MAY BE AT RISK OF SERIOUS LIABILITIES FOR VIOLATING THEIR LOCAL LAWS OR THE LAWS APPLICABLE TO OTHER USERS INTERACTING WITH THEM ON A PEER-TO-PEER BASIS THROUGH MARS V2.

Implementation

This is a signaling proposal, not an executable proposal.

The upgradeability of Mars smart contracts on the Osmosis chain iscurrently subject to implementationby the Builder Multisig address. If this proposal passes, the builders will utilize their multisig to make the necessary changes.

Copyright

Copyright and related rights waived via CC0.

Disclaimers/Disclosures

This proposal is being made by Delphi Labs Ltd., a British Virgin Islands limited company. Delphi Labs engages in incubation, investment, research and development relevant to multiple ecosystems and protocols, including the Mars Protocol. Delphi Labs and certain of its service providers and equity holders own MARS tokens and have financial interests related to this proposal. Additionally, Delphi Labs is one of several entities associated with one another under the “Delphi Digital” brand. Delphi Digital’s associated entities and/or equityholders or service providers of such entities may hold MARS and may have financial interests related to this proposal. All such entities, service providers, equity holders and other related persons may also have financial interests in complementary or competing projects or ecosystems, entities or tokens, including Osmosis/OSMO. These statements are intended to disclose relevant facts and to help identify potential conflicts of interest, and should not be misconstrued as a complete description of all relevant interests or conflicts of interests; nor should they be construed as a recommendation to purchase or acquire any token or security.

This proposal is also subject to and qualified by the Mars Disclaimers/Disclosures. Delphi Labs may lack access to all relevant facts or may have failed to give appropriate weighting to available facts. Delphi Labs is not making any representation, warranty or guarantee regarding the accuracy or completeness of the statements herein, and Delphi Labs shall have no liability in the event of losses or damages ensuing from approval or rejection or other handling of the proposal. Each user and voter should undertake their own research and make their own independent interpretation and analysis of all relevant facts and issues to arrive at their own personal determinations of how to vote on the proposal.