Mirror DEX Solution

Hey all,
Mirror Steering Committee member here: We see that premiums are way out of control, we’re working on it. Unfortunately, not much can be done until proper liquidation mechanisms are implemented (ongoing). In my personal downtime I’ve been working on a solution for premiums for a while and people have expressed the idea of creating a Mirror based/owned DEX as a way to address premiums, whether through a dynamic fee structure, concentrated liquidity, or otherwise. Below you’ll find my recommendation as to what I think would work super well to not only improve capital efficiency, but also provide Mirror more options or tools to fix said premiums:

A huge problem with current Mirror is that each premium has to be adjusted relative to individual mAsset conditions. Minimum Collateral Ratio plays an enormous role in how individual pools behave relative to Oracle prices, evident to the recent mKO and mSPY flippening to huge discounts from prior premiums. Attempting to figure out the most optimal MCR relative to each mAsset, or by implementing an entirely external vAMM to a normal AMM to allow new methods of minting, as I’ve discussed previously in two of my articles, can work, but are extremlely complex, risky, and are difficult to implement on-chain.

Enter my creation of a new pooling method using a vAMM. If you haven’t looked over the paper, do so now. By pooling UST into a single, large pool and then by breaking the allocation of said pool down into chunks relative to mAsset pool size according to Oracle Price, premiums become a more solvable problem. By addressing premiums as a global function, reward allocation becomes much more effective at combatting premiums. Within the conclusion section, you’ll notice my reward structure recommendation. In regards to each of the types, I have this to say:

Type 1: This would be helpful in keeping rewards trackable and liquidity available to frequently traded mAssets; there would be very few surprises as a result of the lack of moving parts.

Type 2: This would be extremely impactful in swaying users to provide more UST or mAsset relative to the global premium. The issue with this is that it’s a very crude solution for small premiums. Individual mAssets that are heavily traded would not be prioritized as a result of blanket reward rate adjustments.

Type 3: A combination of the first two types, perhaps with caps, would allow for a more dynamic environment where causal relationships as to what exactly is influencing premiums would be difficult to determine. Liquidity wars would certainly be fought under this method as rewards would dynamically adjust on both UST and mAsset sides alongside the war on premiums. Highly complex, but potentially worth it.

To note, rewards would not need to be allocated based upon premium, but based upon what users vote or decide given that premiums would be global. This way, liquidity is partitioned to pairs that need it. A veMIR could be implemented alongside this pool to allow for such gauging/voting.

Let me know your thoughts.


Great outside-of-the box idea here.

Anyone have any thoughts on how something like this would actually get built given that TFL doesn’t seem to be too involved with Mirror at the moment?

I can build out the smart contract logic, I just have no idea how to code in rust, sadly. I’ll add any follow-up implementation methods onto the forum post as they come.

Great idea, thanks for your work. Can you give us an update about the current stand of the Mirror Steering Committee? Is your idea the number one idea currently, are they backing it? If so, how’s the implementation going, when can a proposal be live about it?

Those in the MSC do support my idea for a Mirror-based DEX. It’s the best solution insofar as how it approaches/breaks down the premium problem. I’m almost done working out the smart contract logic which I’ll add to the post as soon as I’m able. I’d expect a text proposal within a week or so given I’m able to get what I want up on the post. Building it and getting it put on the protocol will require some dev-help so a bounty will be built if the gov poll for it passes.


I think most of us perceive the MSC budget as earmarked for liquidation mechanisms bounties and audits, because that was our initial ask. Building out our own DEX would have to come in second (if there is enough funding left for the bounties and audits after liquidation mechanisms are upgraded) or require a separate funding proposal for its own bounties. It’s a big complicated ideas, so it could be more expensive to develop and audit than we currently have budget for.

I like the DEX solution at a high level, but as I said in the MSC chat I need to see more of the specific process flows and pricing calculation logic because it sounds like it will have dangerous oracle dependencies (or not be available outside of extended market hours) that make it vulnerable to certain economic attacks.


