Using the 3.5 day median isn't great because it may be a lot higher than the current price at the time the conversion is initiated just due to market fluctuations, which may result in very low collateral, even without any manipulation.
With a 2x collateral requirement, the risk for too low collateral would require the 3.5 day price to be more than 2x the current price (and the likely price at the time of the conversion). But admittedly crypto prices can be quite volatile.
I meant minimum of the hourly medians, so any individual witness with a bad price would be filtered out. This is already the current mechanism in the code.
Ok, minimum of the hourly medians sounds more reasonable, since it shouldn't be subject to manipulation by a single price oracle. Since I've never reviewed this code, I didn't know these were calculated.
I'm still a little concerned about using a single data point over the entire period though, since flash crashes do happen. What about using the min (total period median price, most recent median price)?
Now, this doesn't protect against a trade performed right after the current price has dropped below that value, but neither does using the worst case during the period. There is a fundamental issue because we just don't have the current price to reason about due to the rate at which oracles are feeding in the price. So if we accept that limitation, the only way to mitigate it would be to further increase the collateral ratio (e.g 3x collateral).
RE: Proposed hardfork change to stabilize Hive Dollar’s tracking of USD value