[MRC-8] Change MIPs framework

Proposals MRC (Mars Request for Comment)
1

Proposal Authors

@traianoverse

References

The Mars Improvement Proposal (MIPs) Framework

Summary

As stated in the Mars Improvement Proposal Framework, the four main proposal topic categories are:

  1. “Technical Proposals: Certain proposals for changes to certain configurable aspects of Mars Hub and/or the Mars Outposts (binding), which can be modified directly by on-chain votes, or code changes to the Mars Protocol (signaling), which require upgrading the protocol.”
  2. “Red Bank Asset Listing Proposals: Proposals to add or remove support for one or more assets within the Red Bank (typically binding).”
  3. “Credit Line Extension Proposals: Proposals from developers aiming to secure a virtual “credit line” from the Red Bank for unique applications such as leveraged yield farming (binding or non-binding, depending on whether code is ready and deployed on chain at time of proposal).”
  4. “General Proposals: All other proposals impacting areas such as the treasury, governance, and tokenomics (mix of binding and non-binding).”

The MIP mandates all the mentioned categories to pursue the following timeline:

  1. Mars Request for Comment [MRC] posted on The Forum.
  2. Minimum five days of feedback period on MRC post.
  3. Feedback is incorporated into MRC and “frozen” for a minimum of 2 days.
  4. Proposal formally submitted as a Mars Improvement Proposal [MIP] for voting by MARS stakers.
  5. MIP is authorized by the community and implemented.

Abstract

We propose to make an exception to the following categories of submissions, which should be able to be posted freely on-chain:

  1. Urgent software-related proposal.
  2. IBC client update proposals.

For those categories, the following definitions from The Mars Improvement Proposal (MIPs) Framework should not apply:

  • “Minimum Feedback Period: The minimum amount of time within which the community can give feedback in response to a proposed MRC before it can advance to an on-chain vote and becomes known as a MIP.”
  • “Minimum Frozen Period: The minimum amount of time during which an MRC must remain unchanged before it can advance to an on-chain vote as a MIP.”

Motivation

Given that the technologies employed by Mars, Osmosis, and IBC are not bulletproof, it is important to be prepared for technical difficulties that might require immediate attention.

We feel like a 7-day submission window followed by a 3-day voting period it’s too long to address and resolve any bugs in a timely manner.

2 Likes
2

at some point, the 7days submission period is already too long and we will have “emergency” proposals submitted.

    1. Urgent software-related proposal. => this kind of proposal will be an off-governance upgrade to not disclose a bug and avoid exploit
    1. IBC client update proposals. => an IBC upgrade proposal is not something really urgent. if an IBC channel is used, it will not expire. so this kind of proposal will only happen in case of low usage IBC chanels.

Short term proposal will be, imho, more about the red-bank stuff to quick react on some events.

3

I would like to disagree with this sentence “an IBC upgrade proposal is noting urgent. if an IBC channel is used, it will not expire. so this kind of proposal will only happen in the case of low-usage IBC channels.”.

An unplanned upgrade by a counterparty chain may also result in expired clients. If the counterparty chain undergoes an unplanned upgrade, there may be no commitment to that upgrade signed by the validator set before the chain-id changes. In this situation, the validator set of the last valid update for the light client is never expected to produce another valid header since the chain-id has changed, which will ultimately lead the on-chain light client to become expired.

Yes, consensus can be reached off-governance for some patches, (e.g. Dragonberry patch), all the more so the MIP should make explicit that these kinds of situations are not mandated by the framework.

4

I agree with this, sometimes there are scenarios where faster responses are critical and this should probably be reflected in the MIP Framework.

On that note, I wonder if it could be useful to enable a multisig of contributors that could execute a limited set of functionality in an emergency, such as pausing borrows for a certain asset. This multisig would be able to bypass governance for the given actions, and governance could remove or enable multisig members via proposal.

This would need to be carefully considered however as there is probably many implications , especially on the legal side.

EDIT : this already exists see here

1 Like
5

When a chain change his chain-id, an IBCupgrade plan must mandatory be submit prior to the upgrade.
this is what IXO missed before changing the chain ID and the result of all the proposal to solve the issue.