BitShares Forum
Main => General Discussion => Topic started by: abit on May 24, 2018, 05:30:08 pm
-
BitAssets' MCR (maintenance collateral ratio) is calculated from price feeds (actually it's the median of feeds), it can change when feed changes, although rarely changes (according to current use cases in production aka BitShares mainnet, but perhaps there are potential new use cases which need to change it frequently).
MCR affects all margin positions. When MCR increased, more short positions will be put into margin call territory; when MCR decreased, more short positions will be pull out of margin call territory.
So, ideally, when MCR changed, all short positions should be reevaluated.
Since the quantity of short positions can be very large, for better performance, a caching mechanism is used in current system, aka "call price". When a short position is created, we calculate its call price with current MCR; when its collateral and/or debt got updated, we update its call price according to current MCR. When median feed price reached call price, the short position is put into margin call territory; when feed price changed backwards, the short position is pull out of margin call territory.
However, in current system, we don't refresh the "call price" cache when MCR changed, that said, existing short positions' call prices can be inconsistent with latest MCR. In the meanwhile, call prices of new positions or updated positions will be always up-to-date as long as MCR didn't change. This may lead to unintended margin calls when MCR decreased, or unintended inability to call when MCR increased.
By the way, BSIP31 partially solved the cache refreshing issue: before BSIP31, when a short position is partially called or settled, its call price won't be updated; after BSIP31, it will. https://github.com/bitshares/bsips/blob/master/bsip-0031.md
Another related feature is BSIP38, using "target_collateral_ratio" option will effectively avoid unintended margin calls, somewhat of double insurance. However, if a borrower is not using "target_collateral_ratio" option, her position can be called unintendedly after MCR decreased. https://github.com/bitshares/bsips/blob/master/bsip-0038.md
Now come back to the MCR topic.
To solve the cache inconsistency issue, we have options:
1. totally drop the caching mechanism, calculate call prices on the fly (may impact order matching performance)
2. update "call price" cache immediately when MCR changed (may impact performance since possibly need to update lots of data at a time)
3. update "call price" cache at maintenance interval since maintenance interval is meant to be used to process mass calculation
With the 3rd approach,
3.1 if we don't change MCR update behavior, aka update "current effective" MCR directly when feed changed, then the call price cache will be still inconsistent before maintenance interval;
3.2 we can defer MCR update to maintenance interval, that said, when detected a MCR change due to feed change or asset option e.g. feed lifetime change, don't apply the MCR update immediately, but apply it in next maintenance interval. With this approach, the call price data will be always consistent to "current effective" MCR.
* pros: data consistency
* cons: probably poorer user experience (UX), since users (usually asset issuers and feed producers) need to wait when wanted to update MCR.
Summary:
I recommend the 3.2 approach: defer MCR update to maintenance interval, update call price cache every time after MCR updated.
Update: at present I tend to adopt option 1. Actually, we can also try to move the caching to median price feed.
Thoughts?
-
MCR=maintenance collateral ratio?
MCR= median collateral ratio?
-
3.2 Approach: Does witness have enough time for issue #504 + Defer MCR Update?
If Yes, I would say just go ahead.
If No, is it possible to set Defer MCR update at different time eg. every hour 35 minutes?
-
MCR=maintenance collateral ratio?
MCR= median collateral ratio?
It's actually median of "maintenance collateral ratio" fed by feed producers, I I abbr'ed it to "median collateral ratio". OP updated.
-
I prefer 3.2 as well.
Consistency is key on the blockchain.
Scalability is key as well.
The fact that the economics slight change (read are delayed) in case the MCR changes, isn't too much of a problem
and rather gives people a chance to update their orders in time BEFORE it becomes active.
So, I am all for 3.2
-
support
by the way ,the shorter have the freedom to choice settlement time .if he has the second collateral ,such as gdex.btc . then,we have no reason to buy bitcny for adjusting.
the second collateral is an open idea .
-
I'm for option 1.
The call_price caching is a nice example of Knuth's "Premature Optimization" rule. Removing the cache would simplify the code without changing chain behaviour, whereas deferring MCR changes would make it more complicated *and* reduce chain responsiveness. Also I don't think the impact on performance in order matching would be significant.
-
I'm for option 1.
The call_price caching is a nice example of Knuth's "Premature Optimization" rule. Removing the cache would simplify the code without changing chain behaviour, whereas deferring MCR changes would make it more complicated *and* reduce chain responsiveness. Also I don't think the impact on performance in order matching would be significant.
How much work would it be to implement this and see how much *extra complexity* it adds?
-
I feel 3.2 is acceptable in UX.
however sounds option 1 is an even better solution, but I am not sure whether it add extra complexity or uncertainty, seems need to do more evaluation to ensure the safety.
-
At present I tend to adopt option 1 as well. By moving the caching to median price feed, perhaps performance can be even better. It's still a hard fork change anyway.
-
If changes of MCR is not frequent, I believe we can change MCR even before the protocol upgrade on Dec 2018. What we can do is announce to the community the date/time when MCR will change, then they can update their position for new call price.