Mirror V3+: The Market Module— Arbitrage Solved

Mirror Protocol operates on the Decentralized Finance platform Terra. Mirror seeks to provide synthetic investment price exposure otherwise unavailable to users in the Terra ecosystem, and more generally, the crypto space.

Users have been asking since v2 when Mirror’s mAsset premiums will go away. Even with the sweeping adjustment’s I’ve proposed in my Mirror v3 series, the spread between Oracle price and DEX price will remain variable. Premiums are the symptom Mirror’s lack of efficient arbitrage methods and current liquidity provision tactics. I propose we take a page out of LUNA’s book to solve our problems. I’m referring to LUNA’s Terra Stable mint mechanism and market module. But why should we implement this ‘market module’ specifically, and how would it help? Well, the ‘why’ is that a market module provides not only efficient arbitrage methods, but also gives MIR some much needed utility. The how? Well, let’s dive in.

Context:

Mirror’s mAssets are Collateralized Debt Positions (CDPs). The act of collateralizing volatile assets is a problem because the only way constant product DEX pools will ever independently adjust to match an Oracle Price (real world reference price that mAssets are minted at) of a volatile, collateralized asset is if there is a belief that other people will ‘buy in’ or ‘sell’ to equilibrate price. The problem lies in that there is no way to truly ‘arbitrage’ price differences on Mirror without some string being attached to a CDP (short) or long that will inevitably need to be closed/exited: i.e. there are no guaranteed profit arbitrages. Having ‘strings’ attached to arbitrage also prevents efficient price stability as any price movement toward equilibrium is hindered by users closing their positions once in profit only to drive the pool off-peg again. On top of this flaw, ‘arbs’ only become profitable on the short side (given DEX price > Oracle Price) if the price difference between DEX and the Oracle is greater than 1.5% of the minted value. This is due to the 1.5% fee on the mint position (1.5% on only the minted mAsset’s value) when a CDP is closed. Such a fee structure is a significant factor in why we see consistently high, positive premiums. Mirror is in dire need of a low friction, string-less way to add and remove mAsset liquidity to/from the different swap pairs across DEXs. Enter Terra’s stabilization mechanism.

The Vision:

To integrate a market module into Mirror, I suggest the following: use the same framework of LUNA/Terra Stables but ‘replace’ LUNA with MIR and Terra Stables with mAssets in their own, separate, market module. For example, if DEX price > Oracle price, I envision users able to burn their MIR for an equivalent dollar amount of a newly minted mAsset (at Oracle price) which they can then sell directly on the DEX market to profit without the baggage of a CDP. Similarly, if DEX price < Oracle price, I envision users able to purchase mAsset from a DEX to then burn for MIR without the need to wait for the price gap to close via other users’ buy pressure. Both of these interactions will effectively remove any significant mAsset DEX to Oracle price deviation to create a much more efficient market. Let’s now look at the specific implementation.

The Market Module AMM Curve:

What’s an AMM: Terra uses a constant product AMM curve for its market module. This means that the exchange rate of LUNA to Terra stables follows a curve. When the amount of LUNA in the virtual pool changes due to a swap, the Terra Stable amount must also have changed by an inverse amount. Whether there is more LUNA or Terra Stable in the pool than the pool’s base capitalization depends on the ‘direction’ of swaps that are made (LUNA for Terra Stable, or Terra Stable for LUNA). See the chart below or here for clarification.

Terra Implementation: Given you now know how an AMM works, we can now dive in to the specific application of a virtual AMM on Terra. A virtual AMM is different from a normal AMM in that users do not provide liquidity to this type of AMM. Virtual AMMs are also kept pegged by code, not user arbitrage, via pool replenishment mechanisms relative to an Oracle Price. Terra uses a virtual AMM implementation as a medium for a USD value equivalent in LUNA to be converted to any USD equivalent Terra Stablecoin given their specific Oracle prices at a particular time, or vice versa. This mechanism exists separately from any DEX, is the very lifeblood of Terra, and is what provides LUNA so much value. We’re interested in this mechanism for a slightly different reason than simply providing MIR utility, though. Specifically, the virtual AMM market module created by Terra is an excellent in facilitating arbitrage with external DEXs, which is our main focus.

