Main > General Discussion

[New BSIP Discussion] Defer MCR update to next maintenance interval

<< < (3/3)

abit:
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?

Navigation

[0] Message Index

[*] Previous page