Mirror Protocol’s AMM Problem — A Potential Solution

Mirror Protocol operates on the Decentralized Finance platform Terra as a means to emulate stocks (and other cryptocurrencies) otherwise unavailable to users on the Terra ecosystem, and more generally, the crypto space.

It has been almost a year since Terra’s launch of Mirror Protocol, and its glaring issues are beginning to show. The platform is plagued with an elitist mindset that only certain assets should be ‘mirrored’ on the platform that has stagnated innovation and community interest. Alongside this unfortunate mindset, Mirror’s mechanisms have become contradictory in the advent of Mirror V2 having launched earlier this year — this will be the focus of our discussion. These issues have sent the value of the protocol’s native governance token (MIR) into a downwards spiral — an occurrence that all too many governance tokens face as their projects lose interest and innovation stagnates. There is, however, a solution to a portion of these problems.

It should be mentioned that Mirror, as a protocol, is extraordinarily innovative, allowing the tokenization of real-world assets, other cryptocurrencies, or, really, anything measurable that has a constant data feed. This allows individuals without access to overseas markets exposure to said markets and simultaneously provides an ecosystem where cryptocurrencies that otherwise might have extremely high fees to purchase/trade, are now affordably tradeable on the Terra Blockchain. You can even get paid in protocol fees via (MIR) token to support the functionality of the AMMs, through liquidity provision, that run the trading pairs on the platform.

What was wrong with Mirror V2?

Premiums, the price spread between the Oracle Price (real-world reference price) and the Terraswap Price (the exchange price), prior to V2, was an immense problem. Such premiums reached upwards of 10% or more!

As a way to fix this, V2 introduced short farming which has resulted in a significant reduction in premiums (the average now ~2 to 4%). Unfortunately, a new, greater problem has emerged. This is the important part — short farming allows users to earn interest by attempting to stabilize Liquidity Pools through a contract that mints a mAsset and sells it to the Pool in exchange for said interest. This is supposed to add more mAsset to the Pool while simultaneously removing UST from the Pool for 2 weeks (as a note, the UST the contract gets from selling your minted mAsset to the Pool is locked for 2 weeks) to hopefully balance the Pool towards 0% premium. Unfortunately, there is nothing stopping someone from buying an equal amount of mAsset with other funds they might have available. The result? An essentially zero-risk farm solution where all one has to do is manage their collateral on the short-farm while earning juicy, free APR.

What's so bad about free rewards, that sounds great!? Rewards for those providing liquidity to the system (long-farmers) are shifted to short farmers as premium increases based upon a predefined scale; however because these zero-risk farms (delta-neutral strategies) have a net-zero effect on the liquidity pool, delta-neutral strategies only end up draining the rewards meant for those actually contributing to the reduction of premiums.

The Solution?

Change the AMM curves to remove the premium issue entirely which, in turn, simultaneously eradicates delta-neutral strategies.

This is where things will get a lot more technical. I will be referencing an academic paper regarding Dynamically Adjusted Constant-Product AMM Curves that rely on an external market price (Oracle prices) for adjustment. To note, Terraswap AMMs rely on the constant product formula to equilibrate prices — the unfortunate side effect is that only arbitrage can bring the price of the AMM close to the Oracle price. Given a constant Oracle Price, premiums wouldn’t exist if all liquidity providers were also minters; however, the purchasing of a mAsset and subsequent provision of liquidity with the purchased mAsset and one’s own UST results in a greater proportion of UST present in the Liquidity Pool relative to the mAsset. This greater amount of UST vs. mAsset results in the premiums we observe. However, because the Oracle Price is not static, this function is required to allow arbatrageurs to catch the market price up to the Oracle Price. The aforementioned Dynamically Adjusted Constant-Product AMM Curve would eliminate arbitrage entirely while simultaneously locking the AMM’s trading pair to the Oracle price. See the math and full explanation below:

Why not just remove short farms?

By implementing this method, short farms very well might go away; this new method removes the entire premium problem, permanently, while opening doors for other incentive solutions for newly created problems that are much easier to solve. I will outline how ‘traditional’ constant product AMM’s function as a baseline before going even deeper.

Constant Product AMM Equation:

Where X is one token and Y, the other. For the purposes of this analysis, we will define X as the mAsset component and Y as the UST component. We will also be ignoring transaction tax and AMM fee to keep things simple as they’re identical between the two methods (Constant Product vs. Dynamic Constant Product)

