286 lines
12 KiB
Markdown
286 lines
12 KiB
Markdown
BSIP: 0018
|
|
Title: Revive BitAsset through buying Settlement Pool
|
|
Authors: Fabian Schuh, Peter Conrad
|
|
Status: Installed
|
|
Type: Protocol
|
|
Created: 2017-06-05
|
|
Discussion: https://bitsharestalk.org/index.php/topic,24322.0.html
|
|
Worker: 1.14.56
|
|
|
|
# Abstract
|
|
|
|
BitAssets, i. e. market-pegged assets (MPA) like bitUSD in BitShares can suffer
|
|
a "global settlement" event. After global settlement, the asset is
|
|
effectively rendered useless. This BSIP proposes a protocol change to
|
|
enable resolving a global settlement so that affected assets can be
|
|
continued and put to good use again.
|
|
|
|
# Motivation
|
|
|
|
The necessity of reviving bitassets has already been discussed in
|
|
BSIP-0017, and is unquestioned.
|
|
|
|
Market-pegged assets, aka SmartCoins are among the core features of the
|
|
BitShares blockchain and as such provide one of our unique selling points.
|
|
|
|
MPAs can suffer a "global settlement" event. A global settlement occurs
|
|
when the least collateralized short position has insufficient collateral
|
|
to buy back the borrowed SmartCoins at the current feed price. What
|
|
happens then is that the MPA is tagged with a "settlement price",
|
|
defined as the collateral ratio of the least collateralized short. All
|
|
short positions are closed automatically, by collecting sufficient
|
|
collateral into a settlement pool and paying out the remainder to the
|
|
short's owners. MPA holders can use the forced settlement operation to
|
|
receive their share from the settlement pool in exchange for their MPAs.
|
|
Even after global settlement, market-pegged assets can still be
|
|
transferred or traded, but they can no longer be borrowed.
|
|
|
|
Currently, in BitShares, there is no actual way to resolve the global
|
|
settlement, but eventually, all significant holders will have to settle
|
|
their positions to obtain BTS for their long position. Some dust will
|
|
remain scattered all over the place, where the value of the dust
|
|
position is lower than the fees required to get rid of it.
|
|
|
|
# Rationale
|
|
|
|
When a market-pegged asset undergoes a global settlement, one of the crucial
|
|
mechanisms that support the peg (namely "margin calls") is no longer available.
|
|
However, other mechanisms, such as the "face-value", trading and settlement
|
|
still exist and, unless the valuation of the underlying asset decreases
|
|
significantly, the outstanding debt (the BitAsset long positions) are still
|
|
collateralized through the settlement pool at the fixed settlement price. It is
|
|
even possible that the value of the collateral exceeds the nominal value of the
|
|
MPA significantly.
|
|
|
|
For example, if a global settlement event happened on USD at a price of 1
|
|
bitUSD/BTS, then an outstanding debt of 1000 bitUSD would be backed by
|
|
1000 BTS in the settlement pool of the bitUSD asset. No other call positions
|
|
would be open by anyone else. Every bitUSD long position could, in this case,
|
|
claim BTS from the settlement pool at a rate of 1:1.
|
|
|
|
# Proposal
|
|
|
|
All that is needed for the asset to be *revived* is:
|
|
|
|
* re-enable price feeds
|
|
* replace the settlement pool with sufficiently collateralized call positions.
|
|
|
|
Since after a global settlement, the collateral for the outstanding long
|
|
positions are stored in the settlement pool, we here propose a way to **obtain
|
|
the funds in the settlement pool and its outstanding debt from the
|
|
network**. Since the collateral ratio of the settlement pool after a
|
|
global settlement is 100%, obtaining the settlement funds in order to
|
|
convert it into an open call position **requires to also provide
|
|
additional collateral or reduce the debt** in order to not cause another
|
|
global settlement or margin call right away.
|
|
|
|
# Specifications
|
|
|
|
Like in BSIP-0017, let SWAN be an asset that has seen global settlement, and
|
|
let BACK be the asset backing SWAN.
|
|
|
|
## Bugfix: MPAs that have seen a global settlement cannot be settled after the price feed expires
|
|
|
|
It has turned out that force-settling an MPA requires a valid price feed
|
|
even when the MPA has a `settlement_price` set. This is clearly a bug,
|
|
since in that case the settlement price is independent from the price
|
|
feed. Furthermore, publishing price feeds is no longer possible after a
|
|
global settlement, so the time when settlement is possible at all is
|
|
limited to the expiration period of the price feed of the MPA.
|
|
|
|
This bug will be fixed. See
|
|
https://github.com/cryptonomex/graphene/issues/664#issuecomment-254056746
|
|
for a discussion.
|
|
|
|
(This fix is also part of BSIP-0017. Obviously, it needs to be fixed only once.
|
|
It is repeated here because it is currently unclear which of these proposals
|
|
will be implemented.)
|
|
|
|
## Auto-revive after increase of settlement fund value
|
|
|
|
This applies only to SmartCoins, not to Prediction Markets.
|
|
|
|
A price increase of BACK can lead to the situation where SWAN is worth much more
|
|
than it was originally intended to be. I. e. the value of the settlement fund
|
|
becomes much greater than the nominal value of the existing supply of SWAN.
|
|
|
|
When the value of the settlement fund reaches the minimum required collateral
|
|
(in terms of price feed and MCR), a call_order_object owned by the issuer of
|
|
SWAN is created (or updated) that takes the settlement_fund as collateral and
|
|
covers the full debt. The settlement_fund and the settlement_price will then
|
|
be cleared, which revives the asset.
|
|
|
|
The condition can easily be checked at the time the price feed is updated.
|
|
Obviously, this requires a price feed. Currently it is not possible to
|
|
publish a price feed for assets that have seen global settlement. This
|
|
restriction will be removed.
|
|
|
|
## Recollateralize
|
|
|
|
This applies only to SmartCoins, not to Prediction Markets.
|
|
|
|
### Overview
|
|
|
|
The idea of turning the settlement fund into a short position when its
|
|
value has increased sufficiently can easily be extended. If the value of
|
|
the settlement fund itself is too low to create a sufficiently collateralized
|
|
short position (in terms of price feed and MCR), investors could volunteer to
|
|
add the required amount of collateral to the fund and take ownership of the
|
|
resulting short position (collateral+debt).
|
|
|
|
The proposed operation enables potential investors to "bid" additional
|
|
collateral for taking over part of the debt (or all of it). When enough bids
|
|
have been made to cover the full outstanding debt, and all of them are
|
|
sufficiently collateralized (in terms of price feed and MCR), the
|
|
settlement_fund and the bids are turned into call positions. Finally, the
|
|
settlement_price is removed from the asset, which revives it.
|
|
|
|
If the available bids cover more than the outstanding debt, bids with a higher
|
|
collateral/debt ratio are preferred over those with a lower ratio. The intent is
|
|
to turn the competition among investors into better collateralized calls, which
|
|
is in the interest of the MPA holders.
|
|
|
|
### `bid_collateral_operation`
|
|
|
|
The operation has the following payload:
|
|
|
|
* `fee`(asset_type): The operation requires a fee to be paid
|
|
* `bidder`(account_type): This account pays the additional collateral and
|
|
will become the owner of the resulting call position, if the bid is accepted
|
|
* `additional_collateral`(asset_type): Collateral paid by the account in order
|
|
to support the call position
|
|
* `debt_covered`(asset_type): The amount of debt the account is willing to cover
|
|
|
|
The operation works as follows:
|
|
|
|
1. It pays a fee
|
|
2. If account has already placed a bid on the same MPA, the existing bid is
|
|
cancelled (see below).
|
|
3. If `debt_covered` equals 0, no further action is taken.
|
|
4. It reduces the account's balance by `additional_collateral`.
|
|
5. It creates a `collateral_bid_object` containing the `bidder` and the partial
|
|
inverted swan price calculated as `additional_collateral` / `debt_covered`.
|
|
|
|
The required validity checks for the operation are:
|
|
|
|
* `debt` == 0 || `debt` > 0 && `collateral` > 0
|
|
|
|
The required evalutation checks for the operation are:
|
|
|
|
* debt_covered.asset must be a bitasset (not a PM) with a settlement_price
|
|
* additional_collateral.asset must be the asset backing SWAN
|
|
* account must have sufficient BACK, i. e. at least additional_collateral
|
|
|
|
Obviously, the operation must be authorized by `bidder`.
|
|
|
|
### `collateral_bid_object`
|
|
|
|
The `collateral_bid_object` stores information about bids offered by accounts
|
|
using the `bid_collateral_operation`. It is indexed
|
|
|
|
1. by_id
|
|
2. by debt asset and bidder
|
|
3. by debt asset and partial inverted swan price.
|
|
|
|
When a `collateral_bid_object` is cancelled, the additional_collateral (i. e.
|
|
the partial inverted swan price's base) is returned to the bidder and the
|
|
`collateral_bid_object` is deleted.
|
|
|
|
The intent of the partial inverted swan price is to facilitate selection of the
|
|
bids that will result in the call_order_objects with the lowest debt/collateral
|
|
ratio after the revival of the bitasset.
|
|
|
|
### Maintenance
|
|
|
|
In every maintenance interval, all MPAs that have a settlement_price are checked
|
|
if
|
|
|
|
* they have a valid price feed, and
|
|
* if enough sufficiently collateralized bids are available to cover the debt.
|
|
|
|
If both conditions are met, for each `collateral_bid_object` (in order of
|
|
descending partial inverted swan price) a new call_order_object will be
|
|
constructed in this way, starting with remaining_debt=SWAN.current_supply:
|
|
|
|
* call.borrower = bid.bidder
|
|
* call.debt = bid.debt.amount
|
|
* call.collateral = call.debt * SWAN.settlement_price + bid.additional_collateral.amount
|
|
* remaining_debt -= call.debt
|
|
* SWAN.settlement_fund -= call.debt * SWAN.settlement_price
|
|
|
|
If remaining_debt reaches 0, any remaining bids will be cancelled.
|
|
It is likely that for the last converted bid the requested debt will be less
|
|
than the remaining_debt. In that case, call.debt will be set to remaining_debt
|
|
and call.collateral will be set to asset.settlement_fund + additional_collateral.
|
|
|
|
### `execute_bid_operation`
|
|
|
|
In order to make the revival event visible in the bid owners' account histories,
|
|
a new virtual `execute_bid_operation` will be introduced, that contains these
|
|
parameters:
|
|
|
|
* the `bidder`
|
|
* the actual covered `debt`
|
|
* the total `collateral` of the resulting call_order
|
|
|
|
The semantics of that operation includes the removal of the existing bid and
|
|
the creation of the new call_order as described above.
|
|
|
|
# Discussion
|
|
|
|
## Partially Obtaining Settlement Funds
|
|
|
|
In the case a widely used BitAsset is globally settled, the cost of providing
|
|
sufficient collateral and the associated risk may be prohibitively high. The
|
|
proposed bidding mechanism allows to split the cost (and the risk) among
|
|
multiple participants.
|
|
|
|
## BitAssets using BitAssets as collateral are unaffected
|
|
|
|
One huge advantage of this approach over BSIP-0017 is that BitAssets which are
|
|
collateralized by other BitAssets are not directly affected by this proposal.
|
|
Even though the *economical debt* of such asset may be argued about if the
|
|
collateral asset experienced a global settlement, the *technical debt*
|
|
is unaffected. Converting the settlement pool into a regular call
|
|
position through this proposal would not only restore the original
|
|
BitAsset, but also reset the collateral of the derived BitAsset.
|
|
|
|
## Cost vs. Profit
|
|
|
|
This operation opens an interesting cost vs. profit trade-off for those willing
|
|
to take the risk of using this operation that we would like to discuss. Keep in
|
|
mind that
|
|
|
|
* the valuation of the collateral may be volatile (e.g. in case of BTS)
|
|
* after global settlement, the long positions can settle and thus
|
|
reduce the debt as well as the settlement pool
|
|
|
|
Market participants that are willing to take risk may want to obtain a larger
|
|
chunk of a settlement pool as it means an **instant short position**.
|
|
|
|
## Feeds
|
|
|
|
Re-collateralization is deliberately not restricted to the issuer of the
|
|
globally settled bitasset. The intent here is to incentivize potential
|
|
investors. Effectively, during an uptrend in the value of the
|
|
collateral, this works like a reverse auction. A higher value of the
|
|
collateral results in a lower required amount for re-collateralization,
|
|
i. e. the chance/risk ratio increases. This incentive makes sense,
|
|
because additional collateral is in the best interest of the holders of
|
|
the settled BitAsset.
|
|
|
|
This "reverse auction" ends when the BitAsset is auto-revived by
|
|
creating a short position for the issuer. At that point, an "investor"
|
|
could re-collateralize with zero risk, which is no longer in the
|
|
interest of the holders.
|
|
|
|
# Summary for Shareholders
|
|
|
|
This proposal presents a flexible way of reviving a BitAsset that has
|
|
experienced a global settlement event. The blockchain or shareholders do
|
|
not need to take any risk as the proposal only offers a new way for
|
|
market participants to (partially) revive the BitAsset.
|
|
|
|
# Copyright
|
|
|
|
This document is placed in the public domain.
|