I like the idea, and it would work well in combination with a 24 hour delay. And, importantly, the mechanics still look fairly simple to implement.
You are viewing a single comment's thread from:
I like the idea, and it would work well in combination with a 24 hour delay. And, importantly, the mechanics still look fairly simple to implement.
After considering this a bit more, the initial price should use either your method of the minimum of the most recent and median price, or perhaps even better, the minimum of all the prices in the feed history (currently 3.5 days or 24 hours if this were changed).
While temporarily pumping the price doesn't affect the conversion rate in this model, it does reduce the collateral required, increasing the risk of the blockchain taking a loss (which would be a benefit to the converter), so we should defend against that. Using the minimum of the entire feed increases the collateral required when recent price volatility has been higher, which is probably desired.
The converter's "collateral price" in this case is already a 3.5 day median. So it's presumably a reasonable price, unless you're concerned about the price of Hive being persistently pumped over a 3.5 day interval.
At 2x collateral, the converter already has to deal with being exposed to a price 2x his "expected" price (i.e. the median price at the time of the transfer), so it kind of feels like enough risk to me.
And a minimum over a 3.5 day period, or even a 24 hour period could potentially be very low, especially if there was one malicious witness feeding a low price. A single witness could effectively negate use of the conversion mechanism in this case.
My proposal above was the use the most recent price. 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. (This was the motivation for your use of minimum with a recent price; the same logic applies here.)
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.
If the price has really risen a lot over 1-3.5 days (say 2-3x), then I would say there is enough volatility to be "suspicious" (not suspicious in the sense of manipulation, necessarily, just that it may not last), and not give credit for that new, higher price right away, in terms of collateral required.
Overall I'm not very concerned with requiring more collateral. Locking up HIVE for a short time (1-3.5 days) is a very small cost if there is direct profit to be made from the conversion itself (particularly if the profit is large). Arguably, giving people a reason to hold and lock up more HIVE could even be good, but that's not my primary motivation for suggesting a more conservative collateral calculation in this case.
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.
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).
Using the minimum of all the history of median prices provides the maximum degree of protection. The most recent median would be included in that history, so if that happened to be the lowest price, it would set the minimum and the collateral required. If another earlier price were lower, collateral required would be higher.
I'm not worried about this resulting in "too much collateral". Let's say the price doubles or even tripled. That multipled by an 2-3x overcollaterallization ratio would require collateral of 4x-9x. I don't see why people wouldn't post that for a short 1-3.5 day conversion period in order to make even a 1-2% profit, and certainly for a larger profit. The cost of posting collateral for a short time which you then get back just isn't that high. For ease of calculation let's say 1% profit, 10x collateral and 1 day of conversion delay. That's 0.1% per day profit on the posted collateral which is 36% per year not even compounded (compounded would be much higher). This is easily enough to motivate people to do it, and is somewhat of a worst case calculation.
You are correct since we don't know the real time price there is still a risk of undercollateralization. We need to set the overcollateralization ratio high enough to provide reasonable protection as you say, and also just accept some risk of loss in exchange for all the fees collected along the way (not necessarily just from that one conversion request; overall the fees may be quite profitable if overvaluation happens regularly).
Also
Not exactly. That would be the risk of the collateral being insufficient to cover the conversion from the start (obviously very bad), but you definitely want some extra collateral, not just barely enough to cover the conversion. The latter still gives the blockchain a good chance of a loss and the converter a good chance of a corresponding gain (if the HIVE price were to drop still more during the conversion process).