Mirror Implementation: Terra allows for open interaction with its market module which is important as it is the only way that total UST and LUNA supply can be affected. The specific goal of implementing a virtual AMM market module on Mirror is to facilitate efficient arbitrage to bring DEX prices back to oracle price, not to provide users with additional methods of minting/collateralizing mAssets, nor as a way to hold immense amounts of mAsset ‘off the books’.

I argue that an ‘on the rails approach’ is the best solution in implementing this virtual AMM on Mirror versus allowing users to openly mint or burn mAsset (as it would exist on TERRA with its Terra Stables). I suggest we lock the market mint function to swap contracts with DEXs to ensure that DEX liquidity is properly influenced. We also could implement a simple swap optimizer to choose the best DEX to arb for any particular market-mint swap. To note, there is a contract already built that could be repurposed for this market-mint DEX swap mechanism (the v2 short-farm sale and lock mechanic). I also propose the removal of mAsset to mAsset market swaps (seen as Terra Stable to Terra Stable market swaps on Terra) to prevent FOREX gaming across DEX pools and to simplify the user experience. A general 0.5% market swap fee as to earn non-inflationary yields for the platform could also be applied (consistent with LUNA/Terra Stable market swap). This fee could also be adjusted in the event that spreads are still too high due to DEX fees.

Addressing Concerns:

Implementing a virtual AMM market module into Mirror will require careful fee structure construction as to prevent exploits. Remember that the specific goal of implementing a market module is to facilitate efficient arbitrage to bring DEX prices back to oracle price.

CDP Viability:

CDPs would remain important to the protocol, even with a market module, as they provide stability and solvency to the platform. Short farms are also locked to the mint mechanism which forces users to mint and provide collateral (backing). Under my short farming contract fix, short farmers would either only provide mAsset or, if delta-neutral, provide equal amounts of mAsset and UST to a given pool. Any delta-neutral user would therefore help the ecosystem while simultaneously be forced to collateralize and provide solvency to the pool. MIR rewards will still persistently be distributed to those who provide liquidity. Given new avenues of value capture for MIR via this market module, LP participation becomes even more attractive, especially as arbitrage activity grows and trading is incentivized.

Value Drain:

An oracle alternative to an AMM could present a problem where MIR value is exploited via front-running or free-loading. Free-loading in this context is when a user burns Mirror for an mAsset, the Oracle price changes, and then they burn it back to MIR and swap to UST. Let’s follow an example for further clarity:

i. User Buys ~100 UST worth of MIR
ii. User Burns 100 USD value MIR via market mechanism for 100 USD worth of an mAsset.
iii. Oracle price goes up 5%
iv. User burns mAsset back for 105 USD worth of MIR
v. Users Sells ~105 UST worth of MIR

If MIR’s price remains stable over this interaction, new MIR will have been minted and sold to the DEX pair to dilute MIR’s value. Thus, free-loading only serves to drain the value of MIR. Front-running in this case involves free-loading but instead is related specifically to Oracle price lag. Terra solves both problems by having a market swap fee of 0.5% between Terra Stables and LUNA and a 0.35% Tobin Tax between Terra Stables. For Mirror implementation I’ve suggested we put users ‘on the rails’ where market mint goes directly to sell on a DEX while a DEX purchase goes straight to market burn plus a 0.5% market swap fee to prevent front-running and free-loading.

Forced/Scaling Slippage:

LUNA/UST implements slippage and liquidity limitations on-chain to prevent Oracle attacks. Lower liquidity is made available on-chain versus off-chain specifically for this reason. Fortunately, MIR and mAssets face a different interaction. All mAsset reference prices have billions of dollars in capitalization ‘off-chain’ that prevent mAsset liquidity from surpassing external liquidity. Factor in that stocks are not exchangeable for mAssets and a frictional barrier becomes evident that prevents most death spiral type Oracle attacks.