I can find other ways to fund the bounty, need be; I’m not so worried about that part. In regards to the concerns, I’ll have responses up soon as I mentioned~

1 Like

sounds like this has potential. would love to hear the thoughts of @Sihyeok and co re; this.
thanks for your work.

Although the technical details are above my head, I like the general idea. Thumbs up for activity and further development on this front.

What happens in multiplex pool if some mAsset is very demanded and its position in pool goes to close to zero? Lets simplify it to the case that someone places big order and buy all remaining pieces of the mAsset from the pool.
In standard pool price of mAssets and reward increases dramaticaly, in the multiplex pool all mAssets with increase slightly? Then also the mAsset which was sold out increases premium only slightly, right? Can it lead to situation that premium is not motivating for minting new pieces of mAsset?

I believe the most critical issues with Mirror Protocol now is the “random” liquidation of short position. WIthout solving this urgent issue, the rest of effort will be futile.

I’ve actually been thinking about this recently;
The scenario you noted is correct; importantly, immense premiums will be equalized with all other mAsset UST concentrations which would make it more difficult to take advantage of price differences resulting from either a global discount or global premium. In other words, liquidity depth increases, but potentially to the detriment of allowing prices to move towards Oracle. Several solutions to this are as follows:

Multiplex Pool-specific solutions:
1.) A reward allocation system, whether it’s a gauged system like I suggest in the paper or otherwise, would allow users to put their LP towards mAssets that are in need of liquidity which would be voted on (or auto-allocated based upon mAsset liquidity in $) to receive more rewards (such as those in your example). This is specifically in regards to the rewards allocated to the mAsset side.

2.) More efficient LP methods (single sided) would let users be more flexible in how they take advantage of price differences and dynamic incentives, especially if a gauging system is in place.
The greater UST-mAsset reward balance would be determined based on something like what we have/want for short farms where, if there is a premium, mAssets provision rewards will be higher compared to the UST side

3.) Only rebalance the premiums a set number of times a day rather than every block. This would allow prices to act independently of one another, but still stay relatively balanced pool-price-wise day to day. Problem with this would be bots who might take advantage of the price shift and also liquidity depth bonus of this system is lost intraday.
*A middle ground would be to have a delta system that keeps track of changes/deviations from what a perfectly equilibrated set of pools would look like that converges to the point of equilibrium at a pre-defined rate (like how LUNA/UST’s market mechanism replenishment mechanism works). This will take some more thinking for sure though (the math might be hard to implement on-chain)

More ‘out-there’ Solutions:
4.) A treasury implementation that, under very specific conditions, is allowed to take or provide a portion of UST from the UST pool as a ‘service fee’. This treasury would use its funds to balance pools in the long run. This one I haven’t thought about that much tbh so it could be bad, just a thought.

5.) Others have spoken about adjusting the CDP fee to be less, or dynamic even; If a treasury exists, CDP creation could be subsidized (have the creation fee be negative when premiums exist), but then have it cost the subsidization % + some more minor fee to close the CDP to prevent users from exiting when liquidity is required.
The whole CDP fee existing is its own can of worms I’d like to work on separately; maybe make a system that allows short farming (net mAsset contribution to pool) that HAS a creation or closure fee, where normal minting (simply creating and then sale of) does NOT. Problem with this is that you’d have to lock liquidity provision, or minting, to specific contracts that ONLY allow certain behaviors (to prevent harmful DN)

6.) Create bond-esque liquidity provision opportunities that guarantee a %APR given current pool conditions. This bond would have some expiry date. The reason I suggest something like this is that passive LPer dominance (set it and leave it users) makes it hard to actively adjust mAsset premiums. Using NFT’s as a way to implement this would be pretty cool as well (unrelated to a jpeg, and more the non-fungible storage of information as a ‘token’). If there are methods that beneficially support active LPers, balancing things might be better off.

