MIP# - Embedded Volumetric Optionality Middleware - Enabling Price Risk Reduction and Onboarding New Assets

Maker Improvement Proposals
#1 
MIP#: XX
Title: Volumetric Price Stabilization for Reducing Risk for new Assets
Author(s): Sam Bacha (@sambacha)
Contributors: Sam Bacha (@sambacha) , Manifold Finance / Freight Trust
Type: Technical
Status: Pre-MIP Discussion
Date Proposed: 2020-12-25
Date Ratified:
Dependencies: N/A
Replaces: N/A
License: SSPL-1.0 / AGPL

Volumetric Price Stabilization for Reducing Risk for new Assets

Price Stability as a Service for New Asset Onboarding

This proposal provides a middleware layer for MakerDAO to enable ‘almost any’ ERC-20 asset to become a price stable (re: reduced volatility) asset that can enable it to be used as collateral for CDP’s given requirements are met.

NOTES: You can read the
abridged whitepaper on HackMD at this link:
https://hackmd.io/@sbacha/manifold
Full whitepaper:
https://github.com/manifoldfinance/evo
Reference Implementation:
https://github.com/manifoldfinance/documentation

Deployment Contract: 0x766291bE965E6Ba5E77892Ac70034f6B264AE7ea (Rinkeby)

Elevator Pitch

EVO Protocol calculates an average transfer rate for all holders of an ERC20 asset. Movement of an asset (transfers and withdrawals) that are above the calculated average transfer rate incur a fee. This fee is redistributed to all holders. Transfers and Withdrawals below the average transfer rate incur no fee.

Think of this is a ‘Uber Surchage’ or a ‘401 K Penalty’ imposed on bulge bracket transactions. In essence this can serve as a anti rug pull mechanism if so desired.The fees imposed on such transactions can be redistributed to a Mutual Assurance Fund that can act as an insurance vault to further protect the MakerDAO Ecosystem or can be returned to all deposit addresses as a form of Non Inflationary Staking Rewards.

Only the period of recalculation, the Market Period / Contract Rollover, is pre-determined. No admin key, no other centralized form of control exists in the EVO Protocol.

Minting works much like aDAI or cDAI, we use the prefix. mkr- to denote assets that have been deposited into the protocol.

EVO Protocol

Please Note this is a very abridged overview, please read the HackMD or the Full Whitepaper for a more indepth overview!

EVO Protocol, short of Embedded Volumetric Optionality, is a price stabilizing (re: accelerating / decelerating) middleware protocol that enables almost any ERC-20 asset to reach price stability. It achieves this by managing volume.

The token price is determined dynamically(and individually for each holder) based on the information stored or updated in the smart contract during previous transactions giving us the equation:

The above equation will compute the price for a holder [h] to purchase a certain amount of EVO tokens in exchange for a base deposit in ETH/WETH at the given discrete time - [t +1] , where [Dt] stands for the deposit of ETH in the smart contract at previous time - point and [St] stands for the total supply of EVO tokens so far.

The first component with the token - base ratio [Dt/St] under the square root is the indicative price and does not depend on the purchase/transferred amount, a.

Ergo, the component [I_{t+1}^{\prime}(h, a)] is called the discounted interest rate and it can grow proportionally to a within a range of [[0, 0.24]] of $$a$$.

