Moving forward, it’s clear that these attack vectors do exist on the current implementations of Compound V2.
Instead of band aid solutions that don’t fully fix the problem, I would propose that the oracle implementation be fixed with the same solution that SBF uses on FTX. Collateral factors on long tail assets get adjusted very far down to account for lack of liquidity on both centralized and decentralized exchanges, and instead of ignoring price updates if they deviate more than 15% from the TWAP value, always update the price in the oracle, just allow up to a maximum of 15% price deviation on any update. This means if an update comes in that says the price changed 30%, the protocol instead calculates the price of the asset at a 15% higher rate and stores that. Additionally, there should be a minimum period of time enforced between oracle updates so these 15% changes cannot be applied in too short a period of time that would nullify the effect of capping percentage changes.
Removing the concept of the uniswap anchor would be helpful as well because it would simplify the oracle codebase and remove the dependency on a TWAP value that in some cases has less than $200k in liquidity on the uniswap V2 pairs.
The clock is ticking, and the longer the protocol takes to implement a solution, the more likely someone exploiting this economic threat vector becomes.