The system (ie. protocol) is designed to mint and burn - I know that may not be popular, but it was the way it was designed per the market module, and updated in columbus-3 to a constant product, as a way to balance out the swaps between protocol coins when swapped through the system (it is what enables a constant product for the virtual liquidity pool - with the limitation for pool recovery period in number of blocks). The market module (and accompanying custom modules) are the current application on this application specific blockchain (the application it was designed to run, and at least until the depeg it was the application that distinguished it). The LUNA v1 <> TERRA v1 “stable” swaps were shut off as a result of this pull request back in May 2022 to stop the oversupply of LUNA v1 as it continued to devalue (since more and more LUNA v1 was required to mint to exchange for the TERRA v1 stables, particularly UST, that was being swapped back using the protocol).
Unlike LUNA v1 <> TERRA v1 “stable” swaps (which are closed), the TERRA v1 <> TERRA v1 swaps are still active. The protocol still sees each of the TERRA v1 “stables” as a synthetic of their real world counterparts (and prices them at their real world values). When oracle pricing data sources feed bad information, and the validators are not using varied sources, and that data source feeds wrong information, it allows a situation where there is a mismatch in underlying value. Since all TERRA “stables” are denominated in SDR, when you swap one TERRA “stable” for the other “stable” it burns the one stable and mints the other stable (even though it uses the same side of the virtual liquidity pool). Where the underlying value in SDR is the same, the value between the mint and burn is cancelled. When there is a discount due to mispricing, then that particular swap is no longer of equal underlying value and the minting outweighs the burning, even though they are trading into the same side of the virtual liquidity pool (so it shows an increase in minting - I believe the same would happen if the mispricing were in the other direction and someone just happened to swap out of the mispriced “stable” during the mispricing within the protocol, it would burn more than it mints).
It is true that EK did make a proposal discussion in Oct 2022 to make the tobin tax 100% for all TERRA “stables” (to discourage swapping TERRA stables through the protocol), and favored that approach to removing them from the whitelist (which removing them from the whitelist would effectively make them unusable within the protocol for those who owned them). He did mentioned in that proposal discussion that “We are leaning towards the tobin tax approach so that community members who may want to help build the oracle reward pool could do so by swapping their stablecoins to USTC, thus sending all swapped USTC to the oracle rewards pool.” I had concerns due to the tobin tax on SDR, as well as the removal of SDR from the whitelisting (the alternate solution), since the protocol internally uses SDR to value everything. Since I did not see any testing results that indicated how the protocol would deal with either no SDR pricing, or a 100% tobin tax on SDR, it was one of the concerns that I had raised. I had further reservations since it appeared that mitigations did exist and it appeared to be a fiat pricing data source issue. At EK’s suggestion, I did do research, and posted a possible solution to the validators (and have posted essentially the same thing to validators in another venue, and have referenced it multiple times in regards to the oracle pricing data sources and fallback order).
The real issue in the last MYR situation in Sept 2022, as well as this situation, is the data source itself, and that too many validators were using that same data source, or sources that were using the same data (the sources were too concentrated on one data source). In the documentation it specifies that validators are able to setup their oracle feeder and data source(s) for decentralized pricing, but that events like this enable validators to know something is wrong in the pricing and to reconsider their fallback priority order (as part of decentralized pricing). There are other security implication issues (apart from this one) that are good to keep in mind too, such as too many validators using the same public LCD to submit oracle votes over verses varied LCDs or a private LCD (if someone spams the public LCD and no faithful validators are using a different LCD, this can prevent successful oracle voting - for instance). In addition, the oracle price-server could use some TLC in regards to a review to determine if the oracle price-server can be updated to be smarter in determining when one price feed to the price-server is wildly off from other sources in the fallback order, for a particular denomination, and make a determination as to the correct pricing (which can still be error prone, but prioritizing errors in data over correct pricing in a complete market crash seems reasonable, since the errors in data are much more common than a complete market crash - this, or other solutions, could be researched to determine if this type of solution is appropriate or not).
For some reading and research on the current oracle design and process, and the Market module itself:
- Documents:
- Design On Current Oracle:
- Market Module Research:
I hope that helps a little bit more (from my previous comment).
I hope you have a great day today 