Given we lack any low liquidity Oracles, I argue that we’re safe from these forms of purposeful manipulation. As a preventative measure, I propose we keep slippage in at least some form to curb users searching for these types of exploits, regardless. If an ‘on the rails’ approach is acceptable, it may become useful to reduce market swap slippage and fees significantly to facilitate a better exchange rate where the DEX fees would then take on the task of preventing an attack.

Maintaining Solvency — MIR Price Impact:

To refresh, LUNA ‘collateralizes’ UST and other Terra stables via its burn mechanism which mints an equivalent value of Terra Stable versus burnt LUNA using its virtual AMM. In this way, LUNA’s main role is to absorb Terra Stable volatility. To note, a helpful feature with this mechanism is that LUNA can have a market capitalization far less than that of UST so long as LUNAs price and supply remain sufficient enough to absorb Terra Stable volatility. considering that Terra’s market mechanism (Virtual AMM) accrues both non-inflationary rewards denominated in Terra Stables and LUNA for LUNA stakers with each market swap, there should always be some intrinsic value to LUNA. With all of this in mind, how can we apply the Terra Stable/LUNA market module concept to Mirror?

In our case, MIR would be the one absorbing mAsset volatility. Given that DEX prices are consistently too high, there would be a need to burn MIR to mint mAsset. This adds a supply reduction mechanism into MIR which adds positive pressure to MIR price. Conversely, this also adds a supply inflation mechanism if there are DEX discounts relative to oracle price. Discounts are less common, however. Thusly, having a mix of less volatile, upward trending, and downward trending mAssets will be important in blending their individual effects on MIR’s supply. To note MIR would not support supply changes of mAssets like LUNA does with Terra Stables. Instead, MIR would only take on the burden of mAsset volatility. Liquidity demands would be met by CDPs. Also, using CDPs + MIR volatility absorption prevents MIRs lower market cap of $166 Million versus mAsset market cap of $173 Million from being impactful whatsoever to the arbitrage outcomes and peg stability.

Market Swap Time-Frame Availability:

Given that arbitrage is always needed for an mAsset to keep peg, the market module should be allowed to operate only during trading hours. I am unsure whether allowing the market module outside market hours would be beneficial. Allowing off-hours price discovery keeps arbitrage on market-open profitable while simultaneously providing a unique market application for Mirror via off hours speculation that can be reigned in. This is especially true if the ‘on the rails’ approach is implemented.

Other Technical Concerns:

Specifics on the particular curve implementation, base pool values, virtual AMM cooldown rates, virtual liquidity depth, and the mAsset market module whitelisting procedure will be addressed in a separate proof of concept document upon feedback on this idea by the community.

Closing Thoughts:

Using Terra’s virtual AMM market module as model in creating new ways to absorb volatility is a huge proof of concept for other protocols and other additions to Mirror. Specifically, I could see an ORCA like integration for a protocol to take advantage of my proposed Mirror market module whereby ‘bids’ could be made on DEX price premiums. Once a particular premium is reached, the platform would proportionally use bids to execute an arb. Essentially what such a platform would provide is the price security of Uniswap v3’s concentrated liquidity without its massive impermanent loss drawback, and without the need to actively LP. All the while the underlying pool would exist as a simple constant product curve with infinite liquidity bounds and ‘lazy’ liquidity provision. This is an extraordinarily innovative application specifically for DEX markets based on oracles. If a dynamic AMM curve is implemented into the virtual AMM, options contracts on Mirror could also become feasible given the ability for AMM outputs to change relative to an external input price; definitely more on this if the Mirror community likes the market module idea.

Let me know what you think! Discussions are happening all the time: feel free to post any responses/questions with a link to this article in Mirror Protocol’s Discord and Forum, or simply comment below!

Discord: https://discord.gg/KYC22sngFn

Mirror Protocol Forum: https://forum.mirror.finance/