bsips/bsip-0042.md

    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](bsip-0016.md) 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

- https://bitsharestalk.org/index.php?topic=26948.0
- https://bitsharestalk.org/index.php?topic=26315.0
- https://bitsharestalk.org/index.php?topic=26966.0

# 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.