6.7 KiB
BSIP: 0042
Title: Adjust price feed to influence trading price of SmartCoins
Author: Abit More <https://github.com/abitmore>
Status: Draft
Type: Protocol
Created: 2018-08-22
Discussions: https://bitsharestalk.org/index.php?topic=26948.0
https://bitsharestalk.org/index.php?topic=26315.0
Worker: TBD
Abstract
We here propose to dynamically adjust price feed in order to influence trading price of smart coins to achieve tighter peg.
Motivation
To get mass adoption, it's better that the SmartCoins can peg to targets more tightly. E.G. bitUSD pegs more tightly to Fiat USD.
Rationale
When BTS is in a downtrend, the SmartCoins are always being traded at a premium; when BTS is in a uptrend, the SmartCoins tend to be traded with a discount. Here is a chart showing historical trading price of bitUSD: https://coinmarketcap.com/currencies/bitusd/
Typically a premium is around 10%, and a discount is around 5%. Although some people think the numbers are not very large, other people think they're too large. In this BSIP we aim to reduce the numbers.
Trading price of a SmartCoin is influenced by
- underlying value guaranteed by collateral;
- demand vs supply.
Downtrend and premium
When BTS is in a downtrend, before a black swan event, supplies of SmartCoins are squeezed, while the underlying value is still guaranteed if price feeds are around real trading price, thus trading price of the SmartCoins will be pushed up.
If we slightly adjust the price feed, thus slightly loose the guarantee on the underlying value, hopefully we can push the trading price of SmartCoins towards par. Since adjusting price feed affects supply as well, ideally we don't need to adjust much to achieve the goal.
Other options include decreasing MCR to stimulate supply, or decreasing MSSR to suppress demand.
Negative feedback
Actually we don't know what's the best offset to be applied to the inputs, but we can adopt a negative feedback approach. When adjusting the inputs, keep an eye on the result (trading price of SmartCoins). If the adjustment is in the correct direction, the price should move towards par. If the price moved too little, we adjust more; if the price moved too much, we adjust less. Finally this will lead to a stable result.
We may consider setting a hard limit on the offset which may make us feel safer. Actually, to be safe, we do need to start with a small offset, and adjust little by little. Since it's expected that the best offset will be figured out by the negative feedback mechanism, a preset limit may impact the mechanism negatively. A few witnesses publishing too far away offset doesn't harm much because they won't move the median much. In addition, stake holders may vote down perceived bad actors.
Risks
All the adjustments (price feed, or MCR, or MSSR) in a downtrend actually looses requirement of collateral ratio, so it seems it will increase the possibility of black swan events. This is actually the most contraversial part of this BSIP.
The counter argument is about liquidity. As we can see, even without the adjustments, black swan events have occurred on bitHKD, bitSGD and some other SmartCoins due to poor liquidity. In contrast, bitCNY, bitUSD and etc have survived due to good liquidity. With the adjustments, hopefully we'll have better adoption, which means better liquidity in the markets, so possibility of black swan events would likely decrease.
Guarantee of value
Adjusting price feeds impacts force settlements. Specifically, a user will likely get less by force settling when the price feed is adjusted. This lead to an argument says it breaks guarantee of SmartCoins' value.
The counter argument is also liquidity. With good liquidity, users should buy from market rather than force settling. It's up to UI to guide users for better experience. If a user has a large volume to trade, she has to be patient, since even go the force settlement approach she will likely encounter the volume limitation as well.
Margin call price
Actual price (in FIAT) when buying into a margin call would be unchanged, because the adjustment will shift trading price of SmartCoins but not BTS. It's expected that margin calls will be less though.
User experience changes
Currently, GUI shows median price feed on the market page. By looking at the price, people know what price BTS is trading around. Then people can check lastest trading price of BTS / SmartCoin pairs, to know how much premium or discount that the SmartCoins are trading at.
After applied the adjustments on price feeds, the median price feed showing on market page of GUI will no longer mean trading price of BTS, instead, it will mean a somewhat "guiding price" for SmartCoin production. People may get confused especially in the beginning of applying the adjustments.
On the other hand, after applied the adjustments, hopefully SmartCoins will be traded on par, so latest trading price of BTS / SmartCoin pairs will indicate trading price of BTS.
It's up to the GUI development team to optimize the GUI for better user experience.
Uptrend and discount
When BTS is in a uptrend, usually SmartCoins are oversupplied which results in devaluation. Ideally, to reduce supply, the best approach is to increase MCR. However, at this moment, there is a bug in BitShare-Core so we can't adjust MCR freely (more info is here: https://github.com/bitshares/bitshares-core/issues/1270). Before the bug is fixed, we can adjust price feed instead, similar to downtrend, with negative feedbacks, but in opposite direction.
Note: when adjusting price feed in a uptrend, we should set a fair force settlement offset at same time, see BSIP 16 for more info.
Specification
When witness publishing a price feed, after got price of BTS from exchanges
(assuming it's P), check trading price of the publishing SmartCoin,
adjust P with an algorithm.
To be safe, the algorithm should start with a small offset, or a value near the median, and adjust the offset little by little.
The algorithm should implement negative feedback, that said, it should track historical adjustments and historical differences on trading prices of SmartCoins, and make new adjustments accordingly.
We don't force all witnesses to use a same algorithm, instead, witnesses are encouraged to implement different algorithms for same goal.
We also don't set a hard limit about how much the offset should be within, in order to let the negative feed back mechasim find the best result by itself. Witnesses should make their own decisions on whether to set a hard limit and how much should it be if need to set one, generally, to reduce impacts caused by bugs.
Discussion
[To be added]
Summary for Shareholders
[To be added]
Copyright
This document is placed in the public domain.