8.3 KiB

Raw Blame History

BSIP: 0042
Title: Adjust price feed to influence trading price of SmartCoins
Author: Abit More <https://github.com/abitmore>
Status: Up for voting
Type: Protocol
Created: 2018-08-22
Workers: 1.14.118 (pro), 1.14.119 (con)

Abstract

We here propose to dynamically adjust price feed in order to influence trading price of smart coins to achieve tighter peg.

This BSIP is constantly evaluated in terms of being accepted or rejected,see the last section Constant voting evaluation for details.

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.

It will be good to apply the change to bitCNY first, which has much better liquidity than other smartcoins. After witnesses and community learned enough in the process it can be also applied to bitUSD.

Discussion

Summary for Shareholders

The peg of SmartCoin to the underlying asset is crucial to create trust for SmartCoin holders, in combination with a force settlement offset that is considered fair. This BSIP seeks to adress the issue of volatility with respect to the peg by allowing the witnesses to implement (within boundaries) their own price feed strategy that is targeted to uphold the peg and provide a fair force settlement offset.

This is a crucial intrusion into the open market mechanics and is thus not a strict directive to the witnesses, furthermore this BSIP is constantly evaluated, and if it becomes rejected (see the next section), witnesses are bound to return to the former price feed mechanisms.

Constant voting evaluation

This BSIP has a pro and a con worker and has an ever evaluated state of accepted and rejected.

Accepted: The pro worker is active in terms of receiving payout from the reserve pool AND its votes surpass the con worker.
Rejected: The pro worker is NOT active (is not receiving funds from reserve pool) OR the votes of the con worker surpass the pro worker. If the pro worker expires, this BSIP is also considered rejected.

The earliest that this worker can become active is 7th September 2018.

Copyright

This document is placed in the public domain.

8.3 KiB Raw Blame History