Other Equations:

‘A’ denotes mAsset token, ‘B’ denotes UST (affixes ‘in’ and ‘out’ denote direction). Users provide either ‘A’ or ‘B’ for the ‘in’ component depending upon a sale or purchase of mAsset.

Now for an example:

Notice how 10 UST doesn’t quite earn the User 1 mAsset; this is a result of the Constant Product Curve doing its job. The greater the UST spent to purchase mAsset relative to the amount available in the Liquidity Pool (AMM), the greater the cost gets per mAsset. The resulting price follows a curve. As a note: 100/101 ~= 0.990099

As you can see, this functionality is consistent with the behavior we see in the current Liquidity Pools on Mirror.

Dynamically Adjusted Constant Product AMM Equations:

‘w’ and ‘a’ are arbitrary variables chosen to represent the adjustments that need to be made to the original Constant Product equation. Note: w(t) must be strictly positive; a(t) must always be less than the value of x(t). x(t), y(t), k, and Oprice(t) must also all be positive where Oprice(t) represents the Oracle price at time t. Note: x(t) and y(t) do not change until, or if, a swap occurs; a(t) and w(t), however, change as Oprice(t) updates. Also, if there has been no dynamic adjustment to the pool, xy = k remains true.

Other Equations:

Note: these equations simply substitute in the variables that dynamically adjust the curve where they are applicable. REMINDER: ‘A’ denotes mAsset token, ‘B’ denotes UST (affixes ‘in’ and ‘out’ denote direction). Users provide either ‘A’ or ‘B’ for the ‘in’ component depending upon a sale or purchase of mAsset.

There are simplifacations that can be done to reduce the number of variables and overall messiness of the formulae, however, I have chosen to keep them as is to improve readability to let people follow along more easily.

Now for an example using the curve adjustments:

Notice that x and y are the same values here as they were in the original Constant-Product AMM Curve example, the only difference present is the Oprice of 12 UST. Also notice how 10 UST did not purchase the same amount of mAsset as in the original example; in this case, because the ‘price’ per mAsset is set to $12, we expect to receive an amount of mAsset at that price, which we see in the above example. Notice how *Price is not exactly $12, but just over; if you recall, this is the same exact behavior we see with the original Constant-Product AMM Curve whereby the greater the proportion of mAsset purchased relative to the size of the pool, the greater the ‘slippage’ cost will be.

Explanation and further solutions:

The dynamic adjustments made to the AMM Curve correct the values of x and y in the original Constant Product AMM equation to continue to offer the same price (Oprice(t)) at any given time ‘t’ regardless of the pool concentration and the amount of mAsset or UST being exchanged with the Liquidity Pool. Note that slippage still occurs. Unfortunately, this method allows a user to drain the entirety of the pool’s mAssets, or UST if they so choose (the latter would require the user to mint mAsset, so it is less likely one would expose themselves to such risk). Mind you, it would take millions of dollars to do either ‘exploit’. However, this opens the door to allow LP incentives in a new way. With premiums gone, the number of mAsset and UST in the pool is all that matters. Instead of strictly short farming or long farming, one could replace current LP methods with a LP token that incorporates minting alongside liquidity provision in a combined contract where your risks are equivalent to current ‘long farms’ with an included requirement of managing a collateralized position like in the current ‘short farm’. This method would add both mAsset and UST to the Liquidity Pool subsequently streamlining the liquidity provision process, reconsolidate rewards under a single LP method in values that would attract users from the Terra Ecosystem, or elsewhere, while the new curve improves the market price peg to be essentially perfect.

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

Discord: https://discord.gg/KYC22sngFn

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

If you’d like to donate, you’re welcome to send any contributions to this Terra Address for more content and future Mirror Protocol coverage: terra1ha2gag2cxt4dm2qmvlltkvp688ypeuxsafkuh2

References:

Krishnamachari, Bhaskar, et al. “Dynamic Curves for Decentralized Autonomous Cryptocurrency Exchanges.” ArXiv.org, 7 Jan. 2021, arxiv.org/abs/2101.02778. — Paper outlining the Dynamically Adjusted Constant-Product AMM method.

“Mechanism.” Mirror, docs.mirror.finance/protocol/terraswap. — General information on the functionality of Mirror Protocol.