Many concerns have been raised about the current oracle and swap mechanisms, including the potential for undesirable arbitrage between on and off-chain markets, off-chain price manipulation, unrealistic spread behavior and more. Recent volatility in the crypto markets, which has naturally affected the price of Luna, has exposed some of those weaknesses. This fine lady/gentleman was able to earn a handsome profit in Luna and KRT equal to roughly $12K (based on our estimates) purely from on-chain swaps — credit to Paul Kim for uncovering and calculating the damage. This profit may well have been risk-free — a likely explanation is that the price of Luna was manipulated off-chain, giving rise to profit opportunities on-chain.
The broader concern, however, is that the swap mechanism is giving rise to attack vectors and arbitrage opportunities when the price of Terra is perfectly stable. The on-chain market’s very reason for existence is to create Terra arbitrage between on and off-chain when its price diverges from the peg. And yet, by looking at current Terra and Luna prices, it is clear that whatever arbitrage arises between on and off-chain markets is a result of Luna’s price changes, not Terra’s.
One way to look at this conundrum is that the protocol is acting as a market maker for the wrong asset: it is meant to be a market maker for Terra, not Luna. While strictly speaking the two go hand in hand for the Terra/Luna market, Luna is only supposed to be the medium that serves to keep the price of Terra stable. Liquidity is most important when demand for Terra changes — either increases translating to a price above the peg, or decreases translating to a price below the peg. In the former case it is crucial that the protocol can sell Terra, in the latter it is crucial that it can buy Terra. When none of the two is happening, the protocol is offering no particular service to Terra holders — rather it is acting as a Luna market maker in exchange for an asset that is stable. And it is bound to be quite lousy at that: it receives a delayed price feed, it is susceptible to misreported prices and so on. The implication is that swap liquidity is crucial when the price of Terra is drifting away from the peg, and potentially damaging when it is trading at the peg. The farther from the peg Terra’s price, the more important liquidity becomes.
A reasonable objection could be: isn’t Terra stable exclusively because the protocol is making its market using Luna? If that were true, reduced liquidity around the peg could compromise it. In practice, this is almost certainly not true. Terra has purchasing power at an increasing number of e-commerce companies equal to the price it is pegged at (often higher given the discounts it gives access to), so there are many reasons to buy it at face value beyond receiving Luna in return. There is also a significant number of market makers willing to buy and sell Terra’s price close to the peg using fiat, i.e. regardless of Luna and the on-chain market. The existence of the on-chain market is of course essential, but is not the only reason there is demand for Terra at face value, and it certainly does not need to be the first line of defense in keeping Terra stable. In fact, I think that the on-chain market should be the last line of defense, and it should be optimized to do that job alone superbly well. The core stability mechanism, i.e. adjusting transaction fees and burn rate to maintain stable Luna demand, has been designed with that purpose in mind. We should consider adjusting the swap mechanism to serve this essential and more limited role. What do you all think?
There are many ways this could be implemented in practice. A straightforward implementation based on the current Columbus 2 swap/spread mechanism would be to increase the daily Luna supply change cap the further Terra’s price drifts from the peg (or the higher its volatility), starting with a very low cap when Terra trades at the peg or is highly stable. In other words, offer limited liquidity when Terra is stable — increase the spread very rapidly in response to swaps, and increase liquidity the more its price diverges from the target — increase the spread more slowly. Thoughts or alternative proposals?