What I’d like to do:
It would be super helpful to breakdown the current concentration of positions (short vs long vs DN) according to each mAsset right now to model out what a multiplex pool application might look like in practice. Doing so would let us know what the global premium/discount might be, as well as what mAssets would be contributing to premium/discount the most (depending upon the value of short, long and DN positions). Just haven’t had the time or ability to query the chain personally (also might take a long ass time for a computer to sift through due to sheer size of the chain).

The goal of the multiplex pool is to let Mirror have more versatile, yet sweeping, tools to tackle premiums more effectively. Right now, each mAsset deals with premiums individually which is VERY hard to fix unless you have some arb-treasury, or another way to mint mAsset w/o strings attatched to a CDP. My hope is that, with a dynamic fee/reward structure alongside a multiplex pool, premiums will be able to be reigned in.

Edit 1: Formatting
Edit 2: Clarity


That’s mostly due to after-market/pre-market Oracle reporting. The issue lies in that, if we remove minting during pre and post market, Mirror users are at a disadvantage compared to tradFi users (who can short during pre and post market).

Might be worth separating trading sessions into CDP types?
Perhaps have a permanent, normal session CDP that only is liquidated during trading hours and then a temporary pre/post-market CDP that’s converted to a normal one at the start of the next trading session. This way, users aren’t liquidated during off-hours, but are still able to create new positions during said hours. Keeps speculation, but prevents unwanted losses.
Not sure if it’d be wise to allow the shifting of Normal CDPs to extended hours CDPs; maybe for a minor fee?

Great thoughts. I think some of these solutions would be best if used collectively, that way the price pegging system would be more “decentralized”, therefore it’d be more effective - more ways to earn higher yield or get lower fees would result in new traders and in the end more liquidity. If we want Mirror to be successful in the long run, we have to draw in new participants. The EU Parliament agreed on tracking down crypto wallets related to CEXs in the near future (a tendency which will be followed by more countries I’m afraid), so Mirror would be in a really favorable position, if a solid, tried system would await the fleeing mass. In the current form though, the protocol is not supporting short term traders, but I think that this community must be the target audience.

Commenting on the solutions:
1.) The reward allocation system regarding the need of liquidity would urge the yield farmers to give in-depth liquidity to all assets across-the board, which is a must have feature IMO.

2.) Single sided staking is always welcome, canceling out IL risk would be attractive for cautious farmers - more liquidity coming in is sure nice.

3.) I think the refracted daily premium rebalancing would only benefit the farmer community, while it’d make the protocol unusable for day traders.

4.) In the perspective of sustainability for the long run, I think that using treasury funds in order to rebalance the price can be only an emergency solution, but in case of your multiplex pool idea (and especially if these other ideas are also implemented) it seems it just wouldn’t be necessary.

5.) Highly encourage to rework the CDP fees to a dynamic structure, my suggestion would be to build a time-based structure. If the position is closed within the day for example, only a 0.1% fee applies, if the position is opened for a week it’s 0.5%, and so on. Also, a multiplier could be attached to it, if longing into high premium/shorting into low premium (bit like some CEX’s maker-taker fee structure). Negative creation fee above/below a certain premium with a certain lockup period maybe? Without lowering the fees, highly doubt that short term traders would use Mirror. It’s common interest, with more volume comes more trading fee to the farmers.

6.) Interesting idea, but concerned about that fixed expiry date in the case of large liquidity could cause huge fluctuation in the price on the given day. Also, in the case of UST-mAsset pairs it’d be fairly risky to be in a fixed expiry pool, given the lack of ability to “roll out” the IL risk in case of huge short term price swings. Maybe in case of single sided pools it’d be useful.

About the LP dominance question and also reflecting to the delta rebalance idea, maybe if part of the trading fees would be used to systematically buy/sell assets based on the premium would work out. Thoughts?

