I think it’s great to see discussion about the risks of the OSM, but in my opinion rather than zooming in on the auctions, I think it is a much better direction to discuss how to improve the OSM and make it more secure, and I already see a lot of great suggestions on the topic.
On that note people here might find it relevant to take a look the MIP1 problem spaces that relate to the OSM, such as Decentralized Oracle Freeze and Emergency Oracles.
Focusing specifically on trying to make auctions resistant to OSM failure misses the mark, because there are already other aspects of the protocol that critically rely on, and assume, that the OSM will always report true values.
Most importantly is triggering liquidations, and calculating emergency shutdown settlement. Both of these result in catastrophic failure if the OSM fails - if Maker liquidated all of its collateral simultaneously in a fire sale due to a failure of the OSM, it wouldn’t really matter if the auctions had a correct starting price, it still wouldn’t be much different from selling everything at 0, and obviously it’s an outcome that is completely unacceptable to users no matter what. So it has to be prevented from happening in the first place by governance.
Same goes for emergency shutdown, if the OSM failed, an emergency shutdown could be manipulated so that either all Dai holders, or all Vault holders would lose everything and the other side would gain twice as much in the settlement. Again an outcome that would be completely unacceptable if it was even remotely a possibility in the long run, and has to be prevented by governance for the Maker protocol to be viable.
So my point is, if we’re worried about failure of the OSM, I think the solution is to try to improve the OSM and make it more robust, not spend precious time on trying to come up with a perfect auction auction design that’s resistant to the edge case of OSM failure, while at the same time ignoring the other critical, unacceptable outcomes that would happen as a result of an OSM failure.
The smarter approach is to tackle the two issues separately to avoid getting stuck, and finish the auction design first without focusing on the OSM failure edge case. Because getting it done would then create space for the community to move on to new features that would address the OSM issue directly, and for all aspects of the system - not just auctions - such as the suggestions already posted here, or another example would be things such as the Decentralized Oracle Freeze and Emergency Oracles mentioned above (both are MIP1 problem spaces so you if you want to learn more about them you can check out MIP1).
A final, but important point to add, is that the auction system, like everything else, can always be upgraded later with more sophisticated and complicated logic. Given the amount of work that still needs to be done to prepare Maker for self-sustainability, I don’t think that now would be the right time to try to build a perfect solution that would never need to be revisited.
So even if it hypothetically is possible to create a solution that mitigates impact of OSM failure for auctions, and does so without compromising economic efficiency, there is still no reason to focus all energy on having that implemented from day 1. Instead it can be done in the future when other, more pressing issues are dealt with.
Thoughtful prioritization will be critical if this community is to be successful in holistically navigating all the risks that the protocol faces.