# 8IP-1: 88mph Improvement Proposals

## Specification

88mph Improvement Proposals, or 8IP (pronounced ape), are governance proposals for making changes to the 88mph platform. They are accepted or rejected through MPH holder governance.

### Format of an 8IP

Each 8IP should have the following sections:

- Title
- Should be in the format `8IP-#: [insert title here]`
- Should be something short and sweet, so that people can understand what you aim to do in a glance.
- Specification
- What is the aspect of 88mph you want to improve? How are things done currently?
- What specific improvements are you proposing? It should be clear enough that anyone with the specs can implement the changes.
- Argument for
- Why should the proposed changes be adopted?
- Who does it benefit? What kind of benefits?
- How is the status quo hurting the growth of 88mph?
- Argument against
- What potential downsides does your proposal have? What could go wrong?
- Who might be hurt by this proposal? How much damage might be caused?
- What objections might a reasonable person raise?
- Required actions
- What specific actions need to be taken if this proposal was accepted? Again, it should be clear enough that a developer with the specs can implement the changes.

### Lifecycle of an 8IP

1. Draft
- Draft the 8IP following the guidelines.
- It's probably a good idea to ask a few community members to coauthor with you. Writing governance proposals is not an easy task, and having coauthors is a good way to ensure your proposal doesn't have glaring issues before you make things public.
- Discussing the 8IP in the relevant special interest groups on Discord is also a good idea.
2. Request for comments
- After an 8IP has been drafted, it should be published on [the forum](forum.88mph.app) for the community to comment on it.
- The comments should (but don't have to) focus on critiquing the 8IP as a proposal, not the proposed changes.
- Part of the 8IP is unclear, some requisite actions are missing, etc.
- Providing more arguments for/against the 8IP is also a good idea.
- The authors of the 8IP should use the comments to polish the proposal and produce the finalized version of the 8IP.
- If the community reaction is mostly negative, the authors might want to consider giving up on the 8IP.
3. Debate
- After the 8IP is finalized, it should be debated based on the changes it proposes. This can happen in the forum or on any social media platform.
- The debate period should be at least 7 days. This is to ensure that the general community has enough time to be aware of the proposal, learn about it and the arguments for and against it, and make an informed decision as to whether they support the 8IP or not.
4. Vote
- After enough debating has been done, the authors of the 8IP may put it up to a governance vote.
- The vote will initially be done using Snapshot, but may be migrated to other platforms if better options arise.
- If the vote passes, the 8IP will be implemented.

## Argument for

N/A

## Argument against

N/A

## Required actions

Any new 8IPs should follow the guidelines written in this 8IP.

# 8IP-2: Make depositor reward vest period equal deposit period

## Specification

Currently, depositors are rewarded with MPH, which is vested over a fixed period of time regardless of how long the deposit period is. Most pools have a 270-day vest period, the Compound UNI pool has a 14-day vest period, and the Aave DAI pool has a 30-day vest period.

We propose that the vest period should equal the deposit period.

## Argument for

88mph pools have been using 7-day reward vesting for most of their existence. During this time, it has been fairly easy for users to dump MPH on the market in the following way:

1. Deposit a large sum of money into an 88mph pool for the maximum period (1 year). Because the deposit MPH reward is proportional to the deposit period, and is vested after 7 days regardless of the deposit period, this achieves the highest possible rate of receiving rewards.
2. Keep enough of the MPH received to cover the MPH payback, and dump the rest on the market. This is what we expect a regular user (who intends to withdraw the deposit after it matures) would do in most cases.
3. Alternatively, just dump all of the MPH received and wait until the price drops to buy back and withdraw the deposit early. This would effectively be shorting MPH.

This is clearly problematic for the long term growth of MPH. There are two potential ways to resolve this:

1. Make the vest period a reasonably long time, such as 1 year
- This would be the easier option to implement, not needing any smart contract upgrades.
2. Make the vest period equal the deposit period
- This option requires a smart contract upgrade, detailed in the required actions section.

While the first option is easier to implement, it also makes it more difficult for other protocols to integrate 88mph. For instance, Mushroom Finance is currently using the Compound UNI pool to earn interest, and their smart contract is making 14-day deposits to ensure the liquidity of their funds. If we made the vest period 1 year, smart contracts integrated with us would need to track vested MPH from a long time ago, rather than just assume that all MPH has been vested when a deposit is withdrawn. This makes things much more difficult for them. Therefore, the second option seems better in the long run.

Moreover, with the need to pay back part of the MPH received when a user withdraws their deposit, users who deposit for a short period of time will need to buy MPH from the market to withdraw their funds, which makes for a terrible user experience.

In addition, making the vest period equal the deposit period means the rate of reward is the same regardless of how long a deposit is locked for, removing the incentive for users to make deposits with maximum periods.

## Argument against

Having a short vest period makes it more attractive for users to deposit, which would lead to more TVL and more revenue generated for MPH holders. Prolonging the vest period would hurt the TVL growth.

## Required actions

The `MPHMinter` and `MPHIssuanceModel01` contracts currently used for minting MPH rewards only support a fixed vest period for each pool. Therefore, they need to be upgraded, which involves:
- Deploying the modified contracts.
- Calling `MPHMinter::setMPHTokenOwner()` on the current `MPHMinter` to set the owner of the MPH token contract to the new `MPHMinter`.
- Calling `DInterest::setMPHMinter()` on each pool with the new `MPHMinter`.

The modified `MPHMinter` and `MPHIssuanceModel02` contracts are available here:
- [MPHMinter](https://github.com/88mphapp/88mph-contracts/blob/feature/mph-vest-period-overhaul/contracts/rewards/MPHMinter.sol)
- [MPHIssuanceModel02](https://github.com/88mphapp/88mph-contracts/blob/feature/mph-vest-period-overhaul/contracts/models/issuance/MPHIssuanceModel02.sol)

# 8IP-3: Distribute MPH staking rewards in MPH

## Specification

Currently, all protocol income (interest fee + farmed tokens) are converted into DAI and distributed via the MPH staking pool.

We propose that a new staking pool should be deployed and migrated to, with the following updates:

- The reward token becomes MPH rather than DAI
- Staked MPH becomes a transferrable ERC-20 token (xMPH)
- The distribution period becomes 14 days rather than the current 7 days

In addition, because the migration would require existing stakers to spend gas on exiting the existing pool and enter the new pool, 500 MPH should be allocated to the first distribution period to incentivize migration and compensate for the gas cost. These MPH tokens would come from the governance treasury.

## Argument for

### Creates MPH buy pressure

Using protocol income to purchase MPH allows 88mph to autonomously generate buy pressure for MPH. Price up good, price down bad🤷‍♂️

### Native yield-bearing MPH

Distributing staking rewards in MPH allows us to create a yield-bearing MPH token that only depends on 88mph itself rather than third-party lending platforms.

### Reduces gas cost

MPH stakers are likely to be long-term believers & investors of the 88mph protocol, meaning it's likely that they would use the DAI rewards to buy more MPH anyways. Integrating MPH buying directly into the staking pool means that these purchases are grouped into a single transaction, which is a lot more gas efficient.

Changing the distribution period from 7 days to 14 days also decreases the frequency of exchanging the protocol income into the reward token, making it cheaper in the long run to distribute the rewards.

## Argument against

### Confusion for inflation

Many not-so-reputable projects often create farming pools for their token that simply uses inflation to give out rewards in the same token. Such farming pools dilute the token supply and usually cause the token price to drop.

While the MPH staking pool is nothing like those farming pools, the difference may not be obvious to the less technical users, and explanation of the differences is certainly needed. This may cause confusion.

### Stakers who don't migrate within 14 days won't get gas compensation

Long-term believers of 88mph might have chosen to stake their MPH and forget about it, letting the MPH earn the DAI yield. Therefore, they may not be able to react to the launch of a new staking pool quickly enough to take advantage of the gas compensation.

### Dilutes the staking pool

Currently, staked MPH is not an ERC-20 token and cannot be transferred between users, so if someone is an active trader or liquidity provider of MPH, it is in their best interest to not stake their MPH. This means only the long-term believers of 88mph, who do not expect to move their MPH around much, will stake their MPH. These stakers are rewarded for their long-term investment with a boosted APY, since fewer MPH tokens are earning yield.

If staked MPH became an ERC-20 token, holding or trading staked MPH is strictly better than holding raw MPH, so even the short-term speculators are incentivized to stake their MPH and trade the staked MPH. This will dilute the MPH staking pool, and decrease the staking APY for the long-term stakers.

## Required actions

- Develop and deploy the updated MPH staking pool contract.
- Deploy a new `Dumper` contract that sells tokens into MPH instead of DAI.
- Call `FeeModel::setBeneficiary()` with the new `Dumper` contract as the beneficiary, so that protocol income is sent to it.
- Distribute 500 MPH in the first 14-day reward distribution period.
- Notify existing stakers of this change.

# 8IP-4: Remove MPH payback during withdrawal

## Specification

Currently, depositors need to pay back a portion of the MPH reward they received, which is 30% for most pools. This paid back MPH is sent to the governance treasury to fund community initiatives such as liquidity mining.

We propose that the payback proportion should be set to 0%. We also propose that the governance treasury be funded in the same way as the dev fund, which is minting 10% extra MPH when minting depositor rewards.

## Argument for

### Simplifies UX

The existence of MPH payback makes the user experience unnecessarily complex.

- Having "temporary APY" and "permanent APY" is confusing to new users.
- When withdrawing a deposit, the user needs to first redeem their vested MPH, and then use the MPH to withdraw the deposit.

### Easier integration

Protocols that use 88mph to earn fixed-rate interest need to maintain a reserve of MPH to cover the cost of withdrawing the deposits, which makes integration more complicated. Removing the requirement to pay back MPH during withdrawal will make integration easier, which will lead to more TVL.

### More available cash for the governance treasury

Using MPH payback to fund the governance treasury means that the treasury only receives funding when a user withdraws their deposit, which means there could be a few months or a year of delay between the deposit's creation and the treasury receiving funding.

This is not ideal for the growth of the protocol. For instance, if the TVL of 88mph suddenly grows by 10x, the protocol would naturally see a lot more activity, and the number of users would increase as well. However, because the governance treasury won't receive any benefit from this growth until much later, it is difficult for the protocol to quickly launch initiatives to capitalize on the growth.

Funding the governance treasury at the time of deposit allows 88mph to be more adaptive to growth.

### Lowers risk of floating-rate bonds

Requiring users to pay back MPH to withdraw their deposit means that under certain conditions, a depositor may not be incentivized to withdraw their deposit at all. For instance, if they had sold their MPH reward immediately after making the deposit, the cost of the MPH payback might exceed the deposited amount if the price of MPH has gone up.

In some of the older 88mph pools, a floating-rate bond holder only receives interest payment from the deposits whose debt they funded when one of those deposits is withdrawn. The possibility that some depositors may not be incentivized to withdraw makes buying floating-rate bonds riskier.

## Argument against

### Decreases buy pressure

Removing the MPH payback requirement decreases the buy pressure for MPH and makes it an easier decision to simply dump all of the MPH reward you receive as a depositor.

### Unfairly distributes protocol income

Part of the rationale for introducing the MPH payback mechanic in the first place was to ensure that existing 88mph users will have a boosted proportion of MPH compared to past users and speculators. If the payback mechanic is removed, most MPH tokens in circulation will be generated by past deposits rather than current deposits, and thus most of the protocol income will go to past users rather than current users. This is unfair to the current users.

## Required actions

- Update `MPHIssuanceModel` contract to mint 10% extra MPH to the governance treasury when minting depositor rewards. Should be bundled with 8IP-2's smart contract upgrade if both 8IPs pass.
- Call `MPHIssuanceModel::setPoolDepositorRewardTakeBackMultiplier()` to set the takeback multiplier of each pool to 0.