The clearly disruptive market action and missteps by the team in handling the migration illustrate that the current design for handling stock splits is not adequate. The current design is going to cost the masset holders upwards of 2% in losses due to trading costs and potentially more if there’s a large market move while they have zero exposure to the asset.
This is entirely unacceptable and unnecessary. I’d like to propose that the team’s resources be pointed toward building a new mechanism for handling stock splits that is effectively a re-denomination of the debt for the vaults and a feeless (other than gas) token swap.
The upcoming stock splits have illustrated the following glaring flaws in the current protocol design for handling a regularly occurring corporate action in equity markets:
mAsset holders lose their exposure for at least half a day (nearly 3 days in the case of the botched mIAU announcement). Instead of delisting at the same time as the new asset becomes live to allow for an immediate exposure migration, the team has questionably chosen to stop trading after the last time the Oracle price is published the previous business day. Forcing your investor to lose their exposure for even a small moment in time is basically unheard of in the investment world and a massive risk from a portfolio management perspective.
The delisting results in a collapse in the spread between the masset and the underlying. Typically, massets trade a premium of 1-2% to the underlying due to the costs associated with burning the masset. The current design requires that the burn fee be removed after delisting. Trading volumes spiked nearly 10x with large selling pressures in the split assets because removing the burn fees means that at some point the masset price must revert to the oracle price.
Masset holders are punished with unnecessary trading fees. To regain the exposure they lost. Long masset holders are forced to buy back into their position. This means they’ll pay 0.25% for the trade along with another 1-2% loss because the burn premium will be present for the new masset.
The pending delisting results in a loss of liquidity. Because of the issues described above, investors will flee the masset early and the liquidity will drop. This makes it even harder for other investors to exit their positions and they pay even higher costs as a result because of the large amount of slippage in constant-product AMMs.
Risk of losses due to under-collateralization and receiving undesired volatile assets. Massets can be collateralized by tokens other than UST and this will become a bigger problem with Mirror v2. Long masset holders don’t know what asset they will receive when they burn the delisted asset. It may be UST, or it could be something they don’t want (e.g. burning mIAU and receiving mTSLA). This makes burning a huge gamble, especially when the collateral factor is set at 100%. If that risky collateral goes down in price even a penny, you will receive back less than the last price of the delisted asset. Imagine if mIAU was backed by mETH when it became delisted at 4pm this past Friday.
All of this can be avoided with the following redesign to the platform:
The open vaults get their debt migrated to the new token and oracle. Following the close of business the day before the stock split, burning and minting of massets will be disabled as usual. When minting and burning resumes the next morning, the vault will owe the new masset* and use the new masset oracle.
A simple token burn & mint mechanism is created. Holders of the old masset can exchange their old token to the new one.
You don’t need to halt trading in the old masset. The market will know that it is reliably exchanged for the new one and people will exploit the arbitrage if it becomes mispriced relative to the new asset. I’d expect most of the liquidity to migrate quickly because the MIR rewards will switch to the new asset. This allows for an efficient (only paying gas to swap) migration to the new masset without the massive downside risks and market disruption caused by the current design.
I’m certain #1 will require a decent amount of engineering work, an audit, and potentially a vault migration, but it’s far from impossible. #2 is simple.
Let me know what you think and if there’s support for this. If necessary I will pay the bond myself, but will likely wait until voting changes to make quorum easier.
(*You could also design the vault to accept both old and new collateral by scaling the new oracle appropriately, which may be convenient to have. I was initially concerned that only accepting the new collateral could result in a short squeeze if not everyone migrates their position, but that’s not actually the case. Having some left over holdouts not migrating from old asset to new is no different from a short squeeze perspective than if you have someone that refuses to sell their long position at any price.)