Higher interest payouts can slow down, decelerate, the price movement. Interest rate determines how fast, or acceleration, such price can change depending on the market demand & supply pressure for EVO-based tokens. Interest[#] is computed individually for each EVO holder.

1194×164 20.3 KB

1156×166 22.5 KB

Interest Rate

Ownership Rate

Discounted Interest Rate

Price dynamics of equation (1) depends on the transactions volume conducted by all of the involved market participants and bounded by

Therefore it can be expected that the demand for EVO Protocol based tokens like EVO-[ERC20] will be able to represent the demand for the underlying asset, whereas EVO-[ERC20] represents the value of the underlying asset as a derivative function of the base asset, the ERC-20 asset. (i.e.a fixed unit of account for the ERC-20 asset, e.g. What Gwei is to Ethereum.)

Implementation Roadmap

If MakerDAO Governance Adopts the proposal, which is to only allow assets to be considered for collateralization with this additional middleware layer, it does not enable Any asset to become automatically accepted, rather it allows any asset to add this functionality in their own asset proposal / onboarding application as currently defined by the current MIP for said Risk Assessment

Manifold Finance, the entity behind EVO Protocol is willing to partner and commit to an ERC-20 asset that is willing to be the first asset that is collateralized under this method. Meaning Manifold Finance will contribute up to a certain amount of liquidity (re: holding the asset for a certain amount of time then unwinding its position under a pre-defined term). This agreement would have to be coordinated with both MakerDAO Governance and the ERC-20 Asset’s Operational Entity (e.g. to procure said asset OTC for example / coordinate with the team in defining the parameters of both recalculation period, scope of holdings, etc).

We stress that not every ERC-20 asset will ‘instantly’ become acceptable to the MakerDAO Ecosystem, rather that this approach vastly reduces price volatility for assets that are otherwise of a sound nature (i.e. offers both functional and utility, strong community, active development, other qualitative measures, etc).

Additional safeguards such as a Mutual Assurance Fund can be implemented as a ‘sandbox’ for ensuring the overall robustness of the MakerDAO Ecosystem. This proposal seeks to first establish a willingness to consider such a solution before ‘getting into the weeds’.

Additional Links

GitHub Documentation

GitHub Repo for Implementation

Telegram: https://t.me/manifoldfi
Telegram (personal): @sambacha
Email: [email protected]

An Audit is being arranged. If developers from MakerDAO wish to be granted access to the currently private repository, that can be arranged easily. Please feel free to contact me about questions / concerns / comments.

Regards,

Sam

2 Likes
#2

Just to re-iterate: this is a provisional proposal, should there be preliminary consensus on the viability of the proposal we are more than willing to provide hard numbers along with defined timeframe for the roadmap / implementation along with the amount of committed capital to the ‘sandbox’.

A sandbox period in which one or a few assets are used to asses the viability and robustness of using the EVO Protocol is our preferred adoption pathway. Additional econometric modeling along with stress testing can be provided through a 3rd Party or through a solution set we are working on called Contract Shark.

Appreciate any questions, thanks again,

Sam

#3

Hi @sambacha and thanks for this interesting proposal!

I must admit I scratch my head a bit. The title of your reads “Stablecoin as a Service” so I was expecting an article on stablecoins but that was the only place stablecoins were mentioned. But I get the concept of price stabilization.

This sentence above contains a typo?

I am left a bit puzzled regarding the implementation of this. Manifold Finance will invest OTC style in a low volume ERC-20 token (generic token XYZ) and then make a price stabilized version of this token in the form of EVO-XYZ. OK - but XYZ is not a ERC-721, not a stablecoin, not a real world asset so I am slighly at a loss about what type of coin or asset will fit into this.

Could you maybe provide a worked-out example?

Also - as far as I see it - how does Manifold Finance handle asset onboarding? From the looks of it is a fully manual process?

#4

Thanks for the great questions, let me answer them right off the bat.

  1. Nothing about the proposal necessitates a ‘low volume’ token, in fact market depth would be the first criteria I would use to evaluate potential candidates.

  2. ‘XYZ’ does not need to be an ERC721, it remains an ERC20.

A real world example would be the following:
ChainLink decides to experiment with proposal and commits to using a 30 day contract roll over for the ‘mkr-LINK’ contract market.
Users deposit LINK into the contract market in order to be able to collateralize vaults / mint DAI / etc.
Once deposited, the user receives their ‘mkr-LINK’, and can utilize it within the MakerDAO Ecosystem.

Lets take a hypothetical example of depositing 2,000 LINK and receiving 2,000 mkr-LINK.
Lets say the user decides to sell 1,500 of their mkr-LINK for some other asset.
Let us also assume that the 30 day avg. transfer rate is 1,000.
Their sale of 1,500 incurs a fee, a percentage fee proportional to the amount in excess of the average transfer rate (in this case, 1,500 - 1,000 = 500 is in excess).
This fee is dynamically calculated based on all transfers for that time period thus far (this specific multiplier can be tied into other MakerDAO 'PIDs/Gauges/Levers/etc), lets say 50 mkr-LINK.
This 50 mkr-LINK is redistributed to all other account holders proportionally. It can also be redirected to a ‘mutual assurance pool’ or some other insurance scheme or even a designated address.

Manifold Finance can deploy the contracts, but it is not necessary for us to do so. We have an SDK for the protocol that will make it turn key, and besides the contracts are actually quite simple as they do not have additional features (e.g. there is no admin, there is no way to upgrade contracts, we tried to reduce the surface area as much as possible).

We do not need to invest ‘OTC’ style, we only wanted to show our commitment to this sort of solution (since we are the ones proposing it).

Thank you for your questions, please let me know If I did not answer any of them or if you would like further clarification.
Yes, I notice now that title of the post doesn’t reflect the content as it should. Really it should probably read something more baroque but I figured ‘Stablecoin as a Service’ was easier to get the idea digested for the community.

1 Like
#5

What sequence of actions must Chainlink actually do here? Is Chainlink’s participation even necessary?

#6

Chainlinks involvement in the example is not necessary. Only for OTC/favorable price entry. However, it should be noted that the two assets may diverge in price if there is a discontinuous relationship vis a vie end users, meaning we want to be able to capture the largest possible set of transaction flow inorder so that the calculated transfer rate is truly representative of functional velocity flows rather than purely speculative velocity flows

#7

@sambacha I feel a bit stupid, but I don’t understand the whole proposal. I understand you are wrapping an ERC-20 and adding friction to avoid price movement.

1- I don’t get who wants to do that and why? Maybe a way to advantage long term holder, but not sure.

2- Where is the underlying price of the ERC-20 used? If It’s WBTC and it goes up +50%, does your wrapper move the same amount (assuming I haven’t transacted in a while)? If yes, this doesn’t add much stability. If not, I don’t understand what is the interest (this goes to 1-)

#8

Great Questions:
First let me clarify: This isn’t wrapping an asset, this takes a deposit, then mints a new asset on a 1:1 basis.

We are not adding friction , that implies that all users would encounter this mechanism, rather we are dynamically charging a certain set of transactions, namely transactions that exceed the trailing average transfer rate.

Why would users want to use this?
Well for MakerDAO it would reduce price risk by having a middleware layer that diffuses price swings.

For users of the protocol by itself, it can afford some protections against rug pulls. However, this all assumes that the traded asset has some ‘intrinsic’ worth, meaning there is some functional or utilitarian purpose for using the asset other than as a unit of account for payments.

The correspondence between the ERC-20 and the ‘evo’-ERC-20 shouldn’t deviate by any significant measure. The reason for this is there will exist an arbitrage opportunity (hence these will trend to zero in terms of a price differential).

The best way to think of this is in terms of acceleration and deacceleration. Price swings still happen, but over a more gradual period of time (like speeding up or slowing down). We want velocity (i.e. volume) to be the penalizing factor, not price.

Like I said, this is what I would call a soft proposal, We first want to make sure that what we are suggesting, is in fact viable, then making sure there is community support behind it. At the end of the day if the Ecosystem doesn’t use it, it serves no purpose then.

#9

Alright @sambacha,

Could you maybe go through the following sequence and see if I got this right?

  1. Someone with a whole lot of LINK and ETH creates mkr.LINK.
  2. Same someone heads over to Uniswap and creates mkr.LINK/ETH. There is now a market and an oracle.
  3. Maker approves mkr.LINK as a collateral type as mkr.LINK is stabilized and better collateral material compared to LINK, allowing more beneficial Vault properties.
  4. mkr.LINK is now used as any other ERC-20 token with regards to liquidation.

Is this the approximate sequence of events?

#10

youre-the-real-mvp
youre-the-real-mvp1000×550 80 KB

Yes*

*SAFU

#11

hi again @sambacha

I am checking your links. What is the link between the above proposal and FreightTrust.com?
FreightTrust is involved with supply chain issues?

#12

Just for my email, that is it. Freight Trust is in the process of a major protocol revision relating to AS2 and EDI messaging. It does not have anything to do with this proposal.

Manifold Finance is the legal entity that is responsible.

Manifold Finance GitHub

Reference Implementation called, ‘GasEVO’, documentation would be the same

#13

Next questions are about capital efficiency and the non-fee inducing transfer rate:

  1. If we consider either mkr-LINK or mkr-ETH (your choice) - how much GasEVO would need to be deposited as a ratio to the collateral material. I am thinking specifically on the unnumbered function square(D/S) in the middle of your hackmd paper.
  2. What are the realistic transfer rates if I do not want to pay extra fees? Let’s say I have minted 5 mkr-ETH - this should go through free of charge? But not 150 mkr-ETH?
1 Like
#14

  1. There is no token required to utilize the EVO protocol. GasEVO is the reference implementation of the whitepaper where the underlying asset is Ethereum. It is ment to be a hedge against price risk for transaction costs (hence the inclusion of the word ‘Gas’).

  2. The transfer rates can be historically examined. If you do not want to pay the imposed surcharge you must wait until the next ‘rollover date’. Rollover date’s are defined at the market’s creation. As of version one this is a fixed constant, for version 2 we plan on implementing a function that can be modified.

Additionally, I am working on some Pytests for simulating extreme events so that the community may better asses the protocol from a more informed standpoint.

If you would like to see simulations along with examining a specific asset so that historical backtest can be applied we would be happy to do so!

1 Like
#15

Hi. What’s happening with this? Does it live? Ty