1 Like

IMO no need to separate things, but also let pre/after market trading. If you can’t close your position in the after hours while everybody’s dumping the asset viciously and the market opens the next day at -30%…that’d hurt even badly.

1 Like

Thanks for the reply!
Agreed on pretty much everything. In regards to your comments:
3.) I agree, I don’t like the idea of limited rebalancing times (once at the start and once end of day). Either farmers or bots would take advantage of the abrupt swings at those times.
4.) I was meaning in the case that, suppose a global premium exists: A treasury would take a percent of that UST causing the premium (removing it from the pool) which would reduce the premium outright. Then, if there ever became a global discount, these funds would be used to buy mAsset. Rinse repeat for the other way.
5.) I’m not sure a time based fee that increases would be ideal. If it scales higher over time, then it incentivizes users to exit sooner rather than later, which helps traders, but not those who LP. If you have it the other way, it hurts traders, but helps LP. Thus my italicized idea of having short-LP and short-only where only short-LP has a closure fee where short-only can close at any time; each method has its own audience in such a case.
6.) I had similar concerns, but figured I’d throw it out there for discussion; only saving grace would be single-sided LP in this case. Definitely want to think this one out more to see if it can be made to be effective. This wouldn’t be the sole lp method, just a more risk-averse, active LP method.

LP dominance/delta-rebalance comment:
This is another idea that’s been thrown around as an intermediate solution between a highly oracle reliant pool (multiplex) and a normal AMM.

1 Like

Yeah, I kind of realized I overcomplicated things after the fact lol. Decided just to leave it~
Honestly could just disable extended hours liquidations but continue to allow minting/burning and it’d accomplish the same thing. Not sure if it’d cause insolvency given that usually, if you’d be liquidated in off-hours, you’d also be liquidated on market-open, so long as the off-hours session didn’t have any huge spike in miscellaneous trading. It’d just filter out those erroneous off-hour liquidations.

1 Like

To the fees:
What about to set up fixed LP entry (or withdrawal) fee for Multiplex pool? It could be lower for mAsset-UST pair and higher for single asset position as it does not have IL risk.
Entry or withdrawal fee would motivate LP providers to provide liquidity longer and not to withdraw on every decline of APR rewards. Plus it could be another source of income for MIR holders or it could allow to lower closing fee for shorters.

4.) I thought something similar, but your take is even better.
5.) I wasn’t too concrete, adding that the 1,5% fee would be the cap for longer periods, just like it is now - in this way the short term traders would also be served and lured into the protocol, and also the liquidity providers with longer time horizon would still get the same profits as now. If not even this way, I think somehow we must differentiate the lower/higher position opening fee while also encourage people to not just use Mirror like a yield farming protocol.

Regarding pre/after hours: I’m not sure how it would effect the system if the users could still mint/burn mAssets in order to prevent their liquidation in those timeframes, but given there’d be no need to rebalance the prices through that liquidation process, maybe it wouldn’t fuck up the system.

Btw, I’ll gladly help with the sorting out of the positions, if you know where to find data about it. The other day I tried to search in this topic but couldn’t find anything meaningfully useful.

As I see it, the UST-mAsset LP providers are already motivated to hold for longer periods given the 1.5% fee currently active, if there’d be no change in that fee, they’d continue to provide liquidity as practically there’s no change in their profitability. They’d still want to get the yields in the longer run from trading fees and MIR rewards, we just need to ensure that a relatively high closing fee prevent them from getting in-out frequently. Lowering the 1.5% for them could cause unwanted day-to-day LP fluctuations.

Therefore by reworking the CDP close fee structure it seems to me that the targeted audience could only be the directional, short term traders in order to keep the current level of liquidity in the pool(s). The directional short term traders cannot rely on yield farming, and the high closing fee makes it really hard to profit from price swings while maintaining significantly higher risk. So effectively the new fee structure should aim to differentiate these